Pipewire 1.0 - Is it time now?

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


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.

1 Like

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?


pipewire, jackd, alsa are all the same to me. I never could run a project (small or big) reliable with lower than 512 buffer. for me personally recording tracks in ardour and use ardours monitoring I need to go down to 128 buffer or lower. Otherwise it feels like a “slapback delay” and its messing up my “flow”. So when I got pipewire to run stable at 512 it was kinda good enough for me.

I have tried rt kernels, lowlatency kernels, generic kernels, I’ve compiled kernels following like 200 tutorials through out the years.

I think Im “home free” with my audiodevice used as monitor when recording new tracks.
Would be nice if I could play through some effects inside ardour though. but I think thats not gonna happen for me.

I have worked with disabling features in my mainboard and grub where computer is now more “potent” than ever.

pipewire version 0.3.81 (Releases · PipeWire / pipewire · GitLab) is loading jackd when I start ardour8 or mixbus32cv9 if I choose alsa it also gives alsa my audio device. The backside on this matter is, now I cant listen to youtube, audiosamples at freesound or any other audiostreams at the same time Im working in my favourite daw. and still, the performance its not increasing even jackd is slightly better in performance than pipewire.

A little note I did edit 25 min after this post.
Just so its clear :
I have tried out ardour, mixbus and other daw’s in microsoft/windows aswell. And its no difference(for me). same “latency problems”.

Cheers :slight_smile:

This tells me all I need to know about your understanding of Pipewire, and whether or not to listen to your “opinions”.


Maybe you should have tried with an interface that actually can handle the 128 byte buffer. Throwing even more software at a latency problem isn’t going to help.

First : I think you’re just trolling with me,
Second : you dont know what audio interface I got.
Third : Where did I throw more software in?

You’r conclusion is not very open for scenarios i must say. Throwing out such a statement not knowing all the details. That’s why I thought you where just trolling. If not, Then I apologize.
Still cant figure out where you got that throwing more software at it come from. Alsa, pipewire/pulse, jack is kinda important software for making sound in linux.
Well, have a nice evening. :slight_smile:

Is it possible to run real JACK server in Pipewire? Have any of you tried to do this? Thx! Skygge.

I don’t know what you mean with “in pipewire”.

You can however run pipewire on top of jackd. In that case jackd uses the hardware and you can run all JACK applications as before. And pipewire is just another JACK client not using hardware directly.


I must try that! Thank you!

  • “In pipewire” - I mean… I don’t know really. I want both, working JACK server and Pipewire. In my system (Kubuntu) Pipewire is the default “sound engine”. It simulates JACK. I wonder if you can get rid of pipewire-jack and run real JACK. I don’t know if this makes sense, anyway.

Yes, that is what Robin just described.
I saw in the release notes for the new version of pipewire that it will support that mode of operation by default now. I believe it needs jackdbus, but I did not look through the details to see how it is configured.
You will have to look at the Pipewire documentation to find details needed for setup, but the short version is yes, you can do what you suggested.

1 Like

I have nothing against the idea of Pipewire, and it’s apparent that CoreAudio is a good thing. But personally, I really like that I have to turn on jackd in order to do audio work.

When I do that, my concentration and attention span are increased tenfold. I play with the virtual instruments if I have to or want to, pick up my favorite guitar, connect anything to anything I want, and do the recording and mixing - my mindset changes. I’m in another world where non-musical stuff is not present.

Well, I guess that’s more or less just me, I can clearly live without Pipewire but will probably live well with it when it will be harder to avoid it. :slight_smile:


I run pipewire from systemd as user

Why this response?
Theres so much confusion on howto use pipewire. Probably reason for that are : problems comes and problem goes/are fixed along the way.

I have followed pipewire a while and seen some changes on howto run it , Im not sure this is the right way, since I have not followed any spesific tutorial for this one. I think its pretty closed to the right way. If there is one :smile:

If you want to use jackd and have a systemwide pipewire running. Then one option is to delete or move /etc/ld.so.conf.d/pipewire-jack-x86_64.conf.
this file contains a path to pipewires own libjack.so files.

Ardour will now not find pipewire’s own libjack.so library and the jackd2 package’s libjack.so library will now pick up Ardour and gracefully carry it to victory! :smile:

