Hello
I have a problem when I use the intro to send a pre-roll, the main stream
generates a 20 second delay, when the main stream is played it has no delay.
Is there any parameter I can use to eliminate the delay?
with pre-rolli: https://radiomarca-rrcast.flumotion.com/radiomarca/live.mp3
without pre-rolli:
https://radiomarca-rrcast.flumotion.com/radiomarca/live-np.mp3
my conf:
icecast>
<limits>
<clients>2310</clients>
<sources>10000</sources>
<threadpool>16</threadpool>
<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>600</source-timeout>
<!-- If enabled, this will provide a burst of data when a client
first connects, thereby significantly reducing the startup
time for listeners that do substantial buffering. However,
it also significantly increases latency between the source
client and listening client. For low-latency setups, you
might want to disable this. -->
<burst-on-connect>1</burst-on-connect>
<!-- same as burst-on-connect, but this allows for being more
specific on how much to burst. Most people won't need to
change from the default 64k. Applies to all mountpoints -->
<burst-size>65536</burst-size>
</limits>
<mount>
<mount-name>/radiomarca/live.mp3</mount-name>
<queue-size>0</queue-size>
<burst-on-connect>1</burst-on-connect>
<burst-size>0</burst-size>
<intro>/radio-marca/radio-marca-preroll.mp3</intro>
</mount>
<mount>
<mount-name>/radiomarca/live-np.mp3</mount-name>
<queue-size>0</queue-size>
<burst-on-connect>1</burst-on-connect>
<burst-size>0</burst-size>
</mount>
Thanks in advance for your help
Best regards
--
Javier Fuentes
Flumotion Services S.A.
Avda. Diagonal 593-595 5?
08014 Barcelona - Spain
www.flumotion.com
*AVISO LEGAL:* Todo el contenido de este correo y sus adjuntos proviene de
FLUMOTION SERVICES, S.A. (en adelante, ?FLUMOTION?). La informaci?n
contenida en este e-mail es confidencial y est? dirigida exclusivamente a
su destinatario. Aunque FLUMOTION le remita cualquier clase de informaci?n
o material, ello no podr? interpretarse como cesi?n, licencia o derecho a
usar o comercializar tales materiales. Si usted no es el destinatario de
este email, no est? autorizado a usar o comunicar p?blicamente este mensaje
y/o su contenido. Si ha recibido este mensaje por error, por favor elim?nelo y
contacte con nuestro personal en el tel?fono +34 935086350. FLUMOTION es
una sociedad an?nima con domicilio social en Avenida Diagonal 593, 5? 08014
? Barcelona ? Espa?a. Los datos personales que recibamos de nuestra
correspondencia con Ud. se incorporan en un fichero de FLUMOTION cuya
finalidad es la de gestionar la relaci?n contractual con usted, as? como
remitirle comunicaciones sobre FLUMOTION, y su tratamiento est? legitimado
por la existencia de dicha relaci?n y la necesidad de gestionarla. En el
caso de comunicaciones de negocio y, si es o ha sido nuestro cliente, de
comunicaciones de comerciales, la legitimaci?n para el tratamiento ser?
nuestro inter?s leg?timo en desarrollar negocio. Vd. puede ejercitar sus
derechos de acceso, rectificaci?n, cancelaci?n u oposici?n, as? como el
resto de derechos que le asisten seg?n Ley, mediante escrito a
info at flumotion.com o al domicilio social de FLUMOTION.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20191204/f3bd2324/attachment.htm>
On Wed, 4 Dec 2019, Javier Fuentes wrote:> I have a problem when I use the intro to send a pre-roll, the main stream > generates a 20 second delay, when the main stream is played it has no delay. > Is there any parameter I can use to eliminate the delay? > with pre-rolli: https://radiomarca-rrcast.flumotion.com/radiomarca/live.mp3 > without pre-rolli: > https://radiomarca-rrcast.flumotion.com/radiomarca/live-np.mp3Are you saying that the listener is further behind on the stream with the pre-roll? I believe that this happens because the pre-roll is sent as quickly as possible by Icecast to the client, rather than at the rate of the audio. So it will take much less time to send than it does to play. Once it has finished sending the pre-roll, it starts sending the live audio. The player still has to play the pre-roll and will therefore be further behind the live audio when it gets to it. Note that I'm only guessing but it makes sense. My advice, use a shorter pre-roll. As a listener, this will get very annoying very quickly. 40 seconds is a long time to listen through a pre-roll if your connection drops for a second. I would limit it to 10 seconds max. BTW: At time of writing, the live audio is out of phase (see https://www.audiocheck.net/audiotests_polaritycheck.php for explanations and examples). this will cause the encoder to work much harder than it has to and will not sound as good as it should. It will also cause anyone listening through a single speaker not to be able to hear the announcer and anything else that is panned centre (e.g. song vocals). this is most likely caused by an incorrectly wired cable or an RTS plug which is not fully inserted into the jack. HTH, Geoff.
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. The delay is complicated mix of client's , network's and server's configuration and speed. Big burst is good to get a client buffers filled so you get little buffering when listing live. Twerking around the settings can make it better but can't be perfect. 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. On Wed, Dec 4, 2019, 6:52 AM Geoff Shang <geoff at quitelikely.com> wrote:> On Wed, 4 Dec 2019, Javier Fuentes wrote: > > > I have a problem when I use the intro to send a pre-roll, the main stream > > generates a 20 second delay, when the main stream is played it has no > delay. > > Is there any parameter I can use to eliminate the delay? > > with pre-rolli: > https://radiomarca-rrcast.flumotion.com/radiomarca/live.mp3 > > without pre-rolli: > > https://radiomarca-rrcast.flumotion.com/radiomarca/live-np.mp3 > > Are you saying that the listener is further behind on the stream with the > pre-roll? > > I believe that this happens because the pre-roll is sent as quickly as > possible by Icecast to the client, rather than at the rate of the audio. > So it will take much less time to send than it does to play. Once it has > finished sending the pre-roll, it starts sending the live audio. The > player still has to play the pre-roll and will therefore be further behind > the live audio when it gets to it. > > Note that I'm only guessing but it makes sense. > > My advice, use a shorter pre-roll. As a listener, this will get very > annoying very quickly. 40 seconds is a long time to listen through a > pre-roll if your connection drops for a second. I would limit it to 10 > seconds max. > > BTW: At time of writing, the live audio is out of phase (see > https://www.audiocheck.net/audiotests_polaritycheck.php for explanations > and examples). this will cause the encoder to work much harder than it > has to and will not sound as good as it should. It will also cause anyone > listening through a single speaker not to be able to hear the announcer > and anything else that is panned centre (e.g. song vocals). > > this is most likely caused by an incorrectly wired cable or an RTS plug > which is not fully inserted into the jack. > > HTH, > Geoff. > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20191204/52688142/attachment.html>