On Debian based distros, you can find the relevant information in /usr/share/doc/pipewire/README.Debian.gz. Two “official” methods described in this thread are mentioned there in the section Using pipewire as a substitute for JACK. It can be also found in the official Debian wiki:
https://wiki.debian.org/PipeWire#JACK
1 Like
This is because Debian and Ubuntu do a pretty terrible job of installing PipeWire functional for Audio work. The ‘ld’ step is simply a convenient way to make JACK applications invisibly connect to PipeWire’s JACK implementation and have things work like you’d expect. PipeWire itself isn’t to blame, its the incomplete installation.
Is it just that the defaults aren’t good? I guess I never had setups where I required anything more than ALSA for Ardour, so I haven’t really looked into PipeWire for serious audio stuff.
You need to ask in distribution specific forums, pipewire was undergoing rapid development until last year, and it is contingent on the distributions to package and install it properly since as you note if you have to start from the beginning it is rather complex to get all of the components installed and configured correctly.
Then either don’t set it up, or switch to a distribution which has a more fluid setup.
Part of the issue is that you are on the LTS release of Kubuntu, probably 25.10 has an improved pipewire experience since there were several pipewire problems solved during 2025.
Was there a particular reason you wanted to switch to pipewire-jack? Using pipewire-jack does make it easier to integrate desktop applications such as web browser audio output into your audio production connections, but if the distribution had standardized on jackd2 it probably indicates that the distribution had packaged one of the older pipewire versions which still had errors in pipewire-jack.
Just to be clear, if jackd works for your needs, it is completely fine to continue using jackd, and will likely work better than the version which is installed by default in Kubuntu 24.10. I don’t know if Ubuntu/Kubuntu is doing backports to their LTS installs, if not then you will definitely be better not using old pipewire-jack. If you have the Ubuntu Studio repo enabled and preferably the pipewire update repository enabled then pipewire-jack can work acceptably with recent builds. If you don’t want to go to the trouble of setting up the additional repositories you should probably stick with jackd.
Applications which use jackd link to libjack.so, so if you have jackd and pipewire-jack installed there will be two different incompatible libjack.so files on the system. All applications which use JACK API must link to the same shared library, so if you have pipewire-jack running which has loaded the libjack.so from the pipewire install, and other applications which load the libjack.so from the jackd install you will have problems running.
That is why the pw-jack application exists, so that in the early days when pipewire-jack was being developed it was easy to go back and forth between using jackd and pipewire-jack to check compatibility.
At this point most people should not have both jackd and pipewire-jack installed unless they are actively developing pipewire-jack.
Then you probably use a distribution which packages pipewire-jack reasonably. In my opinon the package manager scripts should be doing that in the background, and it is ridiculous to make a user jump through hoops to finish installing a package that was explicitly requested to be installed.
Seems to be the case. Anyone know if 25.10 does a better job? Hopefully the next LTS does a better job than 24.10 (although in their defense at the time 24.10 was first put together the pipewire-jack implementation still had some significant bugs, so it wasn’t really reasonable to make that the default in early 2024).
tl,dr: If you are running 24.10 then just stick with jackd unless you actually have a good reason to switch to pipewire-jack, and in that case you need to be willing to add additional repositories to get recent pipewire versions installed.
You said:
Firstly, you are considering only the case when the PW-JACK dropin is not enabled: JACK2 will simply refuse to start, with errors when the PW-JACK dropin is enabled. Not sure what problems you could have, since every program trying to use JACK will use the PW-JACK dropin.
Secondly, having PipeWire as JACK client is also a possibility (you can have pipewire-jack installed but not enabled), so please explain why they exist then:
https://docs.pipewire.org/page_module_jackdbus_detect.html
https://docs.pipewire.org/page_module_jack_tunnel.html
Thirdly, you can have the Pipewire package installed but disabled. You can happily run PulseAudio and JACK then.
It seems to work now. OMG! Thank you guys.
I definately have to make a note somewhere, I will forget about this till the next time I need it.
I now installed pipewire-jack, then I had the examples directory from which I copied the pipewire-jack-x86_64-linux-gnu.conf to the /etc/ld.so.conf.d/ directory. I ran sudo ldconfig and that actually seems to do the trick.
Yeah, your’re right, it’s most likely a distro thing. I considered switching to Arch anyway which I hope makes a better job of delivering Pipewire and it has a reliable Wiki. I just anticipated the change for much later this year after test driving Arch for a couple of month on old laptop. I wasn’t ready for the switch just yet.
As an outsider it is sometimes difficult to find the line and distinguish what actually causes the bad experience, especially when frustration sets in.
Thanks for sticking with me through this.
So it wasn’t that difficult, isn’t it? A package and a couple of commands and, magically, it works. 
1 Like
Great! Glad to hear it 
Maybe next time, consider reading documentation or asking on forums instead of asking a bullshit generator 
Especially if you’re considering Arch — your first source should be the Arch Wiki.
1 Like
Once you know how to ride a bike it’s not that complicated. Some forward force a little bit of balance and magically it works … it’s just getting there is painful, especially when every bike works different and everyone you ask has a diffrent approach of dealing with it 
Yeah, also right. As I said, I also made experiences with AI that helped me solve far more complicated things than this. It’s still a double edged sword and I didn’t expected it to turn out so bad. The Arch wiki is actually one of the things that attracts me the most about Arch but I’m a 10 year Ubuntu user and habits still outweigh the readiness to switch.
The problem is not that it’s never right. The problem is that it’s sometimes right and failure modes are inconsistent and unpredictable.
1 Like
I will also say that I have used the Arch Wiki quite often even though I’ve never daily-driven Arch.
I’m not sure I follow what you are referring to as “PW-JACK dropin” in that sentence.
Do you mean the pipewire-jack pipewire module, or the pw-jack application that sets the library load path when starting another application?
I am guessing from context that you mean pipewire-jack module. Is that actually the case that jackd will refuse to start? Typically pipewire will gracefully suspend itself when jackd requests, but I have to admit I have not tried that since my system was switched over to using pipewire-jack instead of jackd.
That is certainly not a typical case. If you install pipewire-jack through a distribution package manager then almost certainly it will be enabled. I cannot speak for every distribution, and it seems that Ubuntu leaves pipewire-jack in a kind of half-enabled state where the server is running but the ld path is not set correctly for applications to load the jack library, but I don’t think it is common knowledge how you would disable a pipewire module once it is installed and running.
I think I stand by my earlier assertion, perhaps with the caveat that if you are an expert users you can switch back and forth between pipewire-jack and jackd, but for typical use cases having both installed using standard distribution package manager methods is likely to result in unexpected behavior.
1 Like
Arch is a continuously updating distribution. If you are willing to switch away from a long term support installation then you could first try Ubuntu 25.10, it will have newer packages but still be familiar to you, and generally have more stable software versions that Arch.
Even better also install the Ubuntu Studio repository for better supported audio software.
Yes, it leaves you in the curious situation that in order to use AI you should first be an expert so that you can quickly realize when it gives completely erroneous information, but if you are already an expert than using AI will probably just slow you down and waste time. If you are not an expert then sometimes it is helpful, and sometimes completely erroneous, which on average will likely waste time.
Besides the Arch Wiki and very active community is the rolling release one of my strongest attraction points. I’m completely done with the Ubuntu upgrade cycle because everytime it ends up in a fresh installation and problems setting up pipewire among other fresh installation problems
I wanted a rolling release type setup but didn’t want to leave my Debian roots. Debian sid it is!
The pipewire-jack pipewire module.
Wrong, in the case of PW libkjack.so enabled. See below.
Not typical, sure, but nonetheless an “allowed” case, desirable by some.
In Debian you have pipewire-jack, it contains with libjack*.so, pw-jack and pipewire-jack-x86_64-linux-gnu.conf among other things.
In the Debian’s case if you don’t enable the the PW’s libjack through the ld.so.conf.d (I like to call it the PW-JACK dropin replacement), you can start JACK and, if started with jackdbus, it will automatically call the PW jack_tunnel via the PW jackdbus_detect (contained in libpipewire-0.3-modules). In this case PW becomes a JACK client, similarly to the old PA-JACK module.
If you enable PW’s libjack aka PW-JACK dropin replacement, PW will not become a JACK client (again, not going out of the way in the sense it happens with PA, as you say) and the real JACK simply will not be able to run.
In Arch you have pipewire-jack and pipewire-jack-client, they serve the above 2 cases.
I’m sorry but, with all the above said, your claim sounds even more wrong to me.
Actually, I would recommend debian testing paired with apt-listbugs.
With sid things will break every now and then, and you need to know how to repair them. I found myself (in the past) a couple of times with an unbootable system.
Honestly, I would recommend OP stay on Ubuntu and get more comfortable with troubleshooting and tinkering, reading manuals and documentation, etc. It’s a huge leap from Ubuntu to Arch and if you don’t know what you’re doing, it’s easy to screw up your Arch install.
That being said, testing can often have bugs linger for days because they don’t have a dedicated security pipeline - everything has to go through sid first. I’ll also say that while I’ve had issues with experimental, I don’t think I’ve had sid break my setup. YMMV of course.
Again I will mention MX Linux here… Based on Debian Stable + tons of VERY useful system tools and so many updated and backported packages that it’s like running a rolling release with a stable core. Comes in KDE, XFCE4 and Fluxbox variants, it’s like Debian Stable on steroids. AV Linux is also built with the MX build system and utilizes it’s Repos. Incidentally AV Linux also comes with all the PipeWire BS you had to deal with already done, you would have just had to select your Audio interface hit record and go… 
2 Likes
Ubuntu is not safe from breaking changes. Just last week a new kernel version (6.17) was among updates for Ubuntu 24.04 and that broke a lots and lots of things. For me the boot hangs for several minutes before advancing and Gog - games running on wine won’t start anymore (worked fine before update). There are many reports of various issues on the web. I’m forced to boot with the previous kernel. I must say I’ve had more luck with Arch - based distros than with Ubuntu. This of course depends on hardware one has.