<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi,<br>
<br>
Thank you very much for your answer.<br>
<br>
I just tried to increase the queue size to 13048576 (an arbitrary,
but large, number).<br>
I increased the client / header / source timeouts to 30, 35, 30
respectively.<br>
<br>
Seems strange now, the sound jumps (forward), at least it seems
that some parts of the song are cut.<br>
<br>
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.<br>
<br>
What should I grep on ?<br>
<br>
I could send you the icecast.xml, but there's nothing special in
it. (Icecast 2.3.3).<br>
The flux is <a class="moz-txt-link-freetext" href="http://live.francra.org:8000/Radio-Calade">http://live.francra.org:8000/Radio-Calade</a>.<br>
<br>
Thanks for your help !<br>
-- JM<br>
<br>
Le 19/10/2016 10:55, Philipp Schafft a écrit :<br>
</div>
<blockquote cite="mid:1476867347.1776.14.camel@de.loewenfelsen.net"
type="cite">
<pre wrap="">Good morning,
On Wed, 2016-10-19 at 09:57 +0200, Jean-Marc Coursimault wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello,
My question is : is there a way to have Icecast buffer the input /
increase the input buffering ? Even though the latency would increase ?
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Why : On some radio streams, the listeners to a Icecast stream
experience very frequent silences / disconnections.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">
Thanks
-- JM
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Icecast mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Icecast@xiph.org">Icecast@xiph.org</a>
<a class="moz-txt-link-freetext" href="http://lists.xiph.org/mailman/listinfo/icecast">http://lists.xiph.org/mailman/listinfo/icecast</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
--
Jean-Marc Coursimault
___________________________________________
Axperia SARL Les Contamines, 38420 Revel
<a class="moz-txt-link-abbreviated" href="mailto:jmc@axperia.net">jmc@axperia.net</a> Tél 06 88 62 55 71
RCS 453651606 Grenoble NAF 6311Z
TVA intra FR16453651606</pre>
</body>
</html>