From xxx at mphmedia.net  Sat Dec  3 23:17:33 2005
From: xxx at mphmedia.net (Neil Nelson)
Date: Sat, 03 Dec 2005 16:17:33 -0700
Subject: [Icecast] "preventing YP listings"
Message-ID: <4392278D.6000604@mphmedia.net>

I am running icecast 2.2.0 on Windows XP and am trying to get yp listed
so my server will show on the Icecast Stream Directory under WinAMP.

My sense is that the error.log line seen below ending in "preventing YP
listings" indicates a problem on my end but I do not easily see what it
may be.

Any ideas?

Neil
MPHMedia

[2005-12-03  16:03:47] INFO stats/stats.c stats thread started
[2005-12-03  16:03:47] INFO fserve/fserve.c file serving thread started
[2005-12-03  16:03:47] INFO yp/yp.c YP update thread started
[2005-12-03  16:03:47] DBUG yp/yp.c Add pending yps
http://www.oddsock.org/cgi-bin/yp-cgi
[2005-12-03  16:03:47] DBUG yp/yp.c Add pending yps
http://dir.xiph.org/cgi-bin/yp-cgi
[2005-12-03  16:03:48] DBUG slave/slave.c checking master stream list
[2005-12-03  16:03:48] DBUG slave/slave.c Adding relay source at
mountpoint "/stream"
[2005-12-03  16:03:48] INFO slave/slave.c Starting relayed source at
mountpoint "/stream"
[2005-12-03  16:03:48] DBUG connection/connection.c sources count is 0
[2005-12-03  16:03:48] DBUG source/source.c Applying mount information
for "/stream"
[2005-12-03  16:03:48] DBUG source/source.c fallback /
[2005-12-03  16:03:48] DBUG source/source.c preventing YP listings


From karl at xiph.org  Sun Dec  4 01:02:50 2005
From: karl at xiph.org (Karl Heyes)
Date: Sun, 04 Dec 2005 01:02:50 +0000
Subject: [Icecast] "preventing YP listings"
In-Reply-To: <4392278D.6000604@mphmedia.net>
References: <4392278D.6000604@mphmedia.net>
Message-ID: <4392403A.5060905@xiph.org>

Neil Nelson wrote:
> I am running icecast 2.2.0 on Windows XP and am trying to get yp listed
> so my server will show on the Icecast Stream Directory under WinAMP.
> 
> My sense is that the error.log line seen below ending in "preventing YP
> listings" indicates a problem on my end but I do not easily see what it
> may be.
> 
> Any ideas?

The oddsock.org YP hasn't been running for some time now so don't expect 
that one to work.  As for the 'preventing YP listings', I would guess 
that <no-yp> is enabled for the /stream <mount>

karl.



From etenalio at yahoo.com  Sat Dec  3 14:34:10 2005
From: etenalio at yahoo.com (eric tenalio)
Date: Sat, 3 Dec 2005 06:34:10 -0800 (PST)
Subject: [Icecast] help!!!!!!!!!
Message-ID: <20051203143410.41000.qmail@web35713.mail.mud.yahoo.com>

i just bought traktor dj 3 and i downloaded the icecast software and all the links wont take me too the download packages i need, is there anyway u can walk me through this process. i would really appreciate it
  eric tenalio:O)

		
---------------------------------
 Yahoo! Personals
 Single? There's someone we'd like you to meet.
 Lots of someones, actually. Yahoo! Personals
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20051203/6c0fbe97/attachment.htm>

From msmith at xiph.org  Sun Dec  4 22:15:04 2005
From: msmith at xiph.org (Michael Smith)
Date: Sun, 4 Dec 2005 23:15:04 +0100
Subject: [Icecast] Buffering / disconnect problem
In-Reply-To: <af6aa92fc7a4114ed4d6da72d0513828@gmx.de>
References: <af6aa92fc7a4114ed4d6da72d0513828@gmx.de>
Message-ID: <3c1737210512041415y7ebbf036ud53ef806f7f96190@mail.gmail.com>

On 11/26/05, Lorenz Schoder <angro at gmx.de> wrote:
> hola
> We use IceS2 as source and Icecast 2.3.0 as servertool, streaming ogg
> vorbis in 128kbit/s, players: oggwinamp, vorbis player.
> We have got a new rented server (3ghz) with hardly any application
> running on it and a 100 mbit connection.
> We have 4 people testing the server and although they all got 2mbit
> connections without running any downloads/uploads all of us got
> bufferings, sometimes even we have to redo the authentification.
> Bufferings seem to happen more often the longer we have the server
> running, but I am not totally sure.
>
> Maybe it has nothing to do with it,
>                 -we transcode the ogg files
>                 -some commentlines of the id3 tags seem to be endless

Ogg Vorbis doesn't permit ID3 tags; if your files have ID3 tags they
will be ignored, and may cause problems, though this is unlikely to be
causing the particular issue you describe.

What client/player are your testers using?

It's actually normal for most 'simple' clients to underrun or overrun
their buffers eventually. This occurs because IceS2 (when streaming
preexisting data, rather than live) and icecast will send audio data
at precisely the correct rate (assuming your computer's system clock
is accurate). So, if your stream is 44.1kHz, it'll send it at that
rate.

However, your listening clients will be running at a slightly
different rate - usually just a fraction of a percent off perfect,
because the audio clock on the client computer will usually not be
perfectly accurate.

More advanced clients can compensate for this, but simpler ones can't,
so they eventually either fall too far behind because their buffers
are full, or read too quickly, and have to rebuffer.

Mike


From m.musnikas at lrtc.lt  Mon Dec  5 11:58:24 2005
From: m.musnikas at lrtc.lt (Mindaugas Musnikas)
Date: Mon, 5 Dec 2005 13:58:24 +0200
Subject: [Icecast] Server Full
Message-ID: <037001c5f993$321f7bc0$a290a8c0@techmindaugas>

Hello all,

I have a problem with error message Icecast server generates. We are using Icecast 2.2.0. User limit is set to 1000. The problem is that  when 1001 user tries to connect server generates Error 404 File Not Found instead of 504 Server Full. What could be reason of such behavior? Thank you in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20051205/3102a2d7/attachment.htm>

From karl at xiph.org  Mon Dec  5 17:31:26 2005
From: karl at xiph.org (Karl Heyes)
Date: Mon, 05 Dec 2005 17:31:26 +0000
Subject: [Icecast] Server Full
In-Reply-To: <037001c5f993$321f7bc0$a290a8c0@techmindaugas>
References: <037001c5f993$321f7bc0$a290a8c0@techmindaugas>
Message-ID: <4394796E.1090607@xiph.org>

Mindaugas Musnikas wrote:
> Hello all,
> 
> I have a problem with error message Icecast server generates. We are using Icecast 2.2.0. User limit is set to 1000. The problem is that  when 1001 user tries to connect server generates Error 404 File Not Found instead of 504 Server Full. What could be reason of such behavior? Thank you in advance.

This should be fixed in 2.3.1

karl.



From metanoid at gmail.com  Wed Dec  7 12:06:11 2005
From: metanoid at gmail.com (John Hebert)
Date: Wed, 7 Dec 2005 06:06:11 -0600
Subject: [Icecast] stupid user tricks with ices2: "No such file or
	directory" :P
Message-ID: <49e372d20512070406o36a6bc0esd6caae4aaf7953f7@mail.gmail.com>

I must be doing something really stupid.

I've read the docs for icecast2 and ices2. Icecast2 is running fine; I can
get stats.xml and see that it is running.

When I run ices2, I get the following error in ices.log:
...
[2005-12-07  05:37:51] INFO playlist-basic/playlist_basic_get_next_filename
Loading playlist from file "/home/john/playlist.txt"
[2005-12-07  05:37:51] WARN playlist-builtin/playlist_read Error opening
file "Vistors.ogg": No such file or directory
...

And I've made playlist.txt as simple as I can:

playlist.txt:
/home/john/Visitors.ogg

Yes, there is a file called Visitors.ogg in /home/john. I can play the file
just fine in Zinf.

Does ices2 expect .ogg files to be in another specific directory? From
reading the docs, the path to the .ogg files are specified in the playlist
file.

Any ideas? Suggestions?

Thanks for your help.

John Hebert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20051207/85b0b5e5/attachment.htm>

From mihamina.rakotomandimby at etu.univ-orleans.fr  Thu Dec  8 12:11:07 2005
From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina)
Date: Thu, 08 Dec 2005 13:11:07 +0100
Subject: [Icecast] help!!!!!!!!!
In-Reply-To: <20051203143410.41000.qmail@web35713.mail.mud.yahoo.com>
References: <20051203143410.41000.qmail@web35713.mail.mud.yahoo.com>
Message-ID: <1134043867.2457.10.camel@localhost.localdomain>

On Sat, 2005-12-03 at 06:34 -0800, eric tenalio wrote:
> all the links wont take me too the download packages i need,

- What links exactly?
- What's the relationship between traktor and Icecast?

-- 
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.
Free hosting of CPS groupware: http://www.objectis.org.



From msmith at xiph.org  Fri Dec  9 09:12:09 2005
From: msmith at xiph.org (Michael Smith)
Date: Fri, 9 Dec 2005 10:12:09 +0100
Subject: [Icecast] stupid user tricks with ices2: "No such file or
	directory" :P
In-Reply-To: <49e372d20512070406o36a6bc0esd6caae4aaf7953f7@mail.gmail.com>
References: <49e372d20512070406o36a6bc0esd6caae4aaf7953f7@mail.gmail.com>
Message-ID: <3c1737210512090112h12786325q26334f75719bb1df@mail.gmail.com>

On 12/7/05, John Hebert <metanoid at gmail.com> wrote:
> I must be doing something really stupid.
>
> I've read the docs for icecast2 and ices2. Icecast2 is running fine; I can
> get stats.xml and see that it is running.
>
> When I run ices2, I get the following error in ices.log :
> ...
> [2005-12-07  05:37:51] INFO
> playlist-basic/playlist_basic_get_next_filename Loading
> playlist from file "/home/john/playlist.txt"
> [2005-12-07  05:37:51] WARN playlist-builtin/playlist_read Error opening
> file " Vistors.ogg": No such file or directory
> ...
>
> And I've made playlist.txt as simple as I can:
>
> playlist.txt:
> /home/john/Visitors.ogg

Are you sure you've got IceS opening the playlist file you think you
do? I'd expect that the error message, if you got one, would refer to
"/home/john/Visitors.ogg", rather than just the last bit.

Also, in whatever file it IS reading, there appears to be a leading
space in the filename, it's trying to open " Vistors.ogg" rather than
"Visitors.ogg".

Mike


From karl at xiph.org  Fri Dec  9 15:40:39 2005
From: karl at xiph.org (Karl Heyes)
Date: Fri, 09 Dec 2005 15:40:39 +0000
Subject: [Icecast] stupid user tricks with ices2: "No such file
	or	directory" :P
In-Reply-To: <49e372d20512070406o36a6bc0esd6caae4aaf7953f7@mail.gmail.com>
References: <49e372d20512070406o36a6bc0esd6caae4aaf7953f7@mail.gmail.com>
Message-ID: <4399A577.7060306@xiph.org>

John Hebert wrote:
> I must be doing something really stupid.
> 
> I've read the docs for icecast2 and ices2. Icecast2 is running fine; I can
> get stats.xml and see that it is running.
> 
> When I run ices2, I get the following error in ices.log:
> ...
> [2005-12-07  05:37:51] INFO playlist-basic/playlist_basic_get_next_filename
> Loading playlist from file "/home/john/playlist.txt"
> [2005-12-07  05:37:51] WARN playlist-builtin/playlist_read Error opening
> file "Vistors.ogg": No such file or directory
> ...
> 
> And I've made playlist.txt as simple as I can:
> 
> playlist.txt:
> /home/john/Visitors.ogg
> 
> Yes, there is a file called Visitors.ogg in /home/john. I can play the file
> just fine in Zinf.
> 
> Does ices2 expect .ogg files to be in another specific directory? From
> reading the docs, the path to the .ogg files are specified in the playlist
> file.
> 
> Any ideas? Suggestions?

If /home/john/playlist.txt has full paths to the ogg files then the 
error message saying 'No such file or directory' would also have a full 
path, which the one above does not.  Make absolutely sure that you have 
the right playlist.	

karl.




From metanoid at gmail.com  Fri Dec  9 16:58:58 2005
From: metanoid at gmail.com (John Hebert)
Date: Fri, 9 Dec 2005 10:58:58 -0600
Subject: [Icecast] stupid user tricks with ices2: "No such file or
	directory" :P
In-Reply-To: <4399A577.7060306@xiph.org>
References: <49e372d20512070406o36a6bc0esd6caae4aaf7953f7@mail.gmail.com>
	<4399A577.7060306@xiph.org>
Message-ID: <49e372d20512090858w26bfef63l5d0f7a098e1b3d63@mail.gmail.com>

Michael and Karl,

Thanks for your replies.

Sorry for confusing you with bad test info. The contents of
playlist.txtthat I referred to in my earlier email did not match the
log result I
specified. However, I had ran the test with both a full and relative path in
playlist.txt; "/home/john/Visitors.ogg" and "Visitors.ogg".

Got it working, however. Tried playing a different ogg file than
Visitors.ogg and it worked!!! If you want to test the file
Visitors.oggyourself:
http://www.archive.org/download/Shapeshifting_In_Abalone/Visitors.ogg

My understanding of the encoding section in ices2.xml is that ices2 simply
tries to output the given ogg file with the supplied encoding parameters to
icecast.

Question: The encoding parameters in ices2.xml do not have to match the
encoding bitrates for the played file, correct?

I assume the answer is no, as the ogg file that worked was encoded with the
same sampling rate as Visitors.ogg.

Thanks again for your help. I will be creating a streaming radio station
soon. Pumped!

John Hebert


On 12/9/05, Karl Heyes <karl at xiph.org> wrote:
>
> John Hebert wrote:
> > I must be doing something really stupid.
> >
> > I've read the docs for icecast2 and ices2. Icecast2 is running fine; I
> can
> > get stats.xml and see that it is running.
> >
> > When I run ices2, I get the following error in ices.log:
> > ...
> > [2005-12-07  05:37:51] INFO
> playlist-basic/playlist_basic_get_next_filename
> > Loading playlist from file "/home/john/playlist.txt"
> > [2005-12-07  05:37:51] WARN playlist-builtin/playlist_read Error opening
> > file "Vistors.ogg": No such file or directory
> > ...
> >
> > And I've made playlist.txt as simple as I can:
> >
> > playlist.txt:
> > /home/john/Visitors.ogg
> >
> > Yes, there is a file called Visitors.ogg in /home/john. I can play the
> file
> > just fine in Zinf.
> >
> > Does ices2 expect .ogg files to be in another specific directory? From
> > reading the docs, the path to the .ogg files are specified in the
> playlist
> > file.
> >
> > Any ideas? Suggestions?
>
> If /home/john/playlist.txt has full paths to the ogg files then the
> error message saying 'No such file or directory' would also have a full
> path, which the one above does not.  Make absolutely sure that you have
> the right playlist.
>
> karl.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20051209/8a9865b0/attachment.htm>

From metanoid at gmail.com  Fri Dec  9 17:29:46 2005
From: metanoid at gmail.com (John Hebert)
Date: Fri, 9 Dec 2005 11:29:46 -0600
Subject: [Icecast] stupid user tricks with ices2: "No such file or
	directory" :P
In-Reply-To: <49e372d20512090858w26bfef63l5d0f7a098e1b3d63@mail.gmail.com>
References: <49e372d20512070406o36a6bc0esd6caae4aaf7953f7@mail.gmail.com>
	<4399A577.7060306@xiph.org>
	<49e372d20512090858w26bfef63l5d0f7a098e1b3d63@mail.gmail.com>
Message-ID: <49e372d20512090929n7f81e767s8491ba6efa934b62@mail.gmail.com>

One thing I should have mentioned:

I am running ices 2.0.1 on OpenBSD 3.7. Just realized I am communicating
with both developers of Ices 2.0.1! :)

Thanks again for your help with this. Your development of Ices2 is
appreciated!

Can I help with testing on OpenBSD? Do you need more info or the ices2.xml?

John Hebert

