On 09/07/2010 01:39 PM, Julien Claassen wrote:
'Owdo again!
Now that I've icecast running with ices as a feeder, I wonder, if I can
turn down latency. In icecast I set the burst-size to 0 and in ices I
set realtime. Still the delay is considereable. Is there any chance of
tuning this setup further to reduce latency?
If it helps, I will post my ices.xml and my icecast.xml.
the latency is usually bounded by the client buffer.
additionally, it can be irritating that streams that start with silence
seem to exhibit immense latency. the reason is that the size of the
client buffer is usually not defined in seconds but in bytes. ogg vorbis
for example tends to encode silence at very nearly 0 bit/s, so you can
imagine it takes a while for a silent stream to fill the client buffer,
and any subsequent programme material will appear to be severely delayed.
doing away with client buffering is dangerous, because it makes the
client very susceptible to drop-outs.
as to the burst-size, it can be useful, too. say you have a burst-size
of 64kbyte at 128kbit/s, that means the server will push out the data
from (now - 4s) to (now) in one burst transfer. if your client has 64
kbytes of input buffer, it will have a playback latency of those 4 s,
but it will start playing *now* (thanks to the burst filling its buffer
almost immediately). that can improve the user experience.
so unless you don't use client buffering at all, burst-sizes >0 will
generally not cause extra latency.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
