Hi, so I am trying to route audio from jack into pipewire. I used to be able to do this with pactl load-module module-jack-source however since upgrading to Fedora 42 plugging in my USB sound card causes pulse to segfault, so I figured it was finally time to switch.
The docs say we should use libpipewire-module-jackdbus-detect.so to enable pipewire as a jack client, which is provided by pipewire-plugin-jack.
The problem I am having is that package depends on pipewire-jack-audio-connection-kit-libs which provides pipewire’s versions of libjack*.so which break my jack server. So I am in a circular dependency hell where installing the plugin breaks the jack server I want to connect to.
Is this a case of faulty packaging? It doesn’t make much sense to me that the plugin requires the pipewire versions of the jack libs. Or is there something more complex going on here?
It’s difficult to understand when written like this, so could you share some information necessary for solving the problem?
What JACK native client (example: plugin host, DAW, or virtual instrument) are you connecting?
Are you referring to an audio stack with the same concept as pulse?
What docs?
I don’t know of any use cases that use pulse and JACK at the same time. Usually, you choose one and route between clients, or connect clients and effects.
So to clarify my setup: I use JACK for a few purposes. My pro audio setup for production is 100% JACK. I also use JACK for some embedded development (yes there’s JACK running in embedded linux applications, don’t ask). Because of this my primary audio interface (A Scarlett 18i20 1st gen) is perminently handed to JACK via the ALSA driver.
The problem I was previously solving with the pulse-jack bridge was to pass the microphone on the sound card’s channel 1 into my normal “non jack” PC audio so I can use it in video calls etc. I have all of my PC audio for “non pro” stuff routed through my GPU’s audio output.
I am referring to pulseaudio, it literally throw’s a segfault if you try to start it with my Scarlett plugged in. That’s not relevent to my problem I am trying to switch from pulseaudio to pipewire, I have already uninstalled pulse from my system. I only included this detail as motivation for why I am trying to change my setup.
Its an older way of doing things for sure, but the general setup is you use pulseaudio or pipewire to run your normal computer audio experience, browser, system sounds, video playback etc through your normal desktop speakers. Meanwhile when you need to use your “Pro audio” setup you start jack connected to a larger multichannel soundcard.
This has a few advantages:
a notification sound will never show up in my reordings (even if made with extenal equipment)
a notification sound will never be played from my studio monitors at an incredibly high volume
routing things in qjack control is simpler as there is less noise from every chat app / email client etc registering audio ports, that happens somewhere else now.
Don’t have to explain to every application what to do with an 18ch sound card (important for games, proton just shuts off audio if it can’t figure out your channel mapping for instance)
Most applications don’t support JACK. But my DAW runs with noticably lower latency in JACK than pipewire, so running both and bridging gets the best of both worlds
Substancial power savings from being able to turn off all the pro audio gear when I am not using it, without having to reconfigure my desktop audio setup. (Just shut down JACK and the DAW)
The downside is you need two soundcards and two sets of speakers, but my display has speakers which are more than adequate for chat or a few youtube videos etc.
I only have one microphone though, which is the whole motivation for bridging.
Are you using the “standard JACK” or pipewire-jack ?
With pipewire-jack, normally, everything (all audio devices / applications) is visible. Which was not the case with the standard JACK.
In the Audinux repo, you have the ‘alsa-scarlett-gui’ package. This program has a nice interface for the configuration of this audio device.
There is also qasmixer …
Hi Yann, I think you missunderstand my problem. I am trying to bridge Pipewire and JACK together. Not configure my soundcard.
Bridging is a feature that is supported by pipewire and is reported working in other distros. I am trying to open a discussion about a possible packaging error in Fedora, not debug my sound system.
To continue that discussion: I kept poking, by installing the pipewire-plugin-jack package then manually removing the pipewire jack libs from the system with
sudo rm /usr/lib64/pipewire-0.3/jack/ -rfv
(note to anyone finding this page from google this is NOT the solution, don’t go deleting random files from your system unless you really know what you’re doing)
This put me in the state where pipewire would now load the plugin, without any errors in journalctl, and I can still start my jack server with the alsa backend active. However the plugin doesn’t actually seem to be working, no bridge is created, even with “enable Jack D-Bus interface” switched on in qjackctl. Pipewire annoyingly doesn’t seem to log anything ever, so I don’t have many clues what’s going on or not on the pw side.
However the plugin loading without error with the pipewire jack libraries maliciously cut out of the system in my opinion lends more evidence to the package having an uneeded dependency that is creating my conflict.
Yes this worked before on Fedora 41. As mentioned in a post above I can no longer run pulse as it consistently crashes when I attach my USB sound card.
If you install pipewire-jack-audio-connection-kit you will get a JACK compatible server and that is great, JACK and “regular” apps can work together seamlessly. That is the theory. In practice, sometimes you have to run a real JACK server ( jack-audio-connection-kit).
For example if you have a FireWire interface that only works with FFADO drivers.
Now there is support for FFADO in pipewire but it is mostly broken. With my device, pipewire segfaults (Bug report) so I have to run real JACK.
There are ALSA drivers for the device, but there are other issues (broken pipewire profile, ALSA driver not fully working …) that I will ignore, it just complicates the issue and is not relevant.
So, for whatever reason, you are in a situation where you have to run a real JACK server.
You still want to interface with non JACK apps. In the “old days” you would use snd_aloop kernel module and jack tools to create a tunnel into JACK. Then came Pulse and we had Pulse plugin to create a tunnel with JACK.
Now we have, pipewire-plugin-jack.
So you have your JACK server happily running and you want to create a tunnel. You read the pipewire documentation on JACK Tunnel and you install pipewire-plugin-jack. That package has a dependency on pipewire-jack-audio-connection-kit so it installs that too. That also breaks real JACK since the two can’t coexist. Therein lies the crux of the issue.
Besides the practical issue, there is no logical reason to have pipewire-plugin-jack installed if you already have pipewire-jack-audio-connection-kit working. You would not use pipewire-plugin-jack to create a tunnel from pipewire into pipewire via pipewire’s JACK implementation. Those are the logical and practical reasons why pipewire-jack-audio-connection-kit should not be a dependency of pipewire-plugin-jack.
Hope this helps, sorry for the long post, but I had to break it down like that. Kind of ironic that it is hard to explain something that is obvious to you but non-obvious to others.
Just got a notification that my previous post was “flagged by the community” and hidden, I mean really? Whomever it was: are your feelings more important than a workaround for a real issue?
I guess that comment 4 of bug is showing the issue, although the original text
pipewire-plugin-jack package contains a pipewire plugin for JACK audio server.
It’s dependencies are pipewire-jack-audio-connection-kit and pipewire-jack-audio-connection-kit-libs.
Also stated the problem correctly. I admit I had to read this at least 10 times and also read the comment 4 to realize what the real issue is.
In other words. The package pipewire-plugin-jack should not require something it doesn’t need.
Yes, that is correct but one has to explain why the current dependencies are wrong in a bug report. Further problem was the author of pipewire also getting confused about what was stated, sending us down the unproductive spiral.
Maybe it’s the names of the packages that leads to the confusion, naming is too similar, so people lose the “reference”.