On 12/9/05, John Hebert <metanoid at gmail.com> wrote:
>
> Michael and Karl,
>
> Thanks for your replies.
>
> Sorry for confusing you with bad test info. The contents of playlist.txtthat I referred to in my earlier email did not match the log result I
> specified. However, I had ran the test with both a full and relative path in
> playlist.txt; "/home/john/Visitors.ogg" and "Visitors.ogg".
>
> Got it working, however. Tried playing a different ogg file than
> Visitors.ogg and it worked!!! If you want to test the file Visitors.oggyourself:
> http://www.archive.org/download/Shapeshifting_In_Abalone/Visitors.ogg
>
> My understanding of the encoding section in ices2.xml is that ices2 simply
> tries to output the given ogg file with the supplied encoding parameters to
> icecast.
>
> Question: The encoding parameters in ices2.xml do not have to match the
> encoding bitrates for the played file, correct?
>
> I assume the answer is no, as the ogg file that worked was encoded with
> the same sampling rate as Visitors.ogg.
>
> Thanks again for your help. I will be creating a streaming radio station
> soon. Pumped!
>
> John Hebert
>
>
> On 12/9/05, Karl Heyes <karl at xiph.org> wrote:
> >
> > John Hebert wrote:
> > > I must be doing something really stupid.
> > >
> > > I've read the docs for icecast2 and ices2. Icecast2 is running fine; I
> > can
> > > get stats.xml and see that it is running.
> > >
> > > When I run ices2, I get the following error in ices.log:
> > > ...
> > > [2005-12-07  05:37:51] INFO
> > playlist-basic/playlist_basic_get_next_filename
> > > Loading playlist from file "/home/john/playlist.txt"
> > > [2005-12-07  05:37:51] WARN playlist-builtin/playlist_read Error
> > opening
> > > file "Vistors.ogg": No such file or directory
> > > ...
> > >
> > > And I've made playlist.txt as simple as I can:
> > >
> > > playlist.txt:
> > > /home/john/Visitors.ogg
> > >
> > > Yes, there is a file called Visitors.ogg in /home/john. I can play the
> > file
> > > just fine in Zinf.
> > >
> > > Does ices2 expect .ogg files to be in another specific directory? From
> > > reading the docs, the path to the .ogg files are specified in the
> > playlist
> > > file.
> > >
> > > Any ideas? Suggestions?
> >
> > If /home/john/playlist.txt has full paths to the ogg files then the
> > error message saying 'No such file or directory' would also have a full
> > path, which the one above does not.  Make absolutely sure that you have
> > the right playlist.
> >
> > karl.
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20051209/5d6c29a4/attachment.htm>

From hostmaster at xenterra.net  Fri Dec  9 18:35:07 2005
From: hostmaster at xenterra.net (Robert Muchnick)
Date: Fri, 9 Dec 2005 11:35:07 -0700 (MST)
Subject: [Icecast] stupid user tricks with ices2: "No such file or
	directory" :P
In-Reply-To: <49e372d20512070406o36a6bc0esd6caae4aaf7953f7@mail.gmail.com>
References: <49e372d20512070406o36a6bc0esd6caae4aaf7953f7@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0512091133260.16831@ns1.xenterra.net>

This is pretty obvious but are the directory /home/john and the ogg file 
readable by the user ices2 runs under?

On Wed, 7 Dec 2005, John Hebert wrote:

> I must be doing something really stupid.
>
> I've read the docs for icecast2 and ices2. Icecast2 is running fine; I can
> get stats.xml and see that it is running.
>
> When I run ices2, I get the following error in ices.log:
> ...
> [2005-12-07  05:37:51] INFO playlist-basic/playlist_basic_get_next_filename
> Loading playlist from file "/home/john/playlist.txt"
> [2005-12-07  05:37:51] WARN playlist-builtin/playlist_read Error opening
> file "Vistors.ogg": No such file or directory
> ...
>
> And I've made playlist.txt as simple as I can:
>
> playlist.txt:
> /home/john/Visitors.ogg
>
> Yes, there is a file called Visitors.ogg in /home/john. I can play the file
> just fine in Zinf.
>
> Does ices2 expect .ogg files to be in another specific directory? From
> reading the docs, the path to the .ogg files are specified in the playlist
> file.
>
> Any ideas? Suggestions?
>
> Thanks for your help.
>
> John Hebert
>

Robert Muchnick
Xenterra.net
720-276-7917
-------------- next part --------------
_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast

From xxx at mphmedia.net  Fri Dec  9 20:34:04 2005
From: xxx at mphmedia.net (Neil Nelson)
Date: Fri, 09 Dec 2005 13:34:04 -0700
Subject: [Icecast] Log says yp updated but does not appear at dir.xiph.org
Message-ID: <4399EA3C.7050100@mphmedia.net>

On Windows XP I am running WinAMP to the Shoutcast server and then using
an Icecast 2.2.0 server as a relay. The idea is to have a single source
stream appear on both Shoutcast and Icecast directories.

The log gives the following lines repeatedly but my server does not show
when I search for it at http://dir.xiph.org and does not appear under
the Icecast Stream Directory on WinAmp.

> [2005-12-06  14:34:21] DBUG slave/slave.c checking master stream list
> [2005-12-06  14:34:31] DBUG stats/stats.c update node
> yp_currently_playing (Live From Cedar City, Utah USA)
> [2005-12-06  14:34:31] DBUG yp/yp.c YP touch at
> http://dir.xiph.org/cgi-bin/yp-cgi succeeded


Thanks to Karl for correcting my prior problem.

> The oddsock.org YP hasn't been running for some time now so don't
> expect that one to work.  As for the 'preventing YP listings', I would
> guess that <no-yp> is enabled for the /stream <mount>
>
> karl.


Neil
MPHMedia



From karl at xiph.org  Sat Dec 10 14:17:36 2005
From: karl at xiph.org (Karl Heyes)
Date: Sat, 10 Dec 2005 14:17:36 +0000
Subject: [Icecast] Log says yp updated but does not appear at dir.xiph.org
In-Reply-To: <4399EA3C.7050100@mphmedia.net>
References: <4399EA3C.7050100@mphmedia.net>
Message-ID: <439AE380.1080309@xiph.org>

Neil Nelson wrote:
> On Windows XP I am running WinAMP to the Shoutcast server and then using
> an Icecast 2.2.0 server as a relay. The idea is to have a single source
> stream appear on both Shoutcast and Icecast directories.
> 
> The log gives the following lines repeatedly but my server does not show
> when I search for it at http://dir.xiph.org and does not appear under
> the Icecast Stream Directory on WinAmp.
> 
> 
>>[2005-12-06  14:34:21] DBUG slave/slave.c checking master stream list
>>[2005-12-06  14:34:31] DBUG stats/stats.c update node
>>yp_currently_playing (Live From Cedar City, Utah USA)
>>[2005-12-06  14:34:31] DBUG yp/yp.c YP touch at
>>http://dir.xiph.org/cgi-bin/yp-cgi succeeded

Make sure the stream is accessible externally, the YP server does check 
some of the information passed so if <hostname> is localhost or some 
other invalid external address like 192.168.x.x then the YP information 
will be dropped.  If those seem valid then send us an email (including 
the stream/IP information) and we look into here.

karl.



From xxx at mphmedia.net  Sat Dec 10 20:33:00 2005
From: xxx at mphmedia.net (Neil Nelson)
Date: Sat, 10 Dec 2005 13:33:00 -0700
Subject: [Icecast] Log says yp updated but does not appear at dir.xiph.org
In-Reply-To: <439AE380.1080309@xiph.org>
References: <4399EA3C.7050100@mphmedia.net> <439AE380.1080309@xiph.org>
Message-ID: <439B3B7C.7040401@mphmedia.net>

Karl,

Thank you for your reply. I went through everything carefully and it is
working now.

Neil
MPHMedia

> Neil Nelson wrote:
>
>> On Windows XP I am running WinAMP to the Shoutcast server and then using
>> an Icecast 2.2.0 server as a relay. The idea is to have a single source
>> stream appear on both Shoutcast and Icecast directories.
>>
>> The log gives the following lines repeatedly but my server does not show
>> when I search for it at http://dir.xiph.org and does not appear under
>> the Icecast Stream Directory on WinAmp.
>>
>>
>>> [2005-12-06  14:34:21] DBUG slave/slave.c checking master stream list
>>> [2005-12-06  14:34:31] DBUG stats/stats.c update node
>>> yp_currently_playing (Live From Cedar City, Utah USA)
>>> [2005-12-06  14:34:31] DBUG yp/yp.c YP touch at
>>> http://dir.xiph.org/cgi-bin/yp-cgi succeeded
>>
>
> Make sure the stream is accessible externally, the YP server does
> check some of the information passed so if <hostname> is localhost or
> some other invalid external address like 192.168.x.x then the YP
> information will be dropped.  If those seem valid then send us an
> email (including the stream/IP information) and we look into here.
>
> karl.
>
>
>



From danstowell at gmail.com  Sun Dec 11 00:14:04 2005
From: danstowell at gmail.com (Dan Stowell)
Date: Sun, 11 Dec 2005 00:14:04 +0000
Subject: [Icecast] Cannot build ices0/libshout2 on Mac OSX 10.4.2
Message-ID: <286e6b7c0512101614r66aa384bp@mail.gmail.com>

Hi -

I'm rebuilding my OSX system and I can't get ices0 to build - or to be
more exact, can't get libshout2 to build.

I started by using DarwinPorts, and icecast2 & libogg & libvorbis
seemed to build OK. The install of ices0 then gave up at the libshout2
config stage with output like this:

[...]
checking for libvorbis... ok
checking for struct ovectl_ratemanage_arg... no
configure: error: requisite Ogg Vorbis library not found

Now, I found a thread on this list in July describing a similar
problem: http://lists.xiph.org/pipermail/icecast/2005-July/009744.html
- and suggesting that compiling with gcc 4 might be the cause. I'm
probably compiling with gcc 4 since I have the very latest Apple
Developer Tools installed. Can anyone confirm? Or provide a hint for
how I might fix this?

(I also tried uninstalling the libraries, reinstalling them via fink,
and then manually building libshout2. Then I failed at the config
stage, this time ending with
checking for ogg_sync_init in libogg... configure: error: not found,
maybe you need to set LD_LIBRARY_PATH or /etc/ld.so.conf
)

Thanks in advance for any advice you can give -
Dan
--
http://www.mcld.co.uk


From brendan at xiph.org  Sun Dec 11 00:20:10 2005
From: brendan at xiph.org (Brendan Cully)
Date: Sat, 10 Dec 2005 16:20:10 -0800
Subject: [Icecast] Cannot build ices0/libshout2 on Mac OSX 10.4.2
In-Reply-To: <286e6b7c0512101614r66aa384bp@mail.gmail.com>
References: <286e6b7c0512101614r66aa384bp@mail.gmail.com>
Message-ID: <20051211002010.GA7075@watanabe.kublai.com>

On Sunday, 11 December 2005 at 00:14, Dan Stowell wrote:
> Hi -
> 
> I'm rebuilding my OSX system and I can't get ices0 to build - or to be
> more exact, can't get libshout2 to build.
> 
> I started by using DarwinPorts, and icecast2 & libogg & libvorbis
> seemed to build OK. The install of ices0 then gave up at the libshout2
> config stage with output like this:
> 
> [...]
> checking for libvorbis... ok
> checking for struct ovectl_ratemanage_arg... no
> configure: error: requisite Ogg Vorbis library not found
> 
> Now, I found a thread on this list in July describing a similar
> problem: http://lists.xiph.org/pipermail/icecast/2005-July/009744.html
> - and suggesting that compiling with gcc 4 might be the cause. I'm
> probably compiling with gcc 4 since I have the very latest Apple
> Developer Tools installed. Can anyone confirm? Or provide a hint for
> how I might fix this?
> 
> (I also tried uninstalling the libraries, reinstalling them via fink,
> and then manually building libshout2. Then I failed at the config
> stage, this time ending with
> checking for ogg_sync_init in libogg... configure: error: not found,
> maybe you need to set LD_LIBRARY_PATH or /etc/ld.so.conf
> )

I've built them just fine with fink on OS X.4.3, xcode 2.2. libshout
2.1 and ices0 are already packaged for fink unstable, so you shoudn't
need to build them by hand.


From sci-fi at hush.ai  Sun Dec 11 00:55:54 2005
From: sci-fi at hush.ai (sci-fi at hush.ai)
Date: Sat, 10 Dec 2005 16:55:54 -0800
Subject: [Icecast] Cannot build ices0/libshout2 on Mac OSX 10.4.2
Message-ID: <200512110055.jBB0txpg025023@mailserver2.hushmail.com>


Hi,

On Sat, 10 Dec 2005 16:14:04 -0800 Dan Stowell
<danstowell at gmail.com> wrote:
> Hi -
> 
> I'm rebuilding my OSX system and I can't get ices0
> to build - or to be more exact, can't get libshout2
> to build.
> 
> I started by using DarwinPorts, and icecast2 &
> libogg & libvorbis seemed to build OK. The install
> of ices0 then gave up at the libshout2 config stage
> with output like this:
> 
> [...]
> checking for libvorbis... ok
> checking for struct ovectl_ratemanage_arg... no
> configure: error: requisite Ogg Vorbis library not found
> 
> Now, I found a thread on this list in July
> describing a similar problem:
> http://lists.xiph.org/pipermail/icecast/2005-July/009744.html
> - and suggesting that compiling with gcc 4 might be
> the cause. I'm probably compiling with gcc 4 since I
> have the very latest Apple Developer Tools
> installed. Can anyone confirm? Or provide a hint for
> how I might fix this?
> 
> (I also tried uninstalling the libraries,
> reinstalling them via fink, and then manually
> building libshout2. Then I failed at the config
> stage, this time ending with checking for
> ogg_sync_init in libogg... configure: error: not
> found, maybe you need to set LD_LIBRARY_PATH or
> /etc/ld.so.conf
> )
> 
> Thanks in advance for any advice you can give -
> Dan

Are you doing your builds with:
./configure
make
sudo make install
?

Just this past week I've rolled my own builds using the
Tiger XCode-2.2 set to specify the 10.4u SDK and gcc-4. 
I always begin with the project's latest original tar.gz
files, sometimes needing to get updates via CVS/SVN
(whatever each project uses).

When I am stuck, I sneek into Fink's unstable base/dists
CVS to see how they compiled it.  ;)  But lately it seems
most projects have incorporated whatever patches were
required to make work on OSX, which means Fink and
DarwinPorts themselves are probably way back-level.

Of these Xiph projects, I've just looked at my build dirs
for them, and they all went fine with those three regular
build commands, no special patches or --switches needed. 
I did see that these projects have been recently updated,
e.g. libogg is at 1.1.3 now.

I'm not sure if those DarwinPorts pkgs includes the
'-dev' pieces.  I know Fink splits them up: you need the
foo-dev pkg to get the source code headers etc. installed
along with the binary code for foo, to do any further
building on your own.

I think they shouldn't be mixed up, tho, meaning I will
always run my own builds and not use a Fink/DarwinPorts
pkg to get a missing piece.  I'd much rather find the
original source for a missing piece and build it myself.

I know most ppl like the ease of installing prebuilt
pkgs, but those are usually not the latest stable versions
available at each project (forget how Fink classifies
them, for ex. libogg-1.1.3 has some needed fixes for what
Fink has available).

Plus, I am experimenting with gcc tuning for cpu=7450 and
auto-vectorizing (automatically sensing how to use Altivec
without writing special C/asm code <g>).

I'd say try building these Xiph projects straight from
their latest tar.gz files, and see how it goes.

p.s. when I say you don't need special --switches on the
./configure step, you still might want to see if you need
them.  For ices-0.4, I turned on (--with-*) all the
codecs and python and perl switches so my copy of ices
will support them.  The Fink/DarwinPorts pkgs might not
have that support built-into its pkgs.

And if you do this yourself, be sure to read all the
README and/or INSTALL files, they should help direct you
to what needs to be done first etc.  I'll give a big nod
to the maintenance logic inside those pkg installers,
(IIRC) the 'requires' lines can help you there.





Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485



From danstowell at gmail.com  Sun Dec 11 13:26:34 2005
From: danstowell at gmail.com (Dan Stowell)
Date: Sun, 11 Dec 2005 13:26:34 +0000
Subject: [Icecast] Re: Cannot build ices0/libshout2 on Mac OSX 10.4.2
In-Reply-To: <286e6b7c0512101614r66aa384bp@mail.gmail.com>
References: <286e6b7c0512101614r66aa384bp@mail.gmail.com>
Message-ID: <286e6b7c0512110526v21be03a0k@mail.gmail.com>

Hi -

Thanks to both of you for your answers. In the end I followed a hint
in Brendan's answer, which was to switch Fink to use the unstable
tree. (Of course, since I'm using quite a recent version of Xcode, it
makes sense that the compatibility hasn't made it to the stable tree
just yet.)

Installed ices0 & icecast2, and our radio stream is back up! Hooray!

