OPAM installation conflicts with DEB installation?

[add-n2x]

Until 2.1 I've used Liquidsoap using opam only, since it's the recommended way according to the Liquidsoap documentation. With 2.1 I started using the Debian package provided from the GitHub Build page.

This wasn't a problem until recently, where I noticed our play-out engine is behaving weird when switching channels. So I wrote a test case which was also behaving weird - I was not able to switch between channels in a timely manner anymore. Any channel switch was took quite constantly around ~23 seconds.

So it turns out the test case mentioned above works just fine within a Liqiuidsoap 2.1 Docker environment.

That's why I'm assuming there might be a conflict with Liquidsoap 2.0.x (opam) and Liquidsoap 2.1 (DEB). But even after removing the OPAM version and all dependencies, it is still not working.

• Could this be possible that opam and deb are conflicting?
• And how is the Debian version of Liquidsoap managing its dependencies?

[vitoyucepi]

As far as I understand the idea of the test script is to start server and then in 5 seconds begin playing the queue.

I've tested my own ubuntu:20.04 docker container with deb artifact.
The script works fine.
For the first five seconds the fallback music is played, and after that moment the music is changed.

The differences are

1. I don't use alsa.
2. I used a single instead of playlist for fallback_folder.
3. I use ubuntu:20.04 and corresponding release deb file.
4. I use docker.

Probably you could test it on localhost by setting up a clean debian vm.

[add-n2x]

Wow, thanks for taking the effort. That's much appreciated 🙏

As far as I understand the idea of the test script is to start server and then in 5 seconds begin playing the queue.

Exactly.

Well, the scenario with running in Docker worked for me too. But your statement I don't use alsa gave me a hint to try something different. I'm using ALSA through the PulseAudio ALSA plugin most of the time, because the main downside have been some latency issues with live audio only. But now I the deactivated PulseAudio server for the given test case - and who would have expected that - it works natively on my host machine now. Like in Docker :-D

Now I'm just curious why this happens. I cannot image that PulseAudio introduces a latency of 23 seconds, because generally audio is played quite instantly from the fallback folder. Also, running the script within Docker using ALSA is just delegating device management to PulseAudio on the host machine. So there must be issues too. I leave this question for another time.

[toots]

Thanks for investigating this. I imagine pulseaudio might retain some control over the input device that could cause a delay when opening it from another application?

[add-n2x]

Yes, that probably the case. I'm just baffled about the extreme delay of 23s. There was always some latency with PulseAudio, but we were talking about 2s max. Will investigate this further, when I gonna try Liquidsoap with pure PulseAudio at some point.

Also looking forward to give PipeWire a try, hoping it's the savior of Linux Audio Routing :-)