[Icecast] fallback-override takes very long to switch back -- Is there a way to switch back immediately?

[Geoff Shang]

On Fri, 26 Feb 2021, Lorenz Reichelt wrote:

> I would like to be broadcasting mp3 audio for just about half an hour a day (at the moment via a hosted service), however, listeners are usually waiting and we have some interaction, so delay becomes an issue when it exceeds a couple of seconds.
>
> I like the possibility to provide a fallback mp3 in the web root that is played if someone joins before we start to broadcast. However, as I have tried out multiple times, the delay is far longer then. If I am already broadcasting live or start in the seconds directly after someone joins, they get a delay of five to ten seconds. When they have listened to the fallback mp3 for half a minute before I go live, they receive my live audio with over a minute of delay. So, while someone joining later is directly connected with only a couple of seconds of delay, those already joining before have to listen to the fallback audio for over another minute before it switches to the live mount.

Hi,

The problem is that if Icecast is streaming an MP3 internally, it will 
stream it to the client as quickly as it can.  So the listener will get 
multiple loops of the MP3 file in the time that it takes to play just one. 
It will need to play through all of these before picking up the new data 
from the live mount.

The way to get around this is to stream the fallback mount, rather than to 
have it streamed by Icecast.  You can use something like ezstream or ices 
0.x to stream to your backup mount and it can run on the same machine as 
the Icecast server.

The backup streamer will stream to Icecast at the bitrate of the file, and 
so the audio will be pushed to the listener at that same rate.  The switch 
should be pretty quick.

HTH,
Geoff.