Thanks
Dan


2005/12/11, Dan Stowell <danstowell at gmail.com>:
> Hi -
>
> I'm rebuilding my OSX system and I can't get ices0 to build - or to be
> more exact, can't get libshout2 to build.
>
> I started by using DarwinPorts, and icecast2 & libogg & libvorbis
> seemed to build OK. The install of ices0 then gave up at the libshout2
> config stage with output like this:
>
> [...]
> checking for libvorbis... ok
> checking for struct ovectl_ratemanage_arg... no
> configure: error: requisite Ogg Vorbis library not found
>
> Now, I found a thread on this list in July describing a similar
> problem: http://lists.xiph.org/pipermail/icecast/2005-July/009744.html
> - and suggesting that compiling with gcc 4 might be the cause. I'm
> probably compiling with gcc 4 since I have the very latest Apple
> Developer Tools installed. Can anyone confirm? Or provide a hint for
> how I might fix this?
>
> (I also tried uninstalling the libraries, reinstalling them via fink,
> and then manually building libshout2. Then I failed at the config
> stage, this time ending with
> checking for ogg_sync_init in libogg... configure: error: not found,
> maybe you need to set LD_LIBRARY_PATH or /etc/ld.so.conf
> )
>
> Thanks in advance for any advice you can give -
> Dan
> --
http://www.flatfourradio.co.uk


From Henrik at Ostergaard.net  Tue Dec 13 13:24:06 2005
From: Henrik at Ostergaard.net (Henrik =?iso-8859-1?Q?=D8stergaard_Madsen?=)
Date: Tue, 13 Dec 2005 14:24:06 +0100 (CET)
Subject: [Icecast] Ices0 and ShoutCast (and KiSS)
Message-ID: <21201.217.74.213.26.1134480246.squirrel@post.Ostergaard.net>

I have successfully set up a system with Ices0.4 and IceCast2.20 (and
Tunez). It plays well using mpg123 or WinAmp.

But I would like to use also my KiSS DVD player for the stream, and I have
not been able to do so - It appearently needs 110% SHOUTcast
compatibility.

So I tried the IceCast2.3.1 - but it still didn't like the KiSS (or the
other way around). In stead, I have added a SHOUTcast server as a relay on
the same machine. The KiSS can connect to this, and the SHOUTcast to
Icecast in shoutcast mode (and using an alias for the mountpoint).

But sometimes, primarily at a change of song on the Ices, the SHOUTcast
stops streaming, and all clients reconnects a few times, and then play on.
The whole thing does not seem particularly stable. Can this be beacuse of
bitrate changes?

To do something about it, I have tried to connect the IceS directly to the
SHOUTcast server, but I cannot get it to connect (using "icy" protocol and
so, but still..) Must the mountpoint be "/" or is there other tricks?

Will it stabilize it more if I re-encode the stream in IceS? I have all
sorts of (stereo) bitrates, including variable ones.. Re-encoding will
cost CPU power, so I would rather be without..

The very best would be to connect the KiSS to the IceCast server, which
seems very stable when using WinAmp. Does anybody have a clue why this is
not working? Can I make the IceCast even more shoutcast-compatible?

Regards

Henrik





From kuzik at cad.kiev.ua  Tue Dec 13 17:39:50 2005
From: kuzik at cad.kiev.ua (Andrew V. Kuzik)
Date: Tue, 13 Dec 2005 19:39:50 +0200 (EET)
Subject: [Icecast] Ices0 and ShoutCast (and KiSS)
In-Reply-To: <21201.217.74.213.26.1134480246.squirrel@post.Ostergaard.net>
References: <21201.217.74.213.26.1134480246.squirrel@post.Ostergaard.net>
Message-ID: <20051213193857.E91442@cad.cad.ntu-kpi.kiev.ua>

Hi!
You can try to do this
KisS->ShoutCast->Icecast2
         winamp->Icecast2(same)

HsM> I have successfully set up a system with Ices0.4 and IceCast2.20 (and
HsM> Tunez). It plays well using mpg123 or WinAmp.
HsM> 
HsM> But I would like to use also my KiSS DVD player for the stream, and I have
HsM> not been able to do so - It appearently needs 110% SHOUTcast
HsM> compatibility.
HsM> 
HsM> So I tried the IceCast2.3.1 - but it still didn't like the KiSS (or the
HsM> other way around). In stead, I have added a SHOUTcast server as a relay on
HsM> the same machine. The KiSS can connect to this, and the SHOUTcast to
HsM> Icecast in shoutcast mode (and using an alias for the mountpoint).
HsM> 
HsM> But sometimes, primarily at a change of song on the Ices, the SHOUTcast
HsM> stops streaming, and all clients reconnects a few times, and then play on.
HsM> The whole thing does not seem particularly stable. Can this be beacuse of
HsM> bitrate changes?
HsM> 
HsM> To do something about it, I have tried to connect the IceS directly to the
HsM> SHOUTcast server, but I cannot get it to connect (using "icy" protocol and
HsM> so, but still..) Must the mountpoint be "/" or is there other tricks?
HsM> 
HsM> Will it stabilize it more if I re-encode the stream in IceS? I have all
HsM> sorts of (stereo) bitrates, including variable ones.. Re-encoding will
HsM> cost CPU power, so I would rather be without..
HsM> 
HsM> The very best would be to connect the KiSS to the IceCast server, which
HsM> seems very stable when using WinAmp. Does anybody have a clue why this is
HsM> not working? Can I make the IceCast even more shoutcast-compatible?
HsM> 
HsM> Regards
HsM> 
HsM> Henrik
HsM> 
HsM> 
HsM> 
HsM> _______________________________________________
HsM> Icecast mailing list
HsM> Icecast at xiph.org
HsM> http://lists.xiph.org/mailman/listinfo/icecast
HsM> 

-- 
Kuzik V.Andrew (www)kuzik.org.ua,(gsm)380675329075,(icq)345641182
???? ???, ? ???????, ??? ??????. :)
?? ??? ??????? ????????? ????, ??? ??? ????????????? ??????
**? ??????? ?? ?????????, ? ?????? ???????????? ??????, ??????????? ??????????.

From Henrik at ostergaard.net  Tue Dec 13 19:22:38 2005
From: Henrik at ostergaard.net (Henrik Ostergaard Madsen)
Date: Tue, 13 Dec 2005 20:22:38 +0100
Subject: [Icecast] Ices0 and ShoutCast (and KiSS)
In-Reply-To: <20051213193645.S91442@cad.cad.ntu-kpi.kiev.ua>
References: <21201.217.74.213.26.1134480246.squirrel@post.Ostergaard.net>
Message-ID: <439F2D8E.10128.BEC150@localhost>

Hi,

The problem the other way around:

IceS -> IceCast -> ShoutCast -> KiSS

(the KiSS then decodes the mp3 to a RAW SPDIF stream, which is received 
by my sourround receiver).

But the constallation is somewhat overkill and slightly unstable, so I would 
prefer just

IceS -> IceCast -> KiSS

But that does not work at all for unknown reasons (since shoutcast can do 
this, and the KiSS is supposed to be shoutcast compatible..)

As a secondary solution, the following could be used:

IceS -> ShoutCast -> KiSS

But here the IceS cannot connect to the ShoutCast - which it should! I 
probably have overlooked something here.. and any guesses are welcome..

Regards

Henrik

Date sent:      	Tue, 13 Dec 2005 19:38:22 +0200 (EET)
From:           	"Andrew V. Kuzik" <kuzik at cad.ntu-kpi.kiev.ua>
To:             	Henrik ?stergaard Madsen <Henrik at Ostergaard.net>
Copies to:      	icecast at xiph.org
Subject:        	Re: [Icecast] Ices0 and ShoutCast (and KiSS)

Hi!
You can try to do this
KisS->ShoutCast->Icecast2 
         winamp->Icecast2(same)
What do you think about this ?
HsM> I have successfully set up a system with Ices0.4 and IceCast2.20 (and
HsM> Tunez). It plays well using mpg123 or WinAmp.
HsM> 
HsM> But I would like to use also my KiSS DVD player for the stream, and I have
HsM> not been able to do so - It appearently needs 110% SHOUTcast
HsM> compatibility.
HsM> 
HsM> So I tried the IceCast2.3.1 - but it still didn't like the KiSS (or the
HsM> other way around). In stead, I have added a SHOUTcast server as a relay on
HsM> the same machine. The KiSS can connect to this, and the SHOUTcast to
HsM> Icecast in shoutcast mode (and using an alias for the mountpoint).
HsM> 
HsM> But sometimes, primarily at a change of song on the Ices, the SHOUTcast
HsM> stops streaming, and all clients reconnects a few times, and then play on.
HsM> The whole thing does not seem particularly stable. Can this be beacuse of
HsM> bitrate changes?
HsM> 
HsM> To do something about it, I have tried to connect the IceS directly to the
HsM> SHOUTcast server, but I cannot get it to connect (using "icy" protocol and
HsM> so, but still..) Must the mountpoint be "/" or is there other tricks?
HsM> 
HsM> Will it stabilize it more if I re-encode the stream in IceS? I have all
HsM> sorts of (stereo) bitrates, including variable ones.. Re-encoding will
HsM> cost CPU power, so I would rather be without..
HsM> 
HsM> The very best would be to connect the KiSS to the IceCast server, which
HsM> seems very stable when using WinAmp. Does anybody have a clue why this is
HsM> not working? Can I make the IceCast even more shoutcast-compatible?
HsM> 
HsM> Regards
HsM> 
HsM> Henrik
HsM> 
HsM> 
HsM> 
HsM> _______________________________________________
HsM> Icecast mailing list
HsM> Icecast at xiph.org
HsM> http://lists.xiph.org/mailman/listinfo/icecast
HsM> 

-- 
Kuzik V.Andrew (www)kuzik.org.ua,(gsm)380675329075,(icq)345641182
???? ???, ? ???????, ??? ??????. :)
?? ??? ??????? ????????? ????, ??? ??? ????????????? ??????
**? ??????? ?? ?????????, ? ?????? ???????????? ??????, ??????????? ??????????.


From brendan at xiph.org  Tue Dec 13 19:26:59 2005
From: brendan at xiph.org (Brendan Cully)
Date: Tue, 13 Dec 2005 11:26:59 -0800
Subject: [Icecast] Ices0 and ShoutCast (and KiSS)
In-Reply-To: <439F2D8E.10128.BEC150@localhost>
References: <21201.217.74.213.26.1134480246.squirrel@post.Ostergaard.net>
	<439F2D8E.10128.BEC150@localhost>
Message-ID: <20051213192658.GB4253@zakopane.cs.ubc.ca>

On Tuesday, 13 December 2005 at 20:22, Henrik Ostergaard Madsen wrote:
> As a secondary solution, the following could be used:
> 
> IceS -> ShoutCast -> KiSS
> 
> But here the IceS cannot connect to the ShoutCast - which it should! I
> probably have overlooked something here.. and any guesses are welcome..