If you want to have pipewires jack systemwide again.
Just put /etc/ld.so.conf.d/pipewire-jack-x86_64.conf back and do:
sudo ldconfig
then restart pipewire
systemctl --user restart pipewire{,-pulse}.{socket,service} wireplumber.service

Reason for why I personally want this, is that, now I can choose easily btw.

example run
run ardour on top of jackd
In terminal : Ardour8

run ardour on top of pipewires jackd
In terminal : pw-jack Ardour8

I think you need jackdbus running aswell. In ubuntu 22.04 it is in the package jackd2 I think.

In ubuntu 22.04
dpkg -L jackd2 | grep bus

You will also need libpipewire-module-jackdbus-detect.so from pipewires repository :
it is probably in your distros repository somewhere if you use a packetmanager to install pipewire.
If you compile pipewire yourself it comes as default I think.

as skygge made me aware of, so I did change
systemctl --user $1 pipewire{,-pulse}.{socket,service} wireplumber.service
systemctl --user restart pipewire{,-pulse}.{socket,service} wireplumber.service

I apologize for that.

Cheers :slight_smile:

I tested 0.3.79 for a month, it’s perfectly great for general Desktop use. Since my eye is toward deploying it in a Distribution working with BOTH sysvinit and systemd I look at it differently than many people here will. My experience on a Debian Stable base system was not terribly smooth but some of it was not directly PipeWire’s fault:

  • User is not automatically added to the required ‘pipewire’ group
  • The above means no access to security limits.conf.d and thus warnings in Ardour
  • pipewire-jack needs further config to work on system and the Debian Wiki config is outdated
  • There is no pipewire metadata UI in Debian (I had to make my own). There are others in github
  • My Presonus AR-8 is incorrectly recognized as a surround device…
  • Because of the above the Pro Audio template is not available on my machine without config edits…

These are all solvable problems for Audio-savvy and PipeWire configuration savvy Linux Users. This is simply what I personally encountered as a Tester on my own machine, I have to consider what many Users some of whom are brand new to Linux are going to have to deal with on a turnkey Pro Audio system… When I look at the existing Pulse/JACK/pajackconnect system which ‘just works’ on 90% of systems and has full IRQ threading already and route-anything-anywhere capabilities with essentially no configuration required by the user (perhaps changing to USB device in rtirq). When this existing system works perfectly well with both sysvinit and systemd it really would be a foolish move for me to make the change to PipeWire in the context of AV Linux, so for anyone wondering AV Linux 23 on Bookworm (coming soon!) will be retaining it’s current Audio setup for default…

This is NOT a swipe at PipeWire, look at the huge number of people that are happily and productively using it, it is merely what makes the most current sense for me in deploying an existing known-working niche product.


I agree with you. plenty of work to be done.
I have the same experience with jackd also. I had to add my self to the audio (group) in /etc/group.
Another problem jackd have always run as my $USER, so even when I was added to audio group in /etc/group and where audio group was granted in /etc/security/limits.d/config it did not help.

put your user to audio group where jackd is running as your user will not help.

Worst thing is that I did find this out making a config mistake and added my own username into that config. (limits.d).
This is why I never got jackd to work and I thought it was just slow and bloated :sweat_smile:
until now. If you can provide me one link from now and 10 years back that describe this scenario in a userfriendly way , im gonna pull my hair out. :smiling_face_with_tear:

not to mention bios, bad hardware, grub boot tuning, rtkit etc.

since we are talking about it.
Here is some nice info at linuxaudio.org stuff

I’ve updated System configuration [Linux-Sound] with the correct command to add yourself to the audio group (if your system has one). I’d recommend never to edit /etc/group (and also /etc/passwd) directly but always try use commands that do it properly for you like usermod. So no vigr or vipw either.


There is still no info on : howto run pipewire or jack as audio user/group. and that is vital if you ask me.
There is always mentioned to add your user to the audio group. But how you force your application to run as that group is always absent. I think that is just as important.(50 - 50%) if people need help for adding their user to a group. they certainly need help to run the audioserver as that group their adding themselves too. Maby thats a big topic? I don’t know. On this topic, cant be just me? :smile:

I have gone through a lot of the things on your tutorials and its the best site for this matter I’ve seen so far. So, thank you for that! :slight_smile: