Ardour with PipeWire stops existing audio streams

Getting Stuff Done Hints and Tricks
#1

Dear Friends,

I seem to have noticed a change in behaviour using Ardour 8.6 once pipewire or pipewire-pulse is turned on, compared to behaviour with pulseaudio in the past. I have jackd turned off always.

Before, if, for instance, I had, say, mplayer streaming audio out of my motherboard native audio output, and my Scarlett 18i8 being used under Alsa for Ardour with the Scarlett set as ‘Off’ under pavucontrol, there would be no interruption to the streaming audio as Ardour started. Ardour would use the 18i8 quite happily without side effects or interference to other audio apps.

But with a switch to pipewire/wireplumber, when I start Ardour, the mplayer output is seemingly muted (even though mplayer is still able to write to its output audio — it’s not stuttering with backpressure as it can do when its output device is broken - and mplayer’s time code on the screen is still going up). And after I exit Ardour, or stop its audio worker using the Audio Setup Stop button, the mplayer audio output become unmuted and works as before.

I can do some more experiments to investigate more deeply, but I have a feeling this is something to do with Ardour’s alsa backed interacting with pipewire. Really, I’d prefer it if they had nothing to do with each other: Ardour ignoring all other audio devices and pipewire ignoring Ardour and the multi-track audio interface that Ardour is using. Is there something I can change to keep them better isolated (stop them nosing around into each other’s territory)? I guess the same goes for midi interfaces, since Ardour snoops on all of them (40 or 50 in my case) and clutters the REC window with parts of the system I wish it would ignore.

Thanks for any suggestions. I should think I can recompile the Ardour ALSA audio backend to make it less promiscuous, but I am not sure that this would fully work, since I believe ALSA has also enriched its own functionality in recent years and the various ALSA device drivers are no longer fully independent at the bottom level, even if no pulse, pipewire or user app (like Ardour) is aggregating them. Is this correct?

Many thanks - DJG

#2

That’s 100% correct. The ALSA backend gains exclusive access to the audio device you chose to use (in Ardour); Pipewire gives up on it until Ardour exits.

#3

Yes, well what you say is fair enough, thanks Paul.

But I was not asking about that. I was asking about Ardour interacting with other devices beyond the one it is supposed to be using.

DJG

#4

Ardour itself will not interact with any device other than the one(s) you tell it to use for audio input and output.

If pipewire changes its behavior (other than ceasing use of those same device(s)) when Ardour starts up, that’s a pipewire issue.

#5

Ardour itself will not interact with any device other than the one(s) you tell it to use for audio input and output.

Yes Paul, you are quite correct and it is me who has misunderstood the problem. I am sorry about that.

My issue with pipewire is that it is ignoring my attempts at settings that try to ensure the motherboard S/P-DIF is always 44.1 ksps. My old settings work fine if I revert to pulseaudio when no pipewire/wireplumber running.

So the details of my problem are not Ardour-specific. But in case anyone wants to make a suggestion, I here give further details: I have tried new monitor.alsa.rules in my alsa config and various pw command- line commands, but the motherboard S/P-DIF keeps reverting to 48 ksps. Owing to my setup, it was Ardour’s perfectly correct control of the clock rate on its designated interface (the 18i8) that was ultimately interrupting the audio on what I thought were totally independent audio components, but actually there was a studio clock dependency. I started using pipewire since screen capture from Wayland (for zoom screen sharing and obs studio screen capture) do not work otherwise.

One version of my runes is below. Thanks anybody for any suggestions. DJG.

monitor.alsa.rules = [
{
matches = [
{
device.name = “~alsa_output.pci.iec958.”
}
]
actions = {
context_properties =
{
default.clock.allowed-rates = [ 44100 ]
default.clock.rate = 44100
audio.rate = 44100
audio.format = “S24LE”
}
etc …