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