IWFM. You'll just have to go through the logs on both ends (run ices
in verbose mode). Protocol should be icy as you say, and the
mountpoint should be / (shoutcast doesn't support mount points). Also
check the port setting, try +/- 1 if you are getting errors
connecting.


From geoff at hitsandpieces.net  Tue Dec 13 23:03:32 2005
From: geoff at hitsandpieces.net (Geoff Shang)
Date: Wed, 14 Dec 2005 09:03:32 +1000 (EST)
Subject: [Icecast] Trouble compiling Icecast 2.3.1
Message-ID: <Pine.LNX.4.62.0512140850380.4828@data.home>

Hi,

Sorry if this has been posted about before.

I'm trying to upgrade my personal Icecast from some ancient pre-release CVS 
version, and I've hit trouble:

gcc -DHAVE_CONFIG_H -I. -I. -I..  -Wall -ffast-math -fsigned-char 
-I/usr/local/include -I/usr/local/include/libxml2  -pthread -g -O2 -c `test 
-f 'main.c' || echo './'`main.c
In file included from /usr/local/include/libxslt/xsltInternals.h:20,
                  from xslt.h:18,
                  from main.c:49:
/usr/local/include/libxml2/libxml/dict.h:30: syntax error before 
`xmlDictPtr'
/usr/local/include/libxml2/libxml/dict.h:31: warning: data definition has 
no type or storage class
/usr/local/include/libxml2/libxml/dict.h:32: syntax error before 
`xmlDictPtr'
/usr/local/include/libxml2/libxml/dict.h:33: warning: data definition has 
no type or storage class
...

Details are as follows:

Linux Debian 2.2 (x86)
gcc version 2.95.2 20000220 (Debian GNU/Linux)
libogg 1.1.2
Libvorbis aoTuV b3
libxml2 2.6.22
libxslt 1.1.15

Is my compiler just too old, or is there something else I can do?

Geoff.


-- 
Geoff Shang <geoff at hitsandpieces.net>
Phone: +61-418-96-5590
MSN: geoff at acbradio.org

Make sure your E-mail can be read by everyone!
http://www.betips.net/etc/evilmail.html

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html


From hostmaster at xenterra.net  Tue Dec 13 23:10:39 2005
From: hostmaster at xenterra.net (Robert Muchnick)
Date: Tue, 13 Dec 2005 16:10:39 -0700 (MST)
Subject: [Icecast] Trouble compiling Icecast 2.3.1
In-Reply-To: <Pine.LNX.4.62.0512140850380.4828@data.home>
References: <Pine.LNX.4.62.0512140850380.4828@data.home>
Message-ID: <Pine.LNX.4.62.0512131606080.10481@ns1.xenterra.net>

It is almost certain to be the old compiler. Try upgrading to around 
gcc-3.3.6. If that doesn't work, try dropping back to libxml-2.6.21 with 
the upgraded compiler. Icecast 2.3.1 compiles wihout problems with that 
lib and gcc on Slackware Linux with both 2.4.29 and 2.4.31 kernels.

On Wed, 14 Dec 2005, Geoff Shang wrote:

> Hi,
>
> Sorry if this has been posted about before.
>
> I'm trying to upgrade my personal Icecast from some ancient pre-release CVS 
> version, and I've hit trouble:
>
> gcc -DHAVE_CONFIG_H -I. -I. -I..  -Wall -ffast-math -fsigned-char 
> -I/usr/local/include -I/usr/local/include/libxml2  -pthread -g -O2 -c `test 
> -f 'main.c' || echo './'`main.c
> In file included from /usr/local/include/libxslt/xsltInternals.h:20,
>                 from xslt.h:18,
>                 from main.c:49:
> /usr/local/include/libxml2/libxml/dict.h:30: syntax error before `xmlDictPtr'
> /usr/local/include/libxml2/libxml/dict.h:31: warning: data definition has no 
> type or storage class
> /usr/local/include/libxml2/libxml/dict.h:32: syntax error before `xmlDictPtr'
> /usr/local/include/libxml2/libxml/dict.h:33: warning: data definition has no 
> type or storage class
> ...
>
> Details are as follows:
>
> Linux Debian 2.2 (x86)
> gcc version 2.95.2 20000220 (Debian GNU/Linux)
> libogg 1.1.2
> Libvorbis aoTuV b3
> libxml2 2.6.22
> libxslt 1.1.15
>
> Is my compiler just too old, or is there something else I can do?
>
> Geoff.


Robert Muchnick
Xenterra.net
720-276-7917


From bjacint at kvark.hu  Tue Dec 13 23:16:53 2005
From: bjacint at kvark.hu (Balint Jacint)
Date: Wed, 14 Dec 2005 00:16:53 +0100
Subject: [Icecast] matrox rt.x100
Message-ID: <439F5665.1030802@kvark.hu>

Hi,

I got a Matrox RT.X100 Pro capture card to make a live video streaming 
with it. The concert to be streamed will be on Saturday...
I have a Linux-based server running Icecast 2.3, so I need to make this 
computer with the Matrox card to work with the Icecast server. I'd 
prefer Ogg Theora.
Unfortunately there's no Linux support for this card, so the only choice 
I have is Windows XP.
Do you have any idea, how to move on? Has anyone ever faced a problem 
like this? Or is this card "too good" for live streaming...?
I've never ever in my life had anything to do with video, so I feel a 
little lost here...

Thanks in advance!

Yours,
Jacint



From metanoid at gmail.com  Wed Dec 14 09:26:04 2005
From: metanoid at gmail.com (John Hebert)
Date: Wed, 14 Dec 2005 01:26:04 -0800
Subject: [Icecast] Re: Trouble compiling Icecast 2.3.1
In-Reply-To: <Pine.LNX.4.62.0512131606080.10481@ns1.xenterra.net>
References: <Pine.LNX.4.62.0512140850380.4828@data.home>
	<Pine.LNX.4.62.0512131606080.10481@ns1.xenterra.net>
Message-ID: <49e372d20512140126p79487d27u3c86bc2cacfe0a19@mail.gmail.com>

On 12/13/05, Robert Muchnick <hostmaster at xenterra.net> wrote:
> It is almost certain to be the old compiler. Try upgrading to around
> gcc-3.3.6. If that doesn't work, try dropping back to libxml-2.6.21 with
> the upgraded compiler. Icecast 2.3.1 compiles wihout problems with that
> lib and gcc on Slackware Linux with both 2.4.29 and 2.4.31 kernels.

I agree with Robert. Upgrade your compiler. I was able to compile
Icecast 2.3.1 and its dependencies from source on Debian 3.1r0a
(GNU/Linux 2.6.8) using gcc 3.3.5.


From adnusielog4 at rmsud.esercito.difesa.it  Wed Dec 14 11:14:41 2005
From: adnusielog4 at rmsud.esercito.difesa.it (Luigi Palmiero)
Date: Wed, 14 Dec 2005 12:14:41 +0100
Subject: [Icecast] Icecast 2.0 and Oddcast V3 -  Debug error
Message-ID: <000601c6009f$99525e30$efc6170a@pcpalmiero>

Hi guys,
i have an Icecast2 server with 3 source client (Oddcast V3).
I can see in my error.log this lines:

[2005-12-14  12:06:13] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1
[2005-12-14  12:06:13] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1
[2005-12-14  12:06:13] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1

This lines are append every seconds. What is the problem and how can i
view what source causes this error?
Thanks
Luigi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20051214/3e4fbbb6/attachment.htm>

From webdev at chaosmedia.org  Wed Dec 14 13:25:16 2005
From: webdev at chaosmedia.org (ChaosMedia > WebDev)
Date: Wed, 14 Dec 2005 14:25:16 +0100
Subject: [Icecast] XSL Template problem
In-Reply-To: <439F5665.1030802@kvark.hu>
References: <439F5665.1030802@kvark.hu>
Message-ID: <43A01D3C.5000103@chaosmedia.org>

Hi,

i know it won't be a highly technical question and has more to do with 
xml/xsl than icecast itself but i've got a problem with my icecast 
status.xsl template i don't understand and maybe some of you already 
made some "advanced" xsl templates and will be able to help me out..

so better than words you can see the thing in action using the following 
links :

for the properly displayed template : http://www.lilleforum.com

you can click on the "radio" button on the page above or directly access 
the icecast page here :

for the icecast xsl version : 
http://radio.lilleforum.com:8000/alex/status.xsl

when comparing the two headers, you'll see the icecast xsl version has 
some "margin" problems, at least that's how i understand it..
Both pages use the exact same css files and html code for the header part.
The xsl css link being generated thru a php script from that forum 
system, i suspected it could be the source of the problem so i've also 
tested the xsl template with a pure css file but the same thing occurs..

the problem is a bit different in firefox/mozilla and in MSIE, so i was 
wondering if it's not a matter of how those browsers render xsl files ?
Meaning that browsers would react differently to css formating when 
loading a xsl file rather than an html/php.. file ?

Then can you think of a way to make sure the xsl rendering gets similar 
to an classic html rendering ?

Thanks,

Marc


From karl at xiph.org  Wed Dec 14 13:52:15 2005
From: karl at xiph.org (Karl Heyes)
Date: Wed, 14 Dec 2005 13:52:15 +0000
Subject: [Icecast] Icecast 2.0 and Oddcast V3 -  Debug error
In-Reply-To: <000601c6009f$99525e30$efc6170a@pcpalmiero>
References: <000601c6009f$99525e30$efc6170a@pcpalmiero>
Message-ID: <43A0238F.90404@xiph.org>

Luigi Palmiero wrote:
> Hi guys,
> i have an Icecast2 server with 3 source client (Oddcast V3).
> I can see in my error.log this lines:
> 
> [2005-12-14  12:06:13] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1
> [2005-12-14  12:06:13] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1
> [2005-12-14  12:06:13] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1
> 
> This lines are append every seconds. What is the problem and how can i
> view what source causes this error?

That message is from an earlier release of v2, later versions like 2.3.1 
don't have that message.  The message just means that the feed to a 
listener has become full, so needs to back off until the stream data has 
got through. It could be just a temporary stall.

karl.




From andy at earthsong.free-online.co.uk  Wed Dec 14 20:52:29 2005
From: andy at earthsong.free-online.co.uk (Andy Baxter)
Date: Wed, 14 Dec 2005 20:52:29 +0000
Subject: [Icecast] problems compiling libshout-kh
Message-ID: <200512142052.29905.andy@earthsong.free-online.co.uk>

hello,

I just downloaded libshout from http://svn.xiph.org/icecast/branches/kh/ices

and tried to follow the instructions for compiling it. When I 
run ./autogen.sh, I get the following:

monkey:/usr/local/src/libshout-kh# ./autogen.sh
Checking for automake version
  found automake-1.6
  found aclocal-1.6
Generating configuration files for libshout, please wait....
  aclocal-1.6  -I m4
aclocal: couldn't open directory `m4': No such file or directory
  autoheader
autoheader2.50: error: AC_CONFIG_HEADERS not found in configure.in
  libtoolize --automake
  automake-1.6 --add-missing
configure.in:14: no proper implementation of AM_INIT_AUTOMAKE was found,
configure.in:14: probably because aclocal.m4 is missing...
configure.in:14: You should run aclocal to create this file, then
configure.in:14: run automake again.
configure.in: installing `./install-sh'
configure.in: installing `./mkinstalldirs'
configure.in: installing `./missing'
configure.in:15: required file `./config.h.in' not found
examples/Makefile.am: installing `./depcomp'
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
src/Makefile.am:5: required directory src/avl does not exist
src/Makefile.am:5: required directory src/net does not exist
src/Makefile.am:5: required directory src/timing does not exist
src/Makefile.am:5: required directory src/httpp does not exist
src/Makefile.am:5: required directory src/thread does not exist
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
/usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in 
AM_CONDITIONAL
src/Makefile.am:5: required directory src/avl does not exist
src/Makefile.am:5: required directory src/net does not exist
src/Makefile.am:5: required directory src/timing does not exist
src/Makefile.am:5: required directory src/httpp does not exist
src/Makefile.am:5: required directory src/thread does not exist
  autoconf
configure.in:14: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:15: error: possibly undefined macro: AM_CONFIG_HEADER
configure.in:27: error: possibly undefined macro: AM_MAINTAINER_MODE
configure.in:30: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.in:109: error: possibly undefined macro: AM_CONDITIONAL
configure.in:119: error: possibly undefined macro: AC_MSG_WARN
configure.in:159: error: possibly undefined macro: 
AC_CONFIG_LIBCONFIG_IN_STATICconfigure.in:160: error: possibly undefined 
macro: AC_CONFIG_LIBCONFIG_IN
I am going to run ./configure with no arguments - if you wish
to pass any to it, please specify them on the ./autogen.sh command line.
./configure: line 1311: AM_INIT_AUTOMAKE: command not found
./configure: line 1312: syntax error near unexpected token `config.h'
./configure: line 1312: `AM_CONFIG_HEADER(config.h)'

--- end ---

It's trying to look for a directory called 'm4', which doesn't exist. Does 
anyone know what I should do to get this to compile?

andy baxter.


From Henrik at ostergaard.net  Wed Dec 14 20:55:06 2005
From: Henrik at ostergaard.net (Henrik Ostergaard Madsen)
Date: Wed, 14 Dec 2005 21:55:06 +0100
Subject: [Icecast] Ices0 and ShoutCast (and KiSS)
In-Reply-To: <43A0799A.7000306@xiph.org>
References: <43A05BAC.11254.454844@localhost>
Message-ID: <43A094BA.19305.12427DE@localhost>

THAT was it!

Both ones work, so I think I'll stick to the last one.

Now the KiSS will connect to the IceCast2, and I have enabled the metadata 
again without problem.

Thank you very much!

Henrik ?stergaard

Henrik Ostergaard Madsen wrote:
> It did unfortunately not change anything.. Except that the track titles 
> disappears in WinAmp (as expected).
> 
> As the player was able to connect to ShoutCast, it might be worth looking at 
> the differences in communication between the two cases. I include the latest 
> not-working IceCast dump (no metadata) and the working Shoutcast dump.

it could be the OK header that it's not liking, the icecast headers are

HTTP/1.0 200 OK
Content-Type: audio/mpeg
icy-br:128
ice-audio-info: bitrate=128
icy-description:Mixed files of all kinds
icy-genre:All
icy-name:Radio Ostergaard
icy-pub:0
icy-url:http://radio.home.ostergaard.net/index.php
Server: Icecast 2.3.1

the shoutcast ones are

ICY 200 OK
icy-notice1:<BR>This stream requires <a 
href="http://www.winamp.com/">Winamp</a><BR>
icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.5<BR>
icy-name:Radio Ostergaard
icy-genre:All
icy-url:http://radio.home.ostergaard.net/index.php
content-type:audio/mpeg
icy-pub:0
icy-metaint:32768
icy-br:128


so it maybe the ICY header it's expecting.  You could try changing 
src/format.c:275 to read

  bytes = snprintf (ptr, remaining, "ICY 200 OK\r\n"
             "Content-Type: %s\r\n", source->format->contenttype);

rebuild and re-run icecast,  if it works then try changing it to

  bytes = snprintf (ptr, remaining, "HTTP/1.0 200 OK\r\nICY 200 OK\r\n"
             "Content-Type: %s\r\n", source->format->contenttype);

and see if that works.

karl.
-----------------------------------------------------------
Henrik ?stergaard Madsen	Phone: +45 44 48 44 92
PhD, M.Sc.    			Cell:  +45 30 94 02 88  
Mosegard Park 42      		email: Henrik at Ostergaard.net
DK-3500 V?rl?se     		WWW homepage: 
Denmark                   		http://www.Ostergaard.net/Henrik 






From karl at xiph.org  Wed Dec 14 22:51:40 2005
From: karl at xiph.org (Karl Heyes)
Date: Wed, 14 Dec 2005 22:51:40 +0000
Subject: [Icecast] problems compiling libshout-kh
In-Reply-To: <200512142052.29905.andy@earthsong.free-online.co.uk>
References: <200512142052.29905.andy@earthsong.free-online.co.uk>
Message-ID: <43A0A1FC.3040009@xiph.org>

Andy Baxter wrote:
> hello,
> 
> I just downloaded libshout from http://svn.xiph.org/icecast/branches/kh/ices

thats ices-kh, libshout-kh is one up, although you don't need 
libshout-kh now. libshout 2.1 had the necessary work for ices-kh

> It's trying to look for a directory called 'm4', which doesn't exist. Does 
> anyone know what I should do to get this to compile?

The m4 directory should checkout automatically, just like thread, log 
etc, the path is the default one for icecast as a whole 
http://svn.xiph.org/icecast/trunk/m4

karl.


From santiagocapel at yahoo.es  Wed Dec 14 23:30:38 2005
From: santiagocapel at yahoo.es (Santiago Capel)
Date: Thu, 15 Dec 2005 00:30:38 +0100
Subject: [Icecast] Radio production software.
Message-ID: <200512150030.38577.santiagocapel@yahoo.es>

Hi icecasters!

I have set up a radio over internet so that I can broadcast ogg files and the 
output from /dev/dsp.

Is there any GPL software to make radio production, like interviews, mix of 
music and speech, automated broadcasting, etc.

Thanks!



-- 
Tantas cosas que hacer en tan pocas vidas!

		
______________________________________________ 
Renovamos el Correo Yahoo! 
Nuevos servicios, m?s seguridad 
http://correo.yahoo.es


From leo.currie at strath.ac.uk  Thu Dec 15 00:52:31 2005
From: leo.currie at strath.ac.uk (Leo Currie)
Date: Thu, 15 Dec 2005 01:52:31 +0100
Subject: [Icecast] matrox rt.x100
In-Reply-To: <439F5665.1030802@kvark.hu>
References: <439F5665.1030802@kvark.hu>
Message-ID: <43A0BE4F.60103@strath.ac.uk>

Balint Jacint wrote:
> I got a Matrox RT.X100 Pro capture card to make a live video streaming 
> with it. The concert to be streamed will be on Saturday...
> I have a Linux-based server running Icecast 2.3, so I need to make this 
> computer with the Matrox card to work with the Icecast server. I'd 
> prefer Ogg Theora.
> Unfortunately there's no Linux support for this card, so the only choice 
> I have is Windows XP.
> Do you have any idea, how to move on? Has anyone ever faced a problem 
> like this? Or is this card "too good" for live streaming...?
> I've never ever in my life had anything to do with video, so I feel a 
> little lost here...

This ought to be possible, but I've spent a few hours trying without 
much success.

VLC[1] for Windows should in theory be able to do this (assuming your 
capture card is DirectShow capable, which it probably is) but in 
practise it seems that none of the components required (theora encoder, 
vorbis encoder, ogg muxer and libshout output) work properly on the 
windows version.  In fact, attempting to encode even static files to 
Theora in VLC seems to fail more often than it succeeds.

I also tried to make VLC output the ogg stream to STDOUT, and pipe this 
into Ezstream[2], but that failed as well - I'm not convinced it was 
encoding at all.

One thing that did work (sort of) was using Graphedit[3] and Ezstream 
with the DirectShow ogg filters[4].
A graph was created similar to that shown on the example page[5], except 
the source was my webcam and soundcard. The graph was started and then 
Ezstream was launched which read the file that graphedit was creating.
It worked, but the sound was hopelessly out of sync, the framerate 
erratic, and ezstream reached the eof too quickly and so re-started it.

If there were a DirectShow Ogg mux'er which supported outputting to a 
named pipe, and if Ezstream supported reading from named pipes on 
windows, this might actually work (?)

Anyway, all this waffle doesn't help you stream video! The easy solution 
is to go out and buy the cheapest V4L compatable video capture card 
(e.g. a BT878 based card) which will certainly work in Linux.
If you must stream using the hardware you have, it might be possible to 
use VLC to relay captured video to a linux machine, which could then 
re-encode to theora. I haven't tried this.
Another option is to stream in a different format - Icecast currently 
supports NSV (if you use the SHOUTcast compatibilty mode!) and there are 
  available tools[6] to encode live video to NSV on windows.


Good luck!

Leo


[1] http://www.videolan.org/
[2] http://www.icecast.org/ezstream.php
[3] Part of the DirectX SDK - http://msdn.microsoft.com/directx/sdk/
[4] http://www.illiminable.com/ogg/
[5] http://www.illiminable.com/ogg/enc_theora_graphedit.html
[6] http://www.scvi.net/check.htm


From mihamina.rakotomandimby at etu.univ-orleans.fr  Thu Dec 15 18:29:52 2005
From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina)
Date: Thu, 15 Dec 2005 19:29:52 +0100
Subject: [Icecast] relay password
Message-ID: <1134671393.5215.22.camel@localhost.localdomain>

Hi,

In the Icecast configuration file, there is a 
	[...]
	<relay-password>hackme</relay-password>
	[...]
What is it for? 
I have multiple Icecast server that relay each others and the relays are
considered as simple clients.

That is confirmed by the...
[...]
    <relay>
        <server>127.0.0.1</server>
        <port>8001</port>
        <mount>/example.ogg</mount>
        <local-mount>/different.ogg</local-mount>
        <on-demand>0</on-demand>
        <relay-shoutcast-metadata>0</relay-shoutcast-metadata>
    </relay>
[...]

...where there is not mention of any password.
Would you just give me how to use that passwdord in a Icecast-only
server farm?

-- 
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.
Free hosting of CPS groupware: http://www.objectis.org.



From karl at xiph.org  Thu Dec 15 18:48:12 2005
From: karl at xiph.org (Karl Heyes)
Date: Thu, 15 Dec 2005 18:48:12 +0000
Subject: [Icecast] relay password
In-Reply-To: <1134671393.5215.22.camel@localhost.localdomain>
References: <1134671393.5215.22.camel@localhost.localdomain>
Message-ID: <43A1BA6C.5010602@xiph.org>

Rakotomandimby Mihamina wrote:
> Hi,
> 
> In the Icecast configuration file, there is a 
> 	[...]
> 	<relay-password>hackme</relay-password>
> 	[...]
> What is it for? 
> I have multiple Icecast server that relay each others and the relays are
> considered as simple clients.
> 
> That is confirmed by the...
> [...]
>     <relay>
>         <server>127.0.0.1</server>
>         <port>8001</port>
>         <mount>/example.ogg</mount>
>         <local-mount>/different.ogg</local-mount>
>         <on-demand>0</on-demand>
>         <relay-shoutcast-metadata>0</relay-shoutcast-metadata>
>     </relay>
> [...]
> 
> ...where there is not mention of any password.

you can specify a username and password within <relay> if it's a stream 
that requires it, but again it's as if you are an authenticated listener

> Would you just give me how to use that passwdord in a Icecast-only
> server farm?

In a master/slave setup, where a slave mirrors all the non-hidden 
streams, the slave needs to get a streamlist, and it does that by 
requesting that list from the master server using the relay password 
that is specified in the master xml file <relay-password>.  So 
relay-password in the master must match the master-password in the slave.

karl


From carmien at l3d.cs.colorado.edu  Thu Dec 15 19:27:19 2005
From: carmien at l3d.cs.colorado.edu (Stefan Carmien)
Date: Thu, 15 Dec 2005 12:27:19 -0700
Subject: [icecast] Two streams, one source,
	two different bandwidths: A newbie question
Message-ID: <6A8A693E-651F-4B41-A1F7-34AB7E9A5C6E@l3d.cs.colorado.edu>

Dear Akos-


I just read this:

Don Becker wrote:

 > Ok - here's what I want to do...
 >
 > I compiled and installed icecast 1.3.11 and ices 0.2.2, and can get a
 > single lame-encoded stream working.  What I'd like to do is set up  
two
 > streams - one at 48kbps, one at 128kbps - from one source.  Reason  
being is
 > that I'd like to listen to the high-bandwidth stream locally (ie: in
 > another room of the house) while I listen to the 48kbps stream  
elsewhere.

<p>if your source is your soundcard input, darkice has this feature

<p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at  
xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is  
needed.
Unsubscribe messages sent to the list will be ignored/filtered.


Please tell me where I can find config information about oing this -  
I can't find the section in the darkice book.


	Thanks,

	Stefan Carmien


From mihamina.rakotomandimby at etu.univ-orleans.fr  Fri Dec 16 22:11:38 2005
From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina)
Date: Fri, 16 Dec 2005 23:11:38 +0100
Subject: [Icecast] what is the queuesize?
Message-ID: <1134771099.2469.31.camel@localhost.localdomain>

Hi, 
In the Icecast configuration file, at the begining, there is a queuesize
parameter.
Is it an amount of bits? What bits?
Thank you.

-- 
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.
Free hosting of CPS groupware: http://www.objectis.org.



From karl at xiph.org  Fri Dec 16 23:28:48 2005
From: karl at xiph.org (Karl Heyes)
Date: Fri, 16 Dec 2005 23:28:48 +0000
Subject: [Icecast] what is the queuesize?
In-Reply-To: <1134771099.2469.31.camel@localhost.localdomain>
References: <1134771099.2469.31.camel@localhost.localdomain>
Message-ID: <43A34DB0.40209@xiph.org>

Rakotomandimby Mihamina wrote:
> Hi, 
> In the Icecast configuration file, at the begining, there is a queuesize
> parameter.

The queue-size in the limits section is the default for all mountpoints 
unless you override it in a specific <mount> group.

> Is it an amount of bits? What bits?

The queue-size is specified in bytes, using bits as the measure is too 
precise.  It represents the trigger level at which the queue of stream 
data will be pruned, so can be seen as the maximum amount of stream data 
that icecast will store for a particular stream. Normally the queue of 
stream data is not so full, but if it does get full and the queue is to 
be pruned back then it will be because there is a listening client that 
is too slow for the stream bitrate and that listener will be dropped.

There is no one rule for the best size to use, a larger number just 
means a little more RAM can be taken up, obviously video streams 
generally have a higher bitrate so a larger queue size may be better in 
those cases.

karl.


From mihamina.rakotomandimby at etu.univ-orleans.fr  Sun Dec 18 11:57:15 2005
From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina)
Date: Sun, 18 Dec 2005 12:57:15 +0100
Subject: [Icecast] icecast as client, relay, retry time
Message-ID: <1134907035.11021.43.camel@localhost.localdomain>

Hi,
I relay a stream with an icecast 2 server.

I would like to set my Icecast to retry to relay each N seconds if the
stream I relay ever falls down (It may be 1 second, or 10, I dont know
yet...). What is the default relay retry timeout in Icecast? Where to
set it? I saw nothing about that in the configuration sample file,
"relay" section...

Thank you.

-- 
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.
Free hosting of CPS groupware: http://www.objectis.org.



From andy at earthsong.free-online.co.uk  Sun Dec 18 19:36:34 2005
From: andy at earthsong.free-online.co.uk (Andy Baxter)
Date: Sun, 18 Dec 2005 19:36:34 +0000
Subject: [Icecast] ices-kh60: latency bug
Message-ID: <200512181936.34788.andy@earthsong.free-online.co.uk>

hello,

I've just got ices-kh60 running with jack. It's working OK apart from a 
problem where the latency on the stream creeps up from about 15-20 secs to 
around 7 minutes. The stream plays OK, but the audio coming out is 7 minutes 
behind what goes in. I'm not sure how this can be happening, seeing as I 
don't think there are any buffers that long in the system, but it is. I've 
checked that it's not a problem with the player app I'm using (amarok), and 
it isn't - even if I reconnect the stream, there is still a long latency.

I suspect the problem is caused by running the stream for long periods with no 
audio input (zero sound level from an unconnected jack graph), as this is 
what seems to cause it.

any help with this would be appreciated.

andy baxter.


From karl at xiph.org  Sun Dec 18 20:27:12 2005
From: karl at xiph.org (Karl Heyes)
Date: Sun, 18 Dec 2005 20:27:12 +0000
Subject: [Icecast] ices-kh60: latency bug
In-Reply-To: <200512181936.34788.andy@earthsong.free-online.co.uk>
References: <200512181936.34788.andy@earthsong.free-online.co.uk>
Message-ID: <43A5C620.3070803@xiph.org>

Andy Baxter wrote:
> hello,
> 
> I've just got ices-kh60 running with jack. It's working OK apart from a 
> problem where the latency on the stream creeps up from about 15-20 secs to 
> around 7 minutes. The stream plays OK, but the audio coming out is 7 minutes 
> behind what goes in. I'm not sure how this can be happening, seeing as I 
> don't think there are any buffers that long in the system, but it is. I've 
> checked that it's not a problem with the player app I'm using (amarok), and 
> it isn't - even if I reconnect the stream, there is still a long latency.
> 
> I suspect the problem is caused by running the stream for long periods with no 
> audio input (zero sound level from an unconnected jack graph), as this is 
> what seems to cause it.

There are two places that spring to mind.

Icecast 2.2 did have a problem in certain cases when it came across 
digital silence. The problem manifested itself by increasing the burst 
at start-up (increasing latency), 2.3 did correct for this so doesn't 
suffer from it.

The data delivered to ices is regulated by jackd and it has been known 
that the jackd dummy driver has had next to useless timing, make sure 
you use the alsa driver in jackd.

karl.



From andy at earthsong.free-online.co.uk  Mon Dec 19 01:55:42 2005
From: andy at earthsong.free-online.co.uk (Andy Baxter)
Date: Mon, 19 Dec 2005 01:55:42 +0000
Subject: [Icecast] ices-kh60: latency bug
In-Reply-To: <43A5C620.3070803@xiph.org>
References: <200512181936.34788.andy@earthsong.free-online.co.uk>
	<43A5C620.3070803@xiph.org>
Message-ID: <200512190155.42276.andy@earthsong.free-online.co.uk>

On Sunday 18 Dec 2005 20:27, Karl Heyes wrote:
> Andy Baxter wrote:
> > hello,
> >
> > I've just got ices-kh60 running with jack. It's working OK apart from a
> > problem where the latency on the stream creeps up from about 15-20 secs
> > to around 7 minutes. The stream plays OK, but the audio coming out is 7
> > minutes behind what goes in. I'm not sure how this can be happening,
> > seeing as I don't think there are any buffers that long in the system,
> > but it is. I've checked that it's not a problem with the player app I'm
> > using (amarok), and it isn't - even if I reconnect the stream, there is
> > still a long latency.
> >
> > I suspect the problem is caused by running the stream for long periods
> > with no audio input (zero sound level from an unconnected jack graph), as
> > this is what seems to cause it.
>
> There are two places that spring to mind.
>
> Icecast 2.2 did have a problem in certain cases when it came across
> digital silence. The problem manifested itself by increasing the burst
> at start-up (increasing latency), 2.3 did correct for this so doesn't
> suffer from it.
>
> The data delivered to ices is regulated by jackd and it has been known
> that the jackd dummy driver has had next to useless timing, make sure
> you use the alsa driver in jackd.
>
> karl.

I just tried using icecast v2.3, and it's still an issue - at first it's 
slightly better with the latency starting off at around 10 seconds, but then 
it creeps up to several minutes as before (when the jack input is 
disconnected). This is with a jack graph that looks like this:

ecasound -> ices

and nothing feeding into ecasound.
(ecasound is there to provide a compressor plugin for the sound level)

I don't know what jack does with an empty input - whether it feeds it digital 
silence, or simply stops processing that part of the graph. In any case it's 
still happening. Jack is using the alsa plugin.


From dsrinivasmail at rediffmail.com  Thu Dec 22 10:15:42 2005
From: dsrinivasmail at rediffmail.com (srinivas  d)
Date: 22 Dec 2005 10:15:42 -0000
Subject: sir please let me know ([Icecast] Installation problem)
Message-ID: <20051222101542.24482.qmail@webmail29.rediffmail.com>

sir ,

I Have the following error , please let me know.
with kind regards
ds

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... i686-redhat-linux-gnu
checking host system type... i686-redhat-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking dependency style of g++... none
checking how to run the C++ preprocessor... /lib/cpp
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details

D.Srinivas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20051222/f7b8073e/attachment.htm>

From karl at xiph.org  Thu Dec 22 13:55:26 2005
From: karl at xiph.org (Karl Heyes)
Date: Thu, 22 Dec 2005 13:55:26 +0000
Subject: sir please let me know ([Icecast] Installation problem)
In-Reply-To: <20051222101542.24482.qmail@webmail29.rediffmail.com>
References: <20051222101542.24482.qmail@webmail29.rediffmail.com>
Message-ID: <43AAB04E.5070602@xiph.org>

srinivas d wrote:
> sir ,
> 
> I Have the following error , please let me know.
> with kind regards
> ds
> 
...
> checking whether we are using the GNU C++ compiler... no
> checking whether g++ accepts -g... no
> checking dependency style of g++... none
> checking how to run the C++ preprocessor... /lib/cpp
> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> See `config.log' for more details


is this version 2.3.1

karl




From bob at leanbackproductions.com  Fri Dec 23 20:55:32 2005
From: bob at leanbackproductions.com (Bob)
Date: Fri, 23 Dec 2005 20:55:32 +0000
Subject: [Icecast] WMP mp3 stream trouble
Message-ID: <122453440512231255l3f349491l98686e7877fe2d97@mail.gmail.com>

Hello everyone,

I made a big effort to provide an mp3 stream on my site to please the
unenlightened masses, and then I see in my logs that it doesn't work
in Windows Media Player.  Doh!  There's no Windows machine around to
test on so if anyone could help me out, I'd be very grateful.  I
couldn't find anything in the list's archive or on the web in general,
sorry.

Details:

The mp3 files are made from raw PCM data with
  lame --silent -r -x -s 44.1 -f -V 6 --vbr-new file.pcm file.mp3

The mp3 files are piped to ezstream 'stdin' and out to the web with
icecast.  The files are short (7 seconds) and are piped over and over
again.

It works fine with iTunes, RealPlayer, Winamp5.x, VLC, Whamb, but not WMP!
Here's a typical failed connection from the icecast access log

x.x.x.x - - [23/Dec/2005:12:28:24 -0700] "GET /slack HTTP/1.1" 200
14770 "-" "NSPlayer/10.0.0.3923 WMFSDK/10.0" 2
x.x.x.x - - [23/Dec/2005:12:28:29 -0700] "GET /slack HTTP/1.1" 200
45010 "-" "NSPlayer/10.0.0.3923 WMFSDK/10.0" 5
x.x.x.x - - [23/Dec/2005:12:28:29 -0700] "GET /slack HTTP/1.1" 200
7350 "-" "Windows-Media-Player/10.00.00.3923" 0
x.x.x.x - - [23/Dec/2005:12:33:40 -0700] "GET /slack HTTP/1.1" 200
3649530 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
.NET C

where x.x.x.x is the same IP each time.

To try the stream, please go to
http://leanbackproductions.com/streams/slack/
and click 'next' and then you'll see the mp3 link.

If you could send me the error message, that would be great!

Thanks and happy holidays,

Bob.


From karl at xiph.org  Sat Dec 24 01:37:20 2005
From: karl at xiph.org (Karl Heyes)
Date: Sat, 24 Dec 2005 01:37:20 +0000
Subject: [Icecast] WMP mp3 stream trouble
In-Reply-To: <122453440512231255l3f349491l98686e7877fe2d97@mail.gmail.com>
References: <122453440512231255l3f349491l98686e7877fe2d97@mail.gmail.com>
Message-ID: <43ACA650.8020603@xiph.org>

Bob wrote:
> Hello everyone,
> 
> I made a big effort to provide an mp3 stream on my site to please the
> unenlightened masses, and then I see in my logs that it doesn't work
> in Windows Media Player.  Doh!  There's no Windows machine around to
> test on so if anyone could help me out, I'd be very grateful.  I
> couldn't find anything in the list's archive or on the web in general,
> sorry.
> 
> Details:
> 
> The mp3 files are made from raw PCM data with
>   lame --silent -r -x -s 44.1 -f -V 6 --vbr-new file.pcm file.mp3
> 
> The mp3 files are piped to ezstream 'stdin' and out to the web with
> icecast.  The files are short (7 seconds) and are piped over and over
> again.
> 
> It works fine with iTunes, RealPlayer, Winamp5.x, VLC, Whamb, but not WMP!
> Here's a typical failed connection from the icecast access log

I don't know what is different about reading from network vs file, but 
VBR streams in WMP just don't work, although I understand that from file 
it's ok. CBR should be fine.

karl.




From henri.zikken at deltasolutions.nl  Sun Dec 25 14:04:41 2005
From: henri.zikken at deltasolutions.nl (Henri Zikken)
Date: Sun, 25 Dec 2005 15:04:41 +0100
Subject: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
In-Reply-To: <43AAB04E.5070602@xiph.org>
Message-ID: <000301c6095c$26c7b020$b301a8c0@henris>

We're abusing icecast in a true narrowcasting setup (personalized stream per
mountpoint). The streams itself are created in a piece of proprietory
(spelling?, i'm dutch) software, icecast merely relays them.

However, the intended endpoint is an embedded device. This device has
trouble with tcp/ip packets not matching the max. packet size (MSS or MSS
minus header). After eleborate testing, we found that using the sockopt
'TCP_CORK' instead of 'TCP_NODELAY' produces far better results on the field
on reconnects etc/. Also, with streaming media, TCP_CORK is more efficient
than TCP_NODELAY.

To patch icecast to use tcp_cork is a piece of cake, it involves no more
than 10 lines of code. My question would be if the maintainers would
consider bringing this into the main tree. It could be implemented as flag
for configure, of, (even better) as some setting in the config file.

I have already implemented this as configure flag. If this is considered
something usefull, i will submit the patch i created.

Regards,

Henri Zikken



From daleg at elemental.org  Mon Dec 26 16:31:14 2005
From: daleg at elemental.org (Dale Ghent)
Date: Mon, 26 Dec 2005 11:31:14 -0500
Subject: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
In-Reply-To: <000301c6095c$26c7b020$b301a8c0@henris>
References: <000301c6095c$26c7b020$b301a8c0@henris>
Message-ID: <1A50EF31-D8E2-4E94-A362-8A19BC84468F@elemental.org>


Make sure your patch accounts for the fact that not all platforms  
implement TCP_CORK.

/dale

On Dec 25, 2005, at 9:04 AM, Henri Zikken wrote:

> We're abusing icecast in a true narrowcasting setup (personalized  
> stream per
> mountpoint). The streams itself are created in a piece of proprietory
> (spelling?, i'm dutch) software, icecast merely relays them.
>
> However, the intended endpoint is an embedded device. This device has
> trouble with tcp/ip packets not matching the max. packet size (MSS  
> or MSS
> minus header). After eleborate testing, we found that using the  
> sockopt
> 'TCP_CORK' instead of 'TCP_NODELAY' produces far better results on  
> the field
> on reconnects etc/. Also, with streaming media, TCP_CORK is more  
> efficient
> than TCP_NODELAY.
>
> To patch icecast to use tcp_cork is a piece of cake, it involves no  
> more
> than 10 lines of code. My question would be if the maintainers would
> consider bringing this into the main tree. It could be implemented  
> as flag
> for configure, of, (even better) as some setting in the config file.
>
> I have already implemented this as configure flag. If this is  
> considered
> something usefull, i will submit the patch i created.
>
> Regards,
>
> Henri Zikken
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>



From Philipp at phflesch.de  Tue Dec 27 17:47:59 2005
From: Philipp at phflesch.de (Philipp Flesch)
Date: Tue, 27 Dec 2005 18:47:59 +0100
Subject: [Icecast] Best way downsample stream from 128 to 56 on the server?
Message-ID: <20051227184759.snrr4i9ockc0k8c0@webmail.wvb-gym.de>

Hi!
We want to over our stream in better quality (128 or 256) - but we still have
listeners using ISDN ... what's the best way to create a 56'er stream from the
128er send to the server?
The downsampling has to run on the debian streaming server.

Greetings from Germany

Philipp


From peter at theneb.co.uk  Tue Dec 27 20:20:51 2005
From: peter at theneb.co.uk (peter at theneb.co.uk)
Date: Tue, 27 Dec 2005 15:20:51 -0500
Subject: [Icecast] Best way downsample stream from 128 to 56 on the server?
In-Reply-To: <20051227184759.snrr4i9ockc0k8c0@webmail.wvb-gym.de>
References: <20051227184759.snrr4i9ockc0k8c0@webmail.wvb-gym.de>
Message-ID: <20051227152051.ioyohnjo4nc4ocws@www.theneb.co.uk>

Hi Phillipp,
It depends what software you are using, ourselves are using Darkice and it's
quite simply to create a second stream for 56k users.
What software are you using for source?

Quoting Philipp Flesch <Philipp at phflesch.de>:

> Hi!
> We want to over our stream in better quality (128 or 256) - but we still have
> listeners using ISDN ... what's the best way to create a 56'er stream 
> from the
> 128er send to the server?
> The downsampling has to run on the debian streaming server.
>
> Greetings from Germany
>
> Philipp
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>





From marius at flage.org  Tue Dec 27 20:35:47 2005
From: marius at flage.org (Marius Flage)
Date: Tue, 27 Dec 2005 21:35:47 +0100
Subject: [Icecast] Best way downsample stream from 128 to 56 on the server?
In-Reply-To: <20051227184759.snrr4i9ockc0k8c0@webmail.wvb-gym.de>
References: <20051227184759.snrr4i9ockc0k8c0@webmail.wvb-gym.de>
Message-ID: <43B1A5A3.7090705@flage.org>

Philipp Flesch skrev:
> We want to over our stream in better quality (128 or 256) - but we still have
> listeners using ISDN ... what's the best way to create a 56'er stream from the
> 128er send to the server?
> The downsampling has to run on the debian streaming server.

Use StreamTranscoder - http://www.oddsock.org/tools/streamTranscoder/.

Marius


From Philipp at phflesch.de  Wed Dec 28 08:59:42 2005
From: Philipp at phflesch.de (Philipp Flesch)
Date: Wed, 28 Dec 2005 09:59:42 +0100
Subject: [Icecast] Best way downsample stream from 128 to 56 on the server?
In-Reply-To: <20051227152051.ioyohnjo4nc4ocws@www.theneb.co.uk>
References: <20051227184759.snrr4i9ockc0k8c0@webmail.wvb-gym.de>
	<20051227152051.ioyohnjo4nc4ocws@www.theneb.co.uk>
Message-ID: <20051228095942.ax45yaxc84wks40s@webmail.wvb-gym.de>

Hi!
the problem is: we have to downsample the stream on the server. Creating a
second stream in darkice limits our bandwidth to much ...

Philipp




From k.j.wierenga at home.nl  Wed Dec 28 14:35:42 2005
From: k.j.wierenga at home.nl (Klaas Jan Wierenga)
Date: Wed, 28 Dec 2005 15:35:42 +0100
Subject: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
In-Reply-To: <000301c6095c$26c7b020$b301a8c0@henris>
Message-ID: <IPEHLPFNBAINJOFBPOBKMEBJGFAA.k.j.wierenga@home.nl>


Hi Henri and others,

Very interesting post about TCP_CORK. I would be very interested in having
it applied in the next version of Icecast.

I'm using Icecast in a somewhat narrowcasting setup with large numbers of
sources (> 100) and between 5 and 50 listeners per source. All streaming is
done at low bitrates (16 - 24 kbit/sec) and listeners use embedded devices
connected by 56k modems. It is therefore very important to have efficient
use of available bandwidth.

For low-bitrate streams the problem originates in the fact that the stream
source often produces many small packets (they should be using TCP_CORK
too!), which were passed on unchanged by icecast to each client (again as
small write() calls on each socket). This problem had been reduced a lot in
Icecast 2.3.0 as can be read from the release notes of 2.3.0:

Fixes for 2.3.0
...
* avoid small writes to reduce TCP overhead.

This core of this fix is in the complete_read function from format_mp3.c,
which is used in mp3_get_no_meta() and mp3_get_filter_meta().

/* This does the actual reading, making sure the read data is packaged in
 * blocks of 1400 bytes (near the common MTU size). This is because many
 * incoming streams come in small packets which could waste a lot of
 * bandwidth with many listeners due to headers and such like.
 */
static int complete_read (source_t *source)

As far as I can see this fix has been applied only for the mp3 format. I
guess the problem still remains for other formats, correct me if I am wrong.

However, if I understand correctly your TCP_CORK solution would apply to all
formats since it is applied on the client socket (irrespective of the
format). I would be very interested in having this patch and seeing it
applied to Icecast.

Cheers,
KJ

p.s. For an in depth analysis of TCP_CORK read Christiopher Baus' excelent
article: http://www.baus.net/on-tcp_cork

-----Oorspronkelijk bericht-----
Van: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org]Namens Henri
Zikken
Verzonden: zondag 25 december 2005 15:05
Aan: icecast at xiph.org
Onderwerp: [Icecast] Use of TCP_CORK instead of TCP_NODELAY


