Hello dear community, maybe you can help? On one of our channels we have the following setup: the live signal is routed from the studio via Line-In in the Mairlist directly to the encoder and then streamed from there. The playback of the players in this Mairlist are in turn routed to the encoder’s high priority input, as they are supposed to “overlay” the live signal. This works great for our purposes. I adjust the fade time for this via the “high priority fade length” in the encoder options. This also works perfectly for the fade-in, i.e. there is a nice cross-fade from the encoder line signal to the high priority signal.
Now the problem: With the fade-out, however, the high-priority signal fades out completely and only then does the encoder signal slowly fade up again - there is no cross-fade and is once briefly silent for one ms “between” the fades. As far as I can see, I can’t influence this any further, except for the length via the encoder options. The cross-fade is only when fading in.
Does anyone have any ideas? Thank you.
P.S.: For our broadcast chain, we are somewhat misappropriating the function of the high priority input. I know there are other solutions for our setup, e.g. with live feed etc. - but here we use the high priority function for various reasons.
I am also encountering the same issue in mAirlist 8.x.
When enabling a Stream Monitor (configured as High Priority input) it will properly fade-in.
However, when disabling the Stream Monitor the audio of the stream is cut out immediately. After this cut out, the playlist will fade in.
This sounds a bit abruptly. I haven’t found a setting I can configure to fix this.
I do not see how this should work: On disabling the stream the audio is cut. How could mAirList know in advance that the stream will be interrupted in, say, five seconds to establish a fadeout? Or am I missing something?
@Tondose the Stream Monitor could perhaps fade out and stream the additional x-amount of seconds until the fade out is done.
Now, I assume the concept of High Priority input is completely separate from that of the Stream Monitor in the code, so perhaps a separate config option to fade in/out specifically for the streaming monitor could be an option?
Okay, and if the stream is cut from the remote end?
@Tondose @MaartenVN Torben replied to me back then in the German post from 2022:
Unfortunately, there’s currently no other way to do this technically. The high-priority path only sends its “nothing more coming here” message once the fade has actually finished.
Internally, the number of currently active sources on the (virtual) audio device is determined, and only when the last one closes and the number drops to 0 does the encoder switch back to the normal path.
This “intermediate state” (something is still playing, but it’s just a fade-out) is unfortunately not treated as a separate case.
1 Like
Sounds reasonable. As the input is high-priority, its audio is routed to the encoder anyway.