Fading with live source in a switch

[gammaw]

Hi!

I'm trying to fade in and out across several sources including a live source. The sources are scheduled using a switch.

Something like this:

...

radio = switch(track_sensitive=false, 
    [({!live_enabled}, live),
    ({1w and 12h-13h}, delay(60., playlist_my_show)),
    ({true}, radio)])   

def fading_transition(a,b)
	sequence([fade.out(a.source),fade.in(b.source)])
end

radio = cross(fading_transition, radio)

The problem is that for some reason the live source and the default radio source are switching back and forth, although the live source remains ready the whole time. Can anybody explain why is this happening?

When I remove the cross operator (no fading) the switch behaves as expected but without transition.

Thanks!

Origin of the issue: #2123

[TheRealMattLear]

I found the same problem which seems to be related to the harbor buffer. Increasing the buffer to a greater value then the total crossfade duration seems to help the issue, though we're still having some sporadic reports of issues.

For example setting buffer to 30s should be safe:

input.harbor(buffer=30.0)

[gammaw]

Wow, it seems to solve it! Thanks!

30s makes the transition a bit long though, but at least it works.

Do you know if it's a bug, or something which is inherent to how switch (or cross or something) is used here?

Another thing, do you know the difference between buffer and max? When I set 30 for buffer, then I need to set a greater number for max (e.g., 31), but I'd like to understand what it does.

[TheRealMattLear]

So in my testing i found that the buffer just needs to be slightly more than the entire fade duration (duration + in + out). The fade.in and fade.out methods have a default duration of 3 seconds each and cross() has a default duration of 5 seconds. 5 + 3 + 3 = 11s so i'd suggest experimenting with 12s+ of a buffer.

From my understanding, buffer is a minimum and max is a maximum that is held; not entirely sure what max would be used for but i'm guessing it just allows for relaxed garbage collection with an extended duration. Just spitballing here.

Do you know if it's a bug, or something which is inherent to how switch (or cross or something) is used here?

I have not tested but no reports of issue with 1.4.4 so i'd imagine this to be an introduced bug in 2.0. @toots ?

[gammaw]

Thanks! What a magic formula! For me it worked with 11s but not with 10s :)

[toots]

Well I'm actually surprised that this is working. 2.0.x was supposed to prohibit using input.harbor in crossfades.. 😅

The reason is that live source inputs like harbor needs to work in real time but crossfade do accelerate so they'll consume data at a higher rate.

It is indeed possible to have crossfades but you need to know what you are doing, typically you need to buffer enough data (like y'all found out) and only buffer beginning and ending.

I'll revisit this shortly, thanks for reporting.

[gammaw]

Interesting. And what would be then the proposed way to fade out/in a (not live) source before/after a live source if not through a cross? For us it's a fundamental use case because we don't know where the live source will "interrupt" a playing track (from a playlist source) and we don't want an abrupt transition. I imagine that it's a pretty basic use case, or is it not? Note that we don't need to fade the live source cause there we have control over how the live part starts and ends, so buffering the live source should not be an issue.

[toots]

I finally have time to revisit this and the code is actually correct. The sources that are prohibited in a crossfade are sources that cannot be accelerated, like input.alsa or input.srt. input.harbor is buffered so it can be accelerated with the additional constraint that you might run out of data and the source will in this case become unavailable.

So, yeah, this is all correct. In order to have crossfades with harbor inputs, one should make sure that the harbor buffer contains at least enough data for the transition in and out of a live show. This is because the cross operator will fetch ahead of time this data before computing the crossfade transition. @TheRealMattLear remarks seem absolutely correct.

I have changed the default values for input.harbor in v2.0.3-preview and main to make it possible to use crossfade transitions by default without having to run all these computations.

Thanks for bringing this up! I'm converting this as a discussion so that it sticks around for other users who might need it.

[tyctor]

@gammaw
how you set live_enabled in you script?
in my setup i have input.harbor as live source, so i want to use it in your script as live
how i assign true to live_enabled if stream is connected to input.harbor?

i am new in liquidsoap, so sorry for stupid question...

i have this script:

settings.harbor.bind_addrs.set(["0.0.0.0"])
default = mksafe(single("/radio/default.mp3"))
live = input.harbor("live-harbor",port=8080,password="hackme")

live_enabled = ref(live.is_active())

radio = switch(track_sensitive=false, [
    ({!live_enabled}, live),
    ({true}, default) ])

def fading_transition(a,b)
	sequence([fade.out(a.source),fade.in(b.source)])
end

radio = cross(fading_transition, radio)

output.icecast(%mp3, 
  host="localhost",port=8080,password="hackme",
  mount="live-harbor",radio)

but i am getting error:

radio = cross(fading_transition, radio)

Error 7: Invalid value:
That source is fallible

[tyctor]

solved by putting fallible=true to icecast.output
and it seems working as expected
is that really so simple with liquidsoap? :) nothing i am missing there? ofcourse single must be replaced by calling external script, but it will also return filename from disk, but everything else, i think, can stay unchanged

[toots]

Glad you found a solution. You should be aware, though, that fallible sources may disconnect from icecast if they are not able to produce any audio. For more background, you can look at the FAZ entry here: https://www.liquidsoap.info/doc-2.1.2/faq.html and check out the liquidsoap book: https://www.liquidsoap.info/doc-2.1.2/book.html

[omarmn]

Hi,

I am having the same issue, although I tried extending buffer to 30 s, I also copied @toots example (with some tweaks) here, but in all cases I'm getting the same behaviour, when input.harbor connects, it plays the first second then it jumps a few seconds ahead. Maybe I'm missing something, here's my script:

# Function to filter out only mp3 files
def check(r)
  fname = request.filename(r)
  string.match(pattern=".*mp3$", fname)
end

#Directory to where archives are
Archives="My Music"

#Bind harbor to monitor localhost on 8080
set("harbor.bind", "127.0.0.1:8080")

#Live source 
live=input.harbor("live", port=8080, password="hackmenot", buffer=30.0, max=31.0)

#Archive source
archive=playlist(check_next=check, Archives)

#Fallback source
default=single("avril_14.mp3")

#Create radio
radio=fallback(track_sensitive=false,[live, archive, default])

#Add crossfade to provide smoother transitions
radio=crossfade(fade_out=3., fade_in=3., duration=6., radio)

output.icecast(%mp3,fallible=true, [obfuscated credentials], radio) 

Any ideas why this is happening? Is it an issue, or am I doing something wrong? I am running Liquidsoap 2.2.4-1+dev

Thanks :)