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?