Jean-Marc Coursimault
2016-Oct-19 07:57 UTC
[Icecast] Increasing Icecast input buffering ?
Hello, My question is : is there a way to have Icecast buffer the input / increase the input buffering ? Even though the latency would increase ? Why : On some radio streams, the listeners to a Icecast stream experience very frequent silences / disconnections. I strongly suspect that the source has a slow/bursty connection to Icecast so that the data sent to the Icecast server arrives in too discontinuous chunks, even though the average connection speed is ok. What's more, they tell me that the Icecast output is in advance vs the actual radio broadcast (through a link to their FM emitter). So I guess that their emitter has some sort of buffering. Thanks -- JM
Good morning, On Wed, 2016-10-19 at 09:57 +0200, Jean-Marc Coursimault wrote:> Hello, > > My question is : is there a way to have Icecast buffer the input / > increase the input buffering ? Even though the latency would increase ?> Why : On some radio streams, the listeners to a Icecast stream > experience very frequent silences / disconnections.There is no input buffer in Icecast2 at all: Icecast2 forwards the data as fast as it can (from source to listener). Icecast itself has no idea of time (that would require Icecast to interact with the data itself). That is why. There is the queue (the size of the queue can be configured, see the manual). The queue is a single buffer that allows jitters in transmission. But that is not a buffer that belongs to the input or output side. It's kind of both of the same time. When the source sends data it's append to the queue. When the data got transmitted to all clients the tail of the queue is removed. (It's a kind of a ring buffer). In case Icecast2 itself disconnects any listener that is because the client fall to much behind (reached the tail of the queue). That is normally caused by clients that can not receive or process the data at the speed (bitrate) the source sends. In case Icecast2 itself source that is because of source timeout (can also be configured). That is a timeout to disconnect stalled source connections. Basically Icecast2 expect the source to send at least some data within this timeout interval. Both cases are logged in the error.log (see your config). Consider to raise the debug level to 'debug' (4) to get a more verbose output. Another cause could be that clients for some reason disconnect. That can e.g. happen in case the client has some network or processing trouble. If none of the above seems to be happening I would suggest to increase the client's buffer and see if that fixes the problem.> I strongly suspect that the source has a slow/bursty connection to > Icecast so that the data sent to the Icecast server arrives in too > discontinuous chunks, even though the average connection speed is ok.In case Icecast2 disconnects the source for some reason (that in all cases is logged to error.log) there are some options on how to fix it depending on the details of your setup. Sometimes it helps to tune the encoder parameters. Reducing the bitrate for example. Another thing that you should make sure is that you do not have any periods of digital silence that are close to the source timeout. Digital silence will let the encoder drop the bitrate that low, that it may not generate output at least once per timeout interval.> What's more, they tell me that the Icecast output is in advance vs the > actual radio broadcast (through a link to their FM emitter). So I guess > that their emitter has some sort of buffering.It's normal that different channels have different latencies. This is sometimes also caused by the physical aspects of the technologies used. Without more details and log files it's hard to tell what exactly happens. I hope that I sill provided you with some helpful pointers. with best regards, PS: There is also an IRC channel on Freenode at #icecast.> > Thanks > -- JM-- Philipp Schafft (CEO/Geschäftsführer) Telephon: +49.3535 490 17 92 Löwenfelsen UG (haftungsbeschränkt) Registration number: Bickinger Straße 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: <http://lists.xiph.org/pipermail/icecast/attachments/20161019/7b977204/attachment.sig>
Jean-Marc Coursimault
2016-Oct-19 14:23 UTC
[Icecast] Increasing Icecast input buffering ?
Hi, Thank you very much for your answer. I just tried to increase the queue size to 13048576 (an arbitrary, but large, number). I increased the client / header / source timeouts to 30, 35, 30 respectively. Seems strange now, the sound jumps (forward), at least it seems that some parts of the song are cut. I've increased the debug-level to 4, but now I get a gazillion messages. I tried to grep on the mountpoint name, but I do not see anything significant. What should I grep on ? I could send you the icecast.xml, but there's nothing special in it. (Icecast 2.3.3). The flux is http://live.francra.org:8000/Radio-Calade. Thanks for your help ! -- JM Le 19/10/2016 10:55, Philipp Schafft a écrit :> Good morning, > > On Wed, 2016-10-19 at 09:57 +0200, Jean-Marc Coursimault wrote: >> Hello, >> >> My question is : is there a way to have Icecast buffer the input / >> increase the input buffering ? Even though the latency would increase ? >> Why : On some radio streams, the listeners to a Icecast stream >> experience very frequent silences / disconnections. > There is no input buffer in Icecast2 at all: > > Icecast2 forwards the data as fast as it can (from source to listener). > Icecast itself has no idea of time (that would require Icecast to > interact with the data itself). That is why. > There is the queue (the size of the queue can be configured, see the > manual). The queue is a single buffer that allows jitters in > transmission. But that is not a buffer that belongs to the input or > output side. It's kind of both of the same time. > > When the source sends data it's append to the queue. When the data got > transmitted to all clients the tail of the queue is removed. (It's a > kind of a ring buffer). > > In case Icecast2 itself disconnects any listener that is because the > client fall to much behind (reached the tail of the queue). That is > normally caused by clients that can not receive or process the data at > the speed (bitrate) the source sends. > > In case Icecast2 itself source that is because of source timeout (can > also be configured). That is a timeout to disconnect stalled source > connections. Basically Icecast2 expect the source to send at least some > data within this timeout interval. > > Both cases are logged in the error.log (see your config). Consider to > raise the debug level to 'debug' (4) to get a more verbose output. > > > Another cause could be that clients for some reason disconnect. That can > e.g. happen in case the client has some network or processing trouble. > > If none of the above seems to be happening I would suggest to increase > the client's buffer and see if that fixes the problem. > > > >> I strongly suspect that the source has a slow/bursty connection to >> Icecast so that the data sent to the Icecast server arrives in too >> discontinuous chunks, even though the average connection speed is ok. > In case Icecast2 disconnects the source for some reason (that in all > cases is logged to error.log) there are some options on how to fix it > depending on the details of your setup. > > Sometimes it helps to tune the encoder parameters. Reducing the bitrate > for example. Another thing that you should make sure is that you do not > have any periods of digital silence that are close to the source > timeout. Digital silence will let the encoder drop the bitrate that low, > that it may not generate output at least once per timeout interval. > > >> What's more, they tell me that the Icecast output is in advance vs the >> actual radio broadcast (through a link to their FM emitter). So I guess >> that their emitter has some sort of buffering. > It's normal that different channels have different latencies. This is > sometimes also caused by the physical aspects of the technologies used. > > > Without more details and log files it's hard to tell what exactly > happens. I hope that I sill provided you with some helpful pointers. > > > with best regards, > > > PS: There is also an IRC channel on Freenode at #icecast. > >> Thanks >> -- JM > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-- -- Jean-Marc Coursimault ___________________________________________ Axperia SARL Les Contamines, 38420 Revel jmc at axperia.net Tél 06 88 62 55 71 RCS 453651606 Grenoble NAF 6311Z TVA intra FR16453651606 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20161019/664ecb89/attachment.html>