[Icecast] Persistent audio streams?

[Ralph Giles]

On Sat, Jan 22, 2005 at 07:20:46PM -0800, Jeff Simmons wrote:

> I've been experimenting with running an internet audio stream to the remote 
> site. Our ISP has a direct route from the local studio to the remote 
> transmitter (over their backbone and then to the remote via high speed 
> wireless, about 5 hops). I've set up ice2 and icecast, and I'm getting a very 
> nice Ogg Vorbis stream off their line output before it goes to the local 
> transmitter.
> 
> I've been monitoring the stream from my place (via 3m/384k ASDL, about 16 
> hops). My problem is that the various clients I've tried (WinAmp, XMMS, 
> Foobar) all ending up dropping the stream eventually. I have yet to get a 
> stream that was still going after 24 hours.

The question is, why are the clients dropping? It could be your net 
flaking out. I've even heard of some ISPs cutting connections every
24 hours. If you have a leased line to the second transmitter, this 
shouldn't be an issue in practice.

Another issue, as I understand it, is lack of sync between the two audio 
cards. The clocks in consumer audio hardware are very precise, but not 
accurate at all. If the playback clock is faster than the recording 
clock, the network receive buffer will eventually overflow, which should 
cause the client to pause playback and continue after the buffer refills, 
producing a glitch. If, on the other hand, the playback clock is slower 
than the recording clock, the transmit queue on the icecast server will
grow until it hits a predefined limit, at which point icecast drops the
connection to bound its resource usage.

IIRC usually the clock skews result in drops after a week or two, not a 
day, but it's withing the realm of possibility. I can suggest a couple 
of things:

Adjust the playback receive buffer (easy on many clients) and the 
icecast send buffer limit (recompile, I think) and see if they 
correllate with drop frequency. This would positively identify the 
problem. So, of course, would just instrumenting the drop.

Just try different combinations of audio hardware until you find one 
that's a closer match.

Make sure the client that drives the second transmitter restarts if the 
stream ever drops. (obviously :)

Use professional quality sound cards. They would (hopefully) be more 
accurate, or you can use an external source of known accuracy with cards 
that support an external word clock.

It's in theory possible to hack the source/playback clients to compare 
the audio clock against ntp time and stretch/compress the digital audio 
stream to enforce the nominal sample rate at both ends. This might be a 
generally useful feature if you'd like to contribute something. :)

Hope that's of some help,
 -r