We're abusing icecast in a true narrowcasting setup (personalized stream per
mountpoint). The streams itself are created in a piece of proprietory
(spelling?, i'm dutch) software, icecast merely relays them.

However, the intended endpoint is an embedded device. This device has
trouble with tcp/ip packets not matching the max. packet size (MSS or MSS
minus header). After eleborate testing, we found that using the sockopt
'TCP_CORK' instead of 'TCP_NODELAY' produces far better results on the field
on reconnects etc/. Also, with streaming media, TCP_CORK is more efficient
than TCP_NODELAY.

To patch icecast to use tcp_cork is a piece of cake, it involves no more
than 10 lines of code. My question would be if the maintainers would
consider bringing this into the main tree. It could be implemented as flag
for configure, of, (even better) as some setting in the config file.

I have already implemented this as configure flag. If this is considered
something usefull, i will submit the patch i created.

Regards,

Henri Zikken

_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.7/214 - Release Date: 23-12-2005

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.7/214 - Release Date: 23-12-2005

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.8/215 - Release Date: 27-12-2005



From msmith at xiph.org  Wed Dec 28 16:13:55 2005
From: msmith at xiph.org (Michael Smith)
Date: Wed, 28 Dec 2005 17:13:55 +0100
Subject: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
In-Reply-To: <IPEHLPFNBAINJOFBPOBKMEBJGFAA.k.j.wierenga@home.nl>
References: <000301c6095c$26c7b020$b301a8c0@henris>
	<IPEHLPFNBAINJOFBPOBKMEBJGFAA.k.j.wierenga@home.nl>
Message-ID: <3c1737210512280813k75aa47c6je8c26d30089598e@mail.gmail.com>

>
> p.s. For an in depth analysis of TCP_CORK read Christiopher Baus' excelent
> article: http://www.baus.net/on-tcp_cork

Thanks for this pointer. I'd been meaning to reply on this thread, but
hadn't got around to it, primarily because I didn't really understand
TCP_CORK (the linux manpage is, as usual, fairly unclear on what
exactly it does). Now I understand!

>
> -----Oorspronkelijk bericht-----
> Van: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org]Namens Henri
> Zikken
> Verzonden: zondag 25 december 2005 15:05
> Aan: icecast at xiph.org
> Onderwerp: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
>
>
> We're abusing icecast in a true narrowcasting setup (personalized stream per
> mountpoint). The streams itself are created in a piece of proprietory
> (spelling?, i'm dutch) software, icecast merely relays them.
>
> However, the intended endpoint is an embedded device. This device has
> trouble with tcp/ip packets not matching the max. packet size (MSS or MSS
> minus header). After eleborate testing, we found that using the sockopt
> 'TCP_CORK' instead of 'TCP_NODELAY' produces far better results on the field
> on reconnects etc/. Also, with streaming media, TCP_CORK is more efficient
> than TCP_NODELAY.

This is pretty broken. There are really three possibilities. In order
of increasing maximum delay:
  1) TCP_NODELAY - what icecast uses, deliberately.
  2) default (Nagle) - we used to do this in icecast.
  3) TCP_CORK - what you've added

As a streaming server, it's fairly crucial for icecast to send out
data with as low a delay as possible (many clients don't care, but
some do). That's why we use TCP_NODELAY - we actually WANT to send out
data as soon as we can.

There are limits to how much overhead is reasonable to accept, which
is why we do some aggregation in userspace; this aggregation should
probably be tuned better, but it's important that icecast control it,
not the kernel.

You want TCP_CORK, it seems, because of bugs in your target devices -
well, whilst we're willing to make some concessions to broken clients,
an inability to speak TCP correctly is well outside what I consider
sensible, particularly given that it will degrade icecast's
performance for working clients (you remain welcome, of course, to
hack up your local copy). It's also very unportable.

Mike


From k.j.wierenga at home.nl  Wed Dec 28 15:54:16 2005
From: k.j.wierenga at home.nl (Klaas Jan Wierenga)
Date: Wed, 28 Dec 2005 16:54:16 +0100
Subject: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
In-Reply-To: <3c1737210512280813k75aa47c6je8c26d30089598e@mail.gmail.com>
Message-ID: <IPEHLPFNBAINJOFBPOBKMEBKGFAA.k.j.wierenga@home.nl>


Michael,

With regard to your comment below:

> As a streaming server, it's fairly crucial for icecast to send out
> data with as low a delay as possible (many clients don't care, but
> some do). That's why we use TCP_NODELAY - we actually WANT to send out
> data as soon as we can.

Can you explain how some clients depend on a low delay when receiving data
from icecast? How is the use of TCP_CORK going to break those? Would the
application level buffering currently used in format_mp3.c not cause the
same problem?

Is it that the (mp3/vorbis/...) frame rate should be as constant as possible
and maybe for VBR streams using TCP_CORK can cause problems in this area?

If I understand TCP_CORK correctly, it is not going to keep data from being
sent when it can fill a TCP packet to the MSS of the current connection. If
there is enough data in the kernel to fill a packet to the MSS, then it will
not be delayed because the socket has not been uncorked yet. I don't see a
difference with the application level buffering here.

> You (Henri) want TCP_CORK, it seems, because of bugs in your target
devices.

I know our device can handle any size TCP frame (upto MSS), but it would
certainly be more efficient if all frames were filled to MSS (536 for our
device).

Appreciate your comments.

KJ

p.s. Btw we're using a CBR stream as you might have guessed.


-----Oorspronkelijk bericht-----
Van: mlrsmith at gmail.com [mailto:mlrsmith at gmail.com]Namens Michael Smith
Verzonden: woensdag 28 december 2005 17:14
Aan: Klaas Jan Wierenga
CC: henri.zikken at deltasolutions.nl; icecast at xiph.org
Onderwerp: Re: [Icecast] Use of TCP_CORK instead of TCP_NODELAY


>
> p.s. For an in depth analysis of TCP_CORK read Christiopher Baus' excelent
> article: http://www.baus.net/on-tcp_cork

Thanks for this pointer. I'd been meaning to reply on this thread, but
hadn't got around to it, primarily because I didn't really understand
TCP_CORK (the linux manpage is, as usual, fairly unclear on what
exactly it does). Now I understand!

>
> -----Oorspronkelijk bericht-----
> Van: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org]Namens
Henri
> Zikken
> Verzonden: zondag 25 december 2005 15:05
> Aan: icecast at xiph.org
> Onderwerp: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
>
>
> We're abusing icecast in a true narrowcasting setup (personalized stream
per
> mountpoint). The streams itself are created in a piece of proprietory
> (spelling?, i'm dutch) software, icecast merely relays them.
>
> However, the intended endpoint is an embedded device. This device has
> trouble with tcp/ip packets not matching the max. packet size (MSS or MSS
> minus header). After eleborate testing, we found that using the sockopt
> 'TCP_CORK' instead of 'TCP_NODELAY' produces far better results on the
field
> on reconnects etc/. Also, with streaming media, TCP_CORK is more efficient
> than TCP_NODELAY.

This is pretty broken. There are really three possibilities. In order
of increasing maximum delay:
  1) TCP_NODELAY - what icecast uses, deliberately.
  2) default (Nagle) - we used to do this in icecast.
  3) TCP_CORK - what you've added

As a streaming server, it's fairly crucial for icecast to send out
data with as low a delay as possible (many clients don't care, but
some do). That's why we use TCP_NODELAY - we actually WANT to send out
data as soon as we can.

There are limits to how much overhead is reasonable to accept, which
is why we do some aggregation in userspace; this aggregation should
probably be tuned better, but it's important that icecast control it,
not the kernel.

You want TCP_CORK, it seems, because of bugs in your target devices -
well, whilst we're willing to make some concessions to broken clients,
an inability to speak TCP correctly is well outside what I consider
sensible, particularly given that it will degrade icecast's
performance for working clients (you remain welcome, of course, to
hack up your local copy). It's also very unportable.

Mike


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.8/215 - Release Date: 27-12-2005


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.8/215 - Release Date: 27-12-2005

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.8/215 - Release Date: 27-12-2005



From msmith at xiph.org  Wed Dec 28 17:03:15 2005
From: msmith at xiph.org (Michael Smith)
Date: Wed, 28 Dec 2005 18:03:15 +0100
Subject: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
In-Reply-To: <IPEHLPFNBAINJOFBPOBKMEBKGFAA.k.j.wierenga@home.nl>
References: <3c1737210512280813k75aa47c6je8c26d30089598e@mail.gmail.com>
	<IPEHLPFNBAINJOFBPOBKMEBKGFAA.k.j.wierenga@home.nl>
Message-ID: <3c1737210512280903yd1a6706g33ed35da9fbf751a@mail.gmail.com>

>
> Can you explain how some clients depend on a low delay when receiving data
> from icecast? How is the use of TCP_CORK going to break those? Would the
> application level buffering currently used in format_mp3.c not cause the
> same problem?

I imagine it would, yes. I don't use icecast for mp3 streaming,
though, personally, as I don't have a licensed encoder.

I can't think of any case where TCP_CORK would be appropriate for
icecast, though removing TCP_NODELAY (thus getting the default Nagle
algorithm behaviour) might help in some cases.

Mike


From oddsock at oddsock.org  Wed Dec 28 19:50:06 2005
From: oddsock at oddsock.org (oddsock)
Date: Wed, 28 Dec 2005 13:50:06 -0600
Subject: [Icecast] Best way downsample stream from 128 to 56 on the server?
In-Reply-To: <43B1A5A3.7090705@flage.org>
References: <20051227184759.snrr4i9ockc0k8c0@webmail.wvb-gym.de>
	<43B1A5A3.7090705@flage.org>
Message-ID: <7.0.0.16.2.20051228134816.04b0f158@oddsock.org>

also, if you are interested in trying the soon to be released v3 
version of streamTranscoder featuring a completely rewritten core and 
upgrade to using the oddcastv3 engine, try : 
http://www.oddsock.org/tools/streamTranscoderV3/

feedback is most welcome on this.

oddsock
At 02:35 PM 12/27/2005, Marius Flage wrote:
>Philipp Flesch skrev:
>>We want to over our stream in better quality (128 or 256) - but we still have
>>listeners using ISDN ... what's the best way to create a 56'er 
>>stream from the
>>128er send to the server?
>>The downsampling has to run on the debian streaming server.
>
>Use StreamTranscoder - http://www.oddsock.org/tools/streamTranscoder/.
>
>Marius
>_______________________________________________
>Icecast mailing list
>Icecast at xiph.org
>http://lists.xiph.org/mailman/listinfo/icecast




From karl at xiph.org  Wed Dec 28 21:08:33 2005
From: karl at xiph.org (Karl Heyes)
Date: Wed, 28 Dec 2005 21:08:33 +0000
Subject: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
In-Reply-To: <IPEHLPFNBAINJOFBPOBKMEBJGFAA.k.j.wierenga@home.nl>
References: <IPEHLPFNBAINJOFBPOBKMEBJGFAA.k.j.wierenga@home.nl>
Message-ID: <43B2FED1.9020105@xiph.org>

Klaas Jan Wierenga wrote:
> Hi Henri and others,
> 
> Very interesting post about TCP_CORK. I would be very interested in having
> it applied in the next version of Icecast.

I'd be more interested in some figures to show there being a benefit, 
most examples talk about HTTP servers with short lived connections where 
sendfile(2) is used.

> For low-bitrate streams the problem originates in the fact that the stream
> source often produces many small packets (they should be using TCP_CORK
> too!), which were passed on unchanged by icecast to each client (again as
> small write() calls on each socket). This problem had been reduced a lot in
> Icecast 2.3.0 as can be read from the release notes of 2.3.0:

This is exactly why it was implemented, a few people complained about 
the overhead with large numbers of listeners, not only because of the 
TCP overhead but also the fact that it reduces the write syscall 
overhead. Will TCP_CORK (linux) and TCP_NOPUSH (BSD) give noticable 
benefits wrt icecast? It might prove helpful if available but more info 
is needed.

> As far as I can see this fix has been applied only for the mp3 format. I
> guess the problem still remains for other formats, correct me if I am wrong.

It applies to all passthrough streams (ie mp3, aac*, nsv), Ogg is 
different as it has pages which are generally not really small.

karl



From henri.zikken at deltasolutions.nl  Wed Dec 28 23:39:02 2005
From: henri.zikken at deltasolutions.nl (Henri Zikken)
Date: Thu, 29 Dec 2005 00:39:02 +0100
Subject: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
Message-ID: <000101c60c07$e2710580$b301a8c0@henris>

> As a streaming server, it's fairly crucial for icecast to
> send out data with as low a delay as possible (many clients 
> don't care, but some do). That's why we use TCP_NODELAY - we 
> actually WANT to send out data as soon as we can.

Nagle is inherently unsuited for streams. NODELAY was (imho) ment for
connections for which Nagle isn't sufficient and CORK is not an option, i.e.
telnet.

Sending the data as soon as you can might not be the way to go, since this
has the potential to raise overhead significantly. I can explain this best
by grossly exxagerating, suppose i have an application that sends out 1 byte
at a time. Using NODELAY this would result in a dramatic increase of
overhead, since you would then basically use a 20 byte TCP header to send 1
byte, ie an overhead of 95%. If you reach a point where you think data
should be sent immediatly, you can also 'uncork' a connection, resulting in
the data being sent immediatly. 

Besides that, the biggest delay is the time the TCP packet spends to get to
it's intended destination (often > 10ms). NODELAY can lead to TCP packets
not being filled to their max, introducing extra delay because more packets
are being used.

Using CORK you make sure every TCP packet sent has been filled to it's
maximum payload. This minimizes the amount of packets used as well as
overhead.

> There are limits to how much overhead is reasonable to
> accept, which is why we do some aggregation in userspace; 
> this aggregation should probably be tuned better, but it's 
> important that icecast control it, not the kernel.

Why? What's the advantage? To me it looks more like creating an userspace
TCP/IP stack, and that doesnt seem usefull?
 
> You want TCP_CORK, it seems, because of bugs in your target
> devices 

That is my main motivation indeed, however, imho there are more valid
reasons to want TCP_CORK, as i tried to explain above.

>- well, whilst we're willing to make some concessions
> to broken clients, an inability to speak TCP correctly is 
> well outside what I consider sensible,

In your justification for nodelay, you state "(many clients don't care, but
some do)", isn't that the same thing?

> that it will degrade icecast's performance for working
> clients (you remain welcome, of course, to hack up your local 
> copy). 

In most cases it would, in my opinion, enhance icecasts' performance, since
the optimum TCP packet size is being used. CORK would normally result in a
more stable data throughput (because each packet is filled to max) using
less bandwidth (due to minimizing overhead).

> It's also very unportable.

It is, that's why my first proposal was to incorporate it as a ./configure
option. That way you can leave the default the way it is now, but give end
users the option of using it.

However i will cleanup the patch for distribution and then sent it to those
who requested it. I hope you'll reconsider applying it to the main tree.

Regards, 

Henri Zikken



From k.j.wierenga at home.nl  Thu Dec 29 20:25:55 2005
From: k.j.wierenga at home.nl (Klaas Jan Wierenga)
Date: Thu, 29 Dec 2005 21:25:55 +0100
Subject: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
In-Reply-To: <43B2FED1.9020105@xiph.org>
Message-ID: <IPEHLPFNBAINJOFBPOBKOEBNGFAA.k.j.wierenga@home.nl>


> This is exactly why it was implemented, a few people complained about
> the overhead with large numbers of listeners, not only because of the
> TCP overhead but also the fact that it reduces the write syscall
> overhead. Will TCP_CORK (linux) and TCP_NOPUSH (BSD) give noticable
> benefits wrt icecast? It might prove helpful if available but more info
> is needed.

As Christopher Baus points out in his article
http://www.baus.net/on-tcp_cork it is not so much the overhead of a few
write calls that affects performance, but the overhead in sending more
smaller packets. In my case sending small packets resulted in a lot of
interrupts (one or two for each packet sent) for many listeners listening to
low bitrate streams. This resulted in jerky playback because the machine
simply couldn't keep up. With icecast 2.3.0 the interrupt rate at the same
level of listeners has been reduced by more than 50%.

The question that still remains for me is why some clients would have a
problem with a lower packet rate of packets filled to the brim as opposed to
more packets that are partially filled (with the TCP/IP PSH flag set).

In our application it is extremely important to use the low bandwidth
available as efficient as possible to prevent buffer underflow and
connection stall.

Regards,
KJ


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/216 - Release Date: 29-12-2005



From karl at xiph.org  Fri Dec 30 00:34:49 2005
From: karl at xiph.org (Karl Heyes)
Date: Fri, 30 Dec 2005 00:34:49 +0000
Subject: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
In-Reply-To: <IPEHLPFNBAINJOFBPOBKOEBNGFAA.k.j.wierenga@home.nl>
References: <IPEHLPFNBAINJOFBPOBKOEBNGFAA.k.j.wierenga@home.nl>
Message-ID: <43B480A9.60107@xiph.org>

Klaas Jan Wierenga wrote:
>>This is exactly why it was implemented, a few people complained about
>>the overhead with large numbers of listeners, not only because of the
>>TCP overhead but also the fact that it reduces the write syscall
>>overhead. Will TCP_CORK (linux) and TCP_NOPUSH (BSD) give noticable
>>benefits wrt icecast? It might prove helpful if available but more info
>>is needed.
> 
> 
> As Christopher Baus points out in his article
> http://www.baus.net/on-tcp_cork it is not so much the overhead of a few
> write calls that affects performance, but the overhead in sending more
> smaller packets. In my case sending small packets resulted in a lot of
> interrupts (one or two for each packet sent) for many listeners listening to
> low bitrate streams. This resulted in jerky playback because the machine
> simply couldn't keep up. With icecast 2.3.0 the interrupt rate at the same
> level of listeners has been reduced by more than 50%.

I understand what you are saying about the interrupt rate, that is why I 
added the batching up of the read data, which applies to all platforms. 
The article in question doesn't deal with the exact same situation as 
icecast, for instance we don't want icecast to do say 100 write syscalls 
where each one is something like 50 bytes, for each listener. TCP_CORK 
or not, it's still wasteful.

TCP_CORK/TCP_NOPUSH may be useful (where available), but doing some 
tests would be the way forward, especially as 2.3 has helped your 
situation already.

karl.


From dmehler26 at woh.rr.com  Fri Dec 30 19:05:16 2005
From: dmehler26 at woh.rr.com (Dave)
Date: Fri, 30 Dec 2005 14:05:16 -0500
Subject: [Icecast] streaming to dialup users gives low quality audio
Message-ID: <003801c60d73$f8ad39a0$0900a8c0@satellite>

Hello,
    I've got two streams, one for broadband, one for dialup. Well, having 
had occation to use a dialup connection recently i checked the dialup 
stream. Although it was streaming what the broadband stream was, the audio 
quality was audibly worse. It didn't buffer, but it didn't sound as clear as 
the broadband stream. I used lame to encode the tracks to mp3 and used it's 
standard preset while doing it. In my ices.conf file for the dialup stream i 
originally had a samplerate of 22050, two chanels, and a bitrate of 24. I 
changed the bitrate up to 56, which resulted in a noticeable audio increase 
in quality but the buffering was unacceptable. If anyone has settings that 
work i would be interested in hearing about them.
Thanks.
Dave.



From lpmusix at gmail.com  Fri Dec 30 19:23:39 2005
From: lpmusix at gmail.com (Daniel Ballenger)
Date: Fri, 30 Dec 2005 11:23:39 -0800
Subject: [Icecast] streaming to dialup users gives low quality audio
In-Reply-To: <003801c60d73$f8ad39a0$0900a8c0@satellite>
References: <003801c60d73$f8ad39a0$0900a8c0@satellite>
Message-ID: <56755a70512301123t7bc16619p1dc4ca84c6ddb80c@mail.gmail.com>

This doesn't specifically answer your question, but is it possible for
you to use an ogg stream?

I've been running a stream using a 48Kbps ogg (i'm sure I could push
it lower too...) and it sounds to me and other people pretty much just
as "nice" as a 128Kbps mp3.  We can't notice it being audibly worse.

-Daniel
On 12/30/05, Dave <dmehler26 at woh.rr.com> wrote:
> Hello,
>     I've got two streams, one for broadband, one for dialup. Well, having
> had occation to use a dialup connection recently i checked the dialup
> stream. Although it was streaming what the broadband stream was, the audio
> quality was audibly worse. It didn't buffer, but it didn't sound as clear as
> the broadband stream. I used lame to encode the tracks to mp3 and used it's
> standard preset while doing it. In my ices.conf file for the dialup stream i
> originally had a samplerate of 22050, two chanels, and a bitrate of 24. I
> changed the bitrate up to 56, which resulted in a noticeable audio increase
> in quality but the buffering was unacceptable. If anyone has settings that
> work i would be interested in hearing about them.
> Thanks.
> Dave.
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>


--
Daniel Ballenger
http://denetron.com
Sr. Systems Administrator - Denetron LLC

From greg at orban.com  Fri Dec 30 19:32:53 2005
From: greg at orban.com (Greg J. Ogonowski)
Date: Fri, 30 Dec 2005 11:32:53 -0800
Subject: [Icecast] streaming to dialup users gives low quality audio
In-Reply-To: <003801c60d73$f8ad39a0$0900a8c0@satellite>
References: <003801c60d73$f8ad39a0$0900a8c0@satellite>
Message-ID: <6.2.3.4.2.20051230112858.057dfbf0@66.220.31.130>

This is another reason aacPlus is an advantage.
It is supported using Orban Opticodec-PC Streaming Encoder, Icecast2 
Servers and Winamp.

http://www.orban.com/orban/products/stream/1010_overview.html

Icecast2 Eval Stream here:

http://www.orban.com/orban/products/stream/orban_eval_ice.pls

-greg.



At 11:05 2005-12-30, Dave wrote:
>Hello,
>    I've got two streams, one for broadband, one for dialup. Well, 
> having had occation to use a dialup connection recently i checked 
> the dialup stream. Although it was streaming what the broadband 
> stream was, the audio quality was audibly worse. It didn't buffer, 
> but it didn't sound as clear as the broadband stream. I used lame 
> to encode the tracks to mp3 and used it's standard preset while 
> doing it. In my ices.conf file for the dialup stream i originally 
> had a samplerate of 22050, two chanels, and a bitrate of 24. I 
> changed the bitrate up to 56, which resulted in a noticeable audio 
> increase in quality but the buffering was unacceptable. If anyone 
> has settings that work i would be interested in hearing about them.
>Thanks.
>Dave.
>
>_______________________________________________
>Icecast mailing list
>Icecast at xiph.org
>http://lists.xiph.org/mailman/listinfo/icecast


__________________________________________________________________________
Greg J. Ogonowski
VP Product Development
ORBAN / CRL, Inc.
1525 Alvarado St.
San Leandro, CA  94577  USA
TEL +1 510 351-3500
FAX +1 510 351-0500
greg at orban.com
http://www.orban.com



From dmehler26 at woh.rr.com  Fri Dec 30 19:26:06 2005
From: dmehler26 at woh.rr.com (Dave)
Date: Fri, 30 Dec 2005 14:26:06 -0500
Subject: [Icecast] streaming to dialup users gives low quality audio
References: <003801c60d73$f8ad39a0$0900a8c0@satellite>
	<56755a70512301123t7bc16619p1dc4ca84c6ddb80c@mail.gmail.com>
Message-ID: <006101c60d76$e176d040$0900a8c0@satellite>

Hi,
    Currently streaming ogg isn't practical in this situation. That was one 
of the first things i checked into. WHen i looked i didn't see a streamer 
that did both ogg and mp3.
Thanks.
Dave.

----- Original Message ----- 
From: "Daniel Ballenger" <lpmusix at gmail.com>
To: "Dave" <dmehler26 at woh.rr.com>
Cc: <icecast at xiph.org>
Sent: Friday, December 30, 2005 2:23 PM
Subject: Re: [Icecast] streaming to dialup users gives low quality audio


> This doesn't specifically answer your question, but is it possible for
> you to use an ogg stream?
>
> I've been running a stream using a 48Kbps ogg (i'm sure I could push
> it lower too...) and it sounds to me and other people pretty much just
> as "nice" as a 128Kbps mp3.  We can't notice it being audibly worse.
>
> -Daniel
> On 12/30/05, Dave <dmehler26 at woh.rr.com> wrote:
>> Hello,
>>     I've got two streams, one for broadband, one for dialup. Well, having
>> had occation to use a dialup connection recently i checked the dialup
>> stream. Although it was streaming what the broadband stream was, the 
>> audio
>> quality was audibly worse. It didn't buffer, but it didn't sound as clear 
>> as
>> the broadband stream. I used lame to encode the tracks to mp3 and used 
>> it's
>> standard preset while doing it. In my ices.conf file for the dialup 
>> stream i
>> originally had a samplerate of 22050, two chanels, and a bitrate of 24. I
>> changed the bitrate up to 56, which resulted in a noticeable audio 
>> increase
>> in quality but the buffering was unacceptable. If anyone has settings 
>> that
>> work i would be interested in hearing about them.
>> Thanks.
>> Dave.
>>
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
>>
>
>
> --
> Daniel Ballenger
> http://denetron.com
> Sr. Systems Administrator - Denetron LLC
> 



From engineering at owltechnology.net  Fri Dec 30 19:41:32 2005
From: engineering at owltechnology.net (Engineering)
Date: Fri, 30 Dec 2005 13:41:32 -0600
Subject: [Icecast] how to add dynamic relaying to icecast
In-Reply-To: <6.2.3.4.2.20051230112858.057dfbf0@66.220.31.130>
Message-ID: <001b01c60d79$0e968ff0$6403a8c0@Memphis>

Anybody on this list know how to create dynamic relaying with icecast
servers?

I have an icecast server and I would like to give my users the ability to
stream their content from anywhere they are using an username and password
combination.

I have researched the web and have found references to rtptools, I know I
should be able to set up a port to listen on and reroute that stream to the
icecast server, but when I try it I get nothing.

Any suggestions, hints or examples would be appreciated.





From lpmusix at gmail.com  Fri Dec 30 19:46:34 2005
From: lpmusix at gmail.com (Daniel Ballenger)
Date: Fri, 30 Dec 2005 11:46:34 -0800
Subject: [Icecast] streaming to dialup users gives low quality audio
In-Reply-To: <006101c60d76$e176d040$0900a8c0@satellite>
References: <003801c60d73$f8ad39a0$0900a8c0@satellite>
	<56755a70512301123t7bc16619p1dc4ca84c6ddb80c@mail.gmail.com>
	<006101c60d76$e176d040$0900a8c0@satellite>
Message-ID: <56755a70512301146p682e351ftaa38f30bd87aa7b8@mail.gmail.com>

Ezstream can take both mp3's and ogg's and feed them as oggs (or mp3)
to icecast.

I've recently submit a patch to allow you to have ezstream pull the
next song from a program as well, if you need that support.

-Daniel
On 12/30/05, Dave <dmehler26 at woh.rr.com> wrote:
> Hi,
>     Currently streaming ogg isn't practical in this situation. That was one
> of the first things i checked into. WHen i looked i didn't see a streamer
> that did both ogg and mp3.
> Thanks.
> Dave.
>
> ----- Original Message -----
> From: "Daniel Ballenger" <lpmusix at gmail.com>
> To: "Dave" <dmehler26 at woh.rr.com>
> Cc: <icecast at xiph.org>
> Sent: Friday, December 30, 2005 2:23 PM
> Subject: Re: [Icecast] streaming to dialup users gives low quality audio
>
>
> > This doesn't specifically answer your question, but is it possible for
> > you to use an ogg stream?
> >
> > I've been running a stream using a 48Kbps ogg (i'm sure I could push
> > it lower too...) and it sounds to me and other people pretty much just
> > as "nice" as a 128Kbps mp3.  We can't notice it being audibly worse.
> >
> > -Daniel
> > On 12/30/05, Dave <dmehler26 at woh.rr.com> wrote:
> >> Hello,
> >>     I've got two streams, one for broadband, one for dialup. Well, having
> >> had occation to use a dialup connection recently i checked the dialup
> >> stream. Although it was streaming what the broadband stream was, the
> >> audio
> >> quality was audibly worse. It didn't buffer, but it didn't sound as clear
> >> as
> >> the broadband stream. I used lame to encode the tracks to mp3 and used
> >> it's
> >> standard preset while doing it. In my ices.conf file for the dialup
> >> stream i
> >> originally had a samplerate of 22050, two chanels, and a bitrate of 24. I
> >> changed the bitrate up to 56, which resulted in a noticeable audio
> >> increase
> >> in quality but the buffering was unacceptable. If anyone has settings
> >> that
> >> work i would be interested in hearing about them.
> >> Thanks.
> >> Dave.
> >>
> >> _______________________________________________
> >> Icecast mailing list
> >> Icecast at xiph.org
> >> http://lists.xiph.org/mailman/listinfo/icecast
> >>
> >
> >
> > --
> > Daniel Ballenger
> > http://denetron.com
> > Sr. Systems Administrator - Denetron LLC
> >
>
>


--
Daniel Ballenger
http://denetron.com
Sr. Systems Administrator - Denetron LLC

From k.j.wierenga at home.nl  Fri Dec 30 19:13:23 2005
From: k.j.wierenga at home.nl (Klaas Jan Wierenga)
Date: Fri, 30 Dec 2005 20:13:23 +0100
Subject: [Icecast] Use of TCP_CORK instead of TCP_NODELAY
In-Reply-To: <43B480A9.60107@xiph.org>
Message-ID: <IPEHLPFNBAINJOFBPOBKAECAGFAA.k.j.wierenga@home.nl>


> TCP_CORK/TCP_NOPUSH may be useful (where available), but doing some
> tests would be the way forward, especially as 2.3 has helped your
> situation already.

I see you point Karl... good is good enough.
Henri, can you supply me with the patch so I can check it for our setup
streaming to dial-up listeners? We do experience the occasional disconnect
of a listener, but it'll take a lot of testing to quantify an improvement.
Moreover, since there are so many networks between the source, our streaming
server and the listerener, it'll be hard to pinpoint the exact cause of the
problem when a listener is disconnected. I'm willing to give it a try.

Thanks for all your comments.

Regards,
KJ
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/216 - Release Date: 29-12-2005



From k.j.wierenga at home.nl  Fri Dec 30 19:30:56 2005
From: k.j.wierenga at home.nl (Klaas Jan Wierenga)
Date: Fri, 30 Dec 2005 20:30:56 +0100
Subject: [Icecast] streaming to dialup users gives low quality audio
In-Reply-To: <003801c60d73$f8ad39a0$0900a8c0@satellite>
Message-ID: <IPEHLPFNBAINJOFBPOBKKECAGFAA.k.j.wierenga@home.nl>


There are two things that caught my attention in this post.

When you say 22050 kHz sampling rate, two channels and bitrate 24. Do you
mean 24 kbps stereo (which would be 12 kbps per channel, i.e. real bad audio
quality), or 48 kpbs stereo (24 kbps for each channel).

When you talk about dial-up, do you mean analog dial-up that is limited to
56 kbit/sec? In that case streaming at 48kbps is pushing it since many
dial-up connections won't reach that speed because of bad line quality. The
safest way to go is to stream in mono and don't push the bitrate beyond
24kbps or 32kbps if you really must.

KJ

-----Oorspronkelijk bericht-----
Van: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org]Namens
Dave
Verzonden: vrijdag 30 december 2005 20:05
Aan: icecast at xiph.org
Onderwerp: [Icecast] streaming to dialup users gives low quality audio


Hello,
    I've got two streams, one for broadband, one for dialup. Well, having
had occation to use a dialup connection recently i checked the dialup
stream. Although it was streaming what the broadband stream was, the audio
quality was audibly worse. It didn't buffer, but it didn't sound as clear as
the broadband stream. I used lame to encode the tracks to mp3 and used it's
standard preset while doing it. In my ices.conf file for the dialup stream i
originally had a samplerate of 22050, two chanels, and a bitrate of 24. I
changed the bitrate up to 56, which resulted in a noticeable audio increase
in quality but the buffering was unacceptable. If anyone has settings that
work i would be interested in hearing about them.
Thanks.
Dave.

_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/216 - Release Date: 29-12-2005


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/216 - Release Date: 29-12-2005

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/216 - Release Date: 29-12-2005



From danstowell at gmail.com  Fri Dec 30 22:13:55 2005
From: danstowell at gmail.com (Dan Stowell)
Date: Fri, 30 Dec 2005 22:13:55 +0000
Subject: [Icecast] [OT] WiFi radios
Message-ID: <286e6b7c0512301413i711d3850w@mail.gmail.com>

Hi -

Off-topic, but slightly related since it's a device that can listen to
icecast streams. We've just bought one of these devices at home and
it's absolutely great:

http://www.acoustic-energy.co.uk/Product_range/WiFi_radio/WiFi.asp

Not the first wifi radio ever, I know, but the unit is really
impressive. Good sound quality, and decent interface. And they claim
that it a future firmware upgrade it'll support Ogg Vorbis (only
MP3/WMA/Real at the moment)...

Dan
--
http://www.flatfourradio.co.uk


From bcasci at runbox.com  Fri Dec 30 23:17:24 2005
From: bcasci at runbox.com (Brandon)
Date: Fri, 30 Dec 2005 18:17:24 -0500
Subject: [Icecast] [OT] WiFi radios
In-Reply-To: <286e6b7c0512301413i711d3850w@mail.gmail.com>
References: <286e6b7c0512301413i711d3850w@mail.gmail.com>
Message-ID: <43B5C004.5040104@runbox.com>

Not to judge a book by its cover, but it looks like one of those science 
projects kits from a 1985 Radio Shack catalog.

Dan Stowell wrote:

>Hi -
>
>Off-topic, but slightly related since it's a device that can listen to
>icecast streams. We've just bought one of these devices at home and
>it's absolutely great:
>
>http://www.acoustic-energy.co.uk/Product_range/WiFi_radio/WiFi.asp
>
>Not the first wifi radio ever, I know, but the unit is really
>impressive. Good sound quality, and decent interface. And they claim
>that it a future firmware upgrade it'll support Ogg Vorbis (only
>MP3/WMA/Real at the moment)...
>
>Dan
>--
>http://www.flatfourradio.co.uk
>_______________________________________________
>Icecast mailing list
>Icecast at xiph.org
>http://lists.xiph.org/mailman/listinfo/icecast
>
>  
>


From geoff at hitsandpieces.net  Sat Dec 31 01:21:22 2005
From: geoff at hitsandpieces.net (Geoff Shang)
Date: Sat, 31 Dec 2005 11:21:22 +1000 (EST)
Subject: [Icecast] how to add dynamic relaying to icecast
In-Reply-To: <001b01c60d79$0e968ff0$6403a8c0@Memphis>
References: <001b01c60d79$0e968ff0$6403a8c0@Memphis>
Message-ID: <Pine.LNX.4.64.0512311118590.725@data.home>

Engineering wrote:

> Anybody on this list know how to create dynamic relaying with icecast
> servers?
>
> I have an icecast server and I would like to give my users the ability to
> stream their content from anywhere they are using an username and password
> combination.

I assume you mean that you want Icecast to relay a stream that's on some 
other server.

Best way I can see to do this is for you to have some kind of script update 
the config file then send Icecast a HUP signal so the new relay takes 
effect.

Geoff.



From geoff at hitsandpieces.net  Sat Dec 31 01:46:35 2005
From: geoff at hitsandpieces.net (Geoff Shang)
Date: Sat, 31 Dec 2005 11:46:35 +1000 (EST)
Subject: [Icecast] streaming to dialup users gives low quality audio
In-Reply-To: <003801c60d73$f8ad39a0$0900a8c0@satellite>
References: <003801c60d73$f8ad39a0$0900a8c0@satellite>
Message-ID: <Pine.LNX.4.64.0512311122150.725@data.home>

Dave wrote:

> Hello,
>   I've got two streams, one for broadband, one for dialup. Well, having had 
> occation to use a dialup connection recently i checked the dialup stream. 
> Although it was streaming what the broadband stream was, the audio quality 
> was audibly worse. It didn't buffer, but it didn't sound as clear as the 
> broadband stream.

This is expected.  If dialup streams sounded as good as broadband streams, 
everyone would just use dialup streams.

> I used lame to encode the tracks to mp3 and used it's 
> standard preset while doing it. In my ices.conf file for the dialup stream i 
> originally had a samplerate of 22050, two chanels, and a bitrate of 24.

This is going to sound pretty horrible, since MP3 can't really do 22.05kHz 
at 24kbps stereo.

> I 
> changed the bitrate up to 56, which resulted in a noticeable audio increase 
> in quality but the buffering was unacceptable. If anyone has settings that 
> work i would be interested in hearing about them.

You're not going to be able to send 56kbps over a modem, as has been stated 
already.  IMHO, 40kbps would probably be your absolute top for a 56k modem. 
If you want to be accessible to 33.6/28.8k modems, don't go any higher than 
24kbps.

At this rate, you hit the stereo vs mono argument.  If you want clearer 
audio, go mono.  But if you want stereo, you'll have poorer audio.

In my experience, you can get acceptable audio at 24kbps mono with 22.05kHz 
or 24kbps stereo with 11.025kHz.  Note that these aren't the LAME default 
sampling rates for these bit rates.

If you want to go 40kbps, some quick informal testing gives the following 
results:

Stereo: LAME default is 16kHz, but to my ears, you can get acceptable 
results at 22.05kHz.

Mono. LAME default is 24kHz, but 32kHz sounds just fine.  44.1kHz is 
starting to push it, but since it gets rolled off anyway, there's really no 
point in going that high.

At 32kbps, LAME's defaults are 16kHz stereo and 22.05kHz mono, and these 
are what I'd probably recommend.

This is just from some quick informal testing, you should probably listen 
yourself and see what you like.

For quick and dirty testing, I used:

lame --quiet -b <bitrate> [-a] [--resample <samplerate>] <infile.wav> - 
|mpg123 -

Where -a is for mono, and --resample is for changing the sample rate from 
the default.

Oh and you should use a relatively recent LAME release like 3.96.  Versions 
prior to 3.93 or so had noticeably poorer audio at lower sampling rates.

Of course, other codecs will perform better.  I'd advocate for Ogg Vorbis 
myself.

Hope this helps,

Geoff.



From greg at orban.com  Sat Dec 31 02:21:39 2005
From: greg at orban.com (Greg J. Ogonowski)
Date: Fri, 30 Dec 2005 18:21:39 -0800
Subject: [Icecast] streaming to dialup users gives low quality audio
In-Reply-To: <Pine.LNX.4.64.0512311122150.725@data.home>
References: <003801c60d73$f8ad39a0$0900a8c0@satellite>
	<Pine.LNX.4.64.0512311122150.725@data.home>
Message-ID: <6.2.3.4.2.20051230181642.057e8150@66.220.31.130>

Until aacPlus, it was impossible to get decent sounding dial-up audio 
quality on an Internet audio stream.  aacPlus changes everything.

The reason why broadband audio streams happened was to improve the 
quality, since at the time it too 128kbps of MP3 to do it.  Ogg 
Vorbis reduces this to about 64kbps, but still not good enough for 
dial-up.  Broadband is no long absolutely necessary for 
"entertainment grade" audio.

Here is a 32kbps stereo stream as proof:
http://www.orban.com/orban/products/stream/orban_eval_ice.pls
Listen using Winamp or foobar2000.

-greg.



At 17:46 2005-12-30, Geoff Shang wrote:
>Dave wrote:
>
>>Hello,
>>   I've got two streams, one for broadband, one for dialup. Well, 
>> having had occation to use a dialup connection recently i checked 
>> the dialup stream. Although it was streaming what the broadband 
>> stream was, the audio quality was audibly worse. It didn't buffer, 
>> but it didn't sound as clear as the broadband stream.
>
>This is expected.  If dialup streams sounded as good as broadband 
>streams, everyone would just use dialup streams.
>
>>I used lame to encode the tracks to mp3 and used it's standard 
>>preset while doing it. In my ices.conf file for the dialup stream i 
>>originally had a samplerate of 22050, two chanels, and a bitrate of 24.
>
>This is going to sound pretty horrible, since MP3 can't really do 
>22.05kHz at 24kbps stereo.
>
>>I changed the bitrate up to 56, which resulted in a noticeable 
>>audio increase in quality but the buffering was unacceptable. If 
>>anyone has settings that work i would be interested in hearing about them.
>
>You're not going to be able to send 56kbps over a modem, as has been 
>stated already.  IMHO, 40kbps would probably be your absolute top 
>for a 56k modem. If you want to be accessible to 33.6/28.8k modems, 
>don't go any higher than 24kbps.
>
>At this rate, you hit the stereo vs mono argument.  If you want 
>clearer audio, go mono.  But if you want stereo, you'll have poorer audio.
>
>In my experience, you can get acceptable audio at 24kbps mono with 
>22.05kHz or 24kbps stereo with 11.025kHz.  Note that these aren't 
>the LAME default sampling rates for these bit rates.
>
>If you want to go 40kbps, some quick informal testing gives the 
>following results:
>
>Stereo: LAME default is 16kHz, but to my ears, you can get 
>acceptable results at 22.05kHz.
>
>Mono. LAME default is 24kHz, but 32kHz sounds just fine.  44.1kHz is 
>starting to push it, but since it gets rolled off anyway, there's 
>really no point in going that high.
>
>At 32kbps, LAME's defaults are 16kHz stereo and 22.05kHz mono, and 
>these are what I'd probably recommend.
>
>This is just from some quick informal testing, you should probably 
>listen yourself and see what you like.
>
>For quick and dirty testing, I used:
>
>lame --quiet -b <bitrate> [-a] [--resample <samplerate>] 
><infile.wav> - |mpg123 -
>
>Where -a is for mono, and --resample is for changing the sample rate 
>from the default.
>
>Oh and you should use a relatively recent LAME release like 
>3.96.  Versions prior to 3.93 or so had noticeably poorer audio at 
>lower sampling rates.
>
>Of course, other codecs will perform better.  I'd advocate for Ogg 
>Vorbis myself.
>
>Hope this helps,
>
>Geoff.
>
>_______________________________________________
>Icecast mailing list
>Icecast at xiph.org
>http://lists.xiph.org/mailman/listinfo/icecast


__________________________________________________________________________
Greg J. Ogonowski
VP Product Development
ORBAN / CRL, Inc.
1525 Alvarado St.
San Leandro, CA  94577  USA
TEL +1 510 351-3500
FAX +1 510 351-0500
greg at orban.com
http://www.orban.com



From dmehler26 at woh.rr.com  Sat Dec 31 23:04:33 2005
From: dmehler26 at woh.rr.com (Dave)
Date: Sat, 31 Dec 2005 18:04:33 -0500
Subject: [Icecast] O.T. converting mp3's to wavs for burning
Message-ID: <003101c60e5e$906c01f0$0900a8c0@satellite>

Hello,
    I've got mp3's that i converted from CD wavs using abcde to do the 
conversion. Now i need to take those mp3's and return them to either cdda or 
wav for playing in players that do not support mp3. I was thinking lame 
could do this but am uncertain how to do this. My goal is to do this with a 
minimum loss of quality.
    Please respond offlist if necessary.
Thanks.
Dave.