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@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/listinfo/linux-audio-user > > _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
