On 22 Mar 1999, Sean Doran wrote:

> 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).

That's what my player does too. With my ISP, that strategy is not good
enough :-(

> 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.

That's what I mean.

> 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.

I guess I should go read that. I suppose that when retransmissions are
simply omitted, some compensation in the sequence numbers must be done
so that the receiving end does not see anything strange.

>         Sean.
-Olaf.
--
___ Olaf 'Rhialto' Seibert - rhialto@polder.ubc. ---- Unauthorized duplication,
\X/ .kun.nl ---- while sometimes necessary, is never as good as the real thing.