[Icecast] Increasing Icecast input buffering ?

[Philipp Schafft]

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>