[Icecast] Increasing Icecast input buffering ?

[Jean-Marc Coursimault]

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.htm>