<div dir="auto">One thing is, there is always a delay, especially if use a burst cache. I can put 3 different clients on the delay can be a little annoying. From a simple each or reverb effect to a couple sec delay. And if you separate on remote network it can easily be 10 to 15 sec between clients.<div dir="auto"> The delay is complicated mix of client's , network's and server's configuration and speed.</div><div dir="auto"> Big burst is good to get a client buffers filled so you get little buffering when listing live.</div><div dir="auto">  Twerking around the settings can make it better but can't be perfect.</div><div dir="auto">  I find trying listen with the source in one ear and the stream with other, you can find where this delay is. And it will change overtime.</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 4, 2019, 6:52 AM Geoff Shang <<a href="mailto:geoff@quitelikely.com">geoff@quitelikely.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 4 Dec 2019, Javier Fuentes wrote:<br>
<br>
> I have a problem when I use the intro to send a pre-roll, the main stream<br>
> generates a 20 second delay, when the main stream is played it has no delay.<br>
> Is there any parameter I can use to eliminate the delay?<br>
> with pre-rolli: <a href="https://radiomarca-rrcast.flumotion.com/radiomarca/live.mp3" rel="noreferrer noreferrer" target="_blank">https://radiomarca-rrcast.flumotion.com/radiomarca/live.mp3</a><br>
> without pre-rolli:<br>
> <a href="https://radiomarca-rrcast.flumotion.com/radiomarca/live-np.mp3" rel="noreferrer noreferrer" target="_blank">https://radiomarca-rrcast.flumotion.com/radiomarca/live-np.mp3</a><br>
<br>
Are you saying that the listener is further behind on the stream with the <br>
pre-roll?<br>
<br>
I believe that this happens because the pre-roll is sent as quickly as <br>
possible by Icecast to the client, rather than at the rate of the audio. <br>
So it will take much less time to send than it does to play.  Once it has <br>
finished sending the pre-roll, it starts sending the live audio.  The <br>
player still has to play the pre-roll and will therefore be further behind <br>
the live audio when it gets to it.<br>
<br>
Note that I'm only guessing but it makes sense.<br>
<br>
My advice, use a shorter pre-roll.  As a listener, this will get very <br>
annoying very quickly.  40 seconds is a long time to listen through a <br>
pre-roll if your connection drops for a second.  I would limit it to 10 <br>
seconds max.<br>
<br>
BTW: At time of writing, the live audio is out of phase (see <br>
<a href="https://www.audiocheck.net/audiotests_polaritycheck.php" rel="noreferrer noreferrer" target="_blank">https://www.audiocheck.net/audiotests_polaritycheck.php</a> for explanations <br>
and examples).  this will cause the encoder to work much harder than it <br>
has to and will not sound as good as it should.  It will also cause anyone <br>
listening through a single speaker not to be able to hear the announcer <br>
and anything else that is panned centre (e.g. song vocals).<br>
<br>
this is most likely caused by an incorrectly wired cable or an RTS plug <br>
which is not fully inserted into the jack.<br>
<br>
HTH,<br>
Geoff.<br>
<br>
_______________________________________________<br>
Icecast mailing list<br>
<a href="mailto:Icecast@xiph.org" target="_blank" rel="noreferrer">Icecast@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/icecast" rel="noreferrer noreferrer" target="_blank">http://lists.xiph.org/mailman/listinfo/icecast</a><br>
</blockquote></div>