Re: [LAU] Tuning icecast/ices for low latency

Hi,

You have also to notice that, in the case of a _none_ PCM music streaming format
like mp3 or ogg, the encoder usually needs several input buffers to process its
own frequency, amplitude analysis and then matricing. So, whereas the size of
this chunk is varying with the bitrate and the requested quality, it is
impossible to get a very low latency between the (PCM) source and the
broadcasted stream sent to the icecast server (+ the icecast's own buffer).

But, if you _really_ need some low latencies and bitrates, checkout this codec
which tends to reduce those latencies drastically:
http://www.celt-codec.org/

I don't know, however how this codec is supported by main players...
Who knows ? Would this be also streamable through icecast nodes ?

Cheers,
Yomguy

Le 09/09/2010 19:35, Jörn Nettingsmeier a écrit :
> 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@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>
>

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Fri Sep 10 00:15:05 2010