I know that Ardour does not have a direct Pipewire driver nor it plans to currently. The main argument is that its API is still experimental and it is not considered production ready for professional audio. Also, since it currently implements Jack APIs it maybe will never be the case for supporting a direct driver.
I am curious to know if this would perhaps change the current decision. Maybe this is the time to add Pipewire into the roadmap for a future version of Ardour ?
I’ve been a huge fan of Pipewire for a year or so, but now I have my doubts.
The characteristic of Pipewire is, that it can work very good for a long time and suddenly with a new release it can be broken. I mean: really unusable (e.g. v0.3.78). I’m mostly interested in pipewire-jack module of course and I have the impression that it works worse and worse with each new version.
If I run Ardour the sound is crackling even if I adjust system global volume and it causing Ardour to crash.
I’m testing right now the new Studio One 6.5 for Linux, It crashes 2 times out of 3 launches with JACK connection error (but this is beta).
Every update brings suprises (i.e. problems).
The only solution to pipewire-jack and Ardour problems is to make Ardour use ALSA backend with pipewire-alsa device.
Unfortunately Ardour can’t see this device out of the box (I don’t know why) and you have to run Ardour this way:
ARDOUR_ALSA_DEVICE=pipewire /path/to/ardour8
This is the only way now to have smooth playback and other apps have access to sound card.
To me that sound counter-intuitive. One would get better and the other would get worse. Sort of meeting in the middle. Right now from my perspective as an “outsider” the Linux audio environment is rather muddy as it is.
That could happen in theory. But we try to have faith in the Pipewire crew to get it right (eventually). It works on macOS, for example (with CoreAudio, which does the same thing).
Also, the Linux audio environment is no more, and possibly less muddy than the Windows one. There you have ASIO, still the gold standard for drivers to use with pro-audio apps, WDM, Microsoft’s attempt to do what ASIO could but also what MME used to do, plus legacy audio APIs. At least on Linux, everything goes through ALSA, you just choose what level of the stack built on that to use.
Given the CoreAudio encompasses the entire audio stack, from device drivers to high level media-app APIs, it would be inappropriate to try to copy it entirely into a system that will still use ALSA for the driver layer.
However, Pipewire has taken a number of the most important ideas from CoreAudio and used them.
I’ve been using Pipewire (0.3.8) on Opensuse tumbleweed for about a week now. I have an old focusrite saffire 40 and that all connects perfectly. Even the MIDI in that didn’t work in the past now works. It’s a whole lot nicer to use than having to start manually all the time when I wanted to do stuff. Also the fact it’s all in wrong means I can just use the onboard sound now with JACK with no issues. The usability is a big improvement.
Performance wise, I can’t really speak for much yet as have only been using MIDI controlled virtual instruments. I can say that the MIDI latency has been good, all except for using JACK MIDI in Ardour, which introduces extra latency that other programs don’t. It is fine when switched to ALSA mode though.
Maybe I should lock the package whilst the going is good
Just a point of reference, in testing the first RC of Pipewire 1.0, my measured latency dropped from 20ms down to 10, using my USB-based Behringer UMC1820. The IRQ backend really seems to have helped. Hoping this translates to better stability, too.
You know that PipeWire is basically a (questionable) hack to funnel audio streams from containers, different VMs or Flatpack/Snap environments with several versions of the same libraries (which tend to be different to the system libriaries) to the system’s audio hardware. Which is a terrible concept to duct tape the intrinsic flaws of a truly terrible concept. If you want to work with professional audio you want to avoid that mess and use the packages from your distro’s package manager. If that is impossibe then use a reasonable distribution or you’ll never get any order into the mess that PipeWire on top of Pulse on top of ALSA as a “replacement” for Jack is.
I’ve been using Pipewire on Debian for over a year. Never had any issues, didn’t have to worry about setting up sinks so I could use multiple apps together. Everything just works out of the box (including bluetooth audio) it’s lovely.
What do Flatpak/VMs/Snap have to do with Pipewire signal routing? Once the connection is established, the desktop handles routing. You also don’t have ‘Pipewire on top of Pulse on top of ALSA’—in the end, there is only ALSA anyway, and you don’t have to shove Pulse in the middle if you don’t want to. I know I don’t.
Besides, what’s so bad about ensuring backward compatibility?