Olaf Seibert <rhialto@polder.ubc.kun.nl> writes:

> > To react like RealAudio does to changing network conditions, I'd think
> > it would need to use variable bit rate encoding (and multiple copies
> > of the encoded files on the server side?) 

That's one approach.  However, antoher approach -- which
one can see Real* taking when the network is congested --
is to use a buffer to impose a varying delay on the
playback of data received from the network, to smooth out
congestion-related dropped and delayed packets.  The more
congested the network, the bigger the buffer (and thus the
longer the delay).

Who knows what the RealAudio stuff really does beyond that?

> In any case, shoutcast is certainly not perfect yet, since it runs over
> TCP (HTTP even), and TCP is indeed not very well suited to this sort of
> thing.

TCP is very well suited to "playback" material, although
because TCP retransmits lost segments and the time it
takes for a retransmitted segment to arrive at the
listening client, the buffering requirements in the face
of a badly-congested network can be quite large.

For "live" traffic, a better approach is to use RFC2001
congestion avoidance without TCP-style retransmissions,
which also eliminates the server's need to buffer a
congestion window per-client.   Forward error correction
information can mitigate "choppy" playback due to
individual lost segments during slow start and congestion avoidance.

        Sean.