Pipewire 1.0 - Is it time now?

Community Ideas for Ardour
#1

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.

That might have changed recently. PipeWire 1.0 RC Available With Jackdbus By Default, Improved IRQ-Based Scheduling - Phoronix I think they will stabilize the APIs and finish implementing everything they had envisioned for the first major version.

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 totally understand if this changes nothing as it would be yet another complicated development path. Also, @paul has said previously that “we will ansolutely not consider a native Pipewire support implementation” because of Jack. So, the win here is maybe nothing.

I was just curious what are the developers’ thoughts on this 1.0 happening this year. Does it change anything? Will Pipewire take Jacks place?

Thanks for all your work :slight_smile: Currently eager waiting for 8.0!

1 Like
#2

Nope. Nothing changes on Ardour side of things.

Since pipewire is (supposed to be) a 100% compatible drop-in replacement for JACK, no change is required or even desirable.

3 Likes
#3

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. :frowning:
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.

1 Like
Ardour 8 Pipewire-ALSA
#4

It is a workaround at best.

Note that when you do that, MIDI still bypasses piprewire and uses ALSA to directly access to hardware.

This is quite different to using JACK Audio/MIDI which is sample-sync.

Because Ardour only lists actual hardware devices and explicitly excludes software plugs.

1 Like
Ardour 8 Pipewire-ALSA
#5

I don’t care about MIDI devices that much :wink:

#6

What is so bad about JACK that made someone decide to make Pipewire as a replacement?

2 Likes
#7

It’s not that there is anything bad about JACK per se.

The desire is for a single server that can handle both desktop/consumer audio needs handled by PulseAudio and the pro-audio needs handled by JACK.

4 Likes
#8

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.

1 Like
#9

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).

2 Likes
#10

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.

On macOS really got this right.

1 Like
#11

Is Pipe Wire reverse engineering from Core Audio?
So I mean, why not take a model from a well-functioning solution?

#12

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.

#13

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 :smile:

1 Like
#14

0.3.8 is more than 3 years old (July 2020). I hope you meant 0.3.80 or 0.3.81.

#15

Oops, my bad! 0.3.80

#16

And don’t forget video. In these forums we obviously are primarily discussing audio, but PipeWire began as a video project.

2 Likes
#17

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.

7 Likes
#18

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.

1 Like
#19

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.

4 Likes
#20

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?

2 Likes