Pipewire oddness

I’ve made the (possibly dumb) move to pipewire as the audio system on my Linux box, and I’m a bit puzzled why Mixxx doesn’t recognise that Jack is available as an option.

I can play audio back with "mplayer -ao jack " and it works fine, other applications like audacious and qmmp can use jack audio output, and they work. But Mixxx claims Jack isn’t running when it starts up.

“jack server is not running or cannot be started”

I’ve had a quick look at the code and it seems like portaudio is doing the available audio api detection, but for some reason it doesn’t see pipewire providing Jack. The portaudio devs seem to think it shouldn’t be a problem as it is.

It’s not a game breaker because I can still use ALSA as an option, but I was wondering if anyone was aware of the problem.

Thanks for testing this. I was thinking of testing Mixxx with PipeWire soon but have not gotten around to it yet. I don’t know if the issue is in PipeWire or PortAudio, but I suggest commenting both on PipeWire’s issue tracker and the PortAudio issue you linked.

As long as PipeWire works with one PortAudio backend, I suppose it doesn’t really matter, does it?

It’s not ideal on ALSA. If you imagine pipewire is providing a pulse replacement primarily then your options when assigning booth/master/headphones etc are your primary soundcard (default) or “pulse” (which is pipewire). If you select pulse, you can then use pavucontrol to assign things, but they aren’t remembered between mixxx sessions because pulse/pipewire just sees all the connections as “Mixxx”, and you have to assign them by trial and error because they all appear as “Mixxx”.

I’ve got around it by defining specific devices in my .asoundrc as pulse devices, then I can assign things by name in Mixxx, and they are routed to the right places when Mixxx starts up. I wouldn’t call it ideal, but it works. There shouldn’t be a difference, but I’ll try assigning via alsa definitions in the .asoundrc as well to see if that works.

I think it might be one of those edge case problems where nobody is going to want to take ownership, but we’ll see.

I’m curious how PipeWire works with the PortAudio PulseAudio backend (try not to get confused which “PA” you’re talking about :stuck_out_tongue: ).

Well that’s curiously good timing. I’d be interested to see what happens with that compiled in as well. It’s working smoothly so far with the .asoundrc pulse definitions. FYI: I can’t get useful alsa or jack definitions to work in .asoundrc with pipewire, not sure why yet but only just started fiddling with it.

This is quite a convoluted setup: PortAudio ALSA backend -> ALSA -> PipeWire PulseAudio emulation. I am not surprised it doesn’t work great. PortAudio PulseAudio backend -> PipeWire PulseAudio emulation may work better. Ultimately a new PipeWire backend for PortAudio would probably be best. It would be great if you’re able to write that.

I’m not sure it’s as bad as it sounds for plumbing, most of these stages are lightweight api negotiations. But anyway. Had a chance to run it doing a test set for a fair length of time using my “pulse alsa definitions in .asoundrc” cludge, and it’s pretty good.

Mixxx set to ALSA with 11.6ms buffer, I’ve had 227 underflows in about 1.5hr messing around with a continuous mix. That’s better than I managed with Jack. Not bad!

Ideally we just need a way of labelling the channels displayed by pipewire. I can see them in Mixxx, but it’s just 64 unnamed channels and I’ve no guarantee they’d be allocated the same after a reboot. That really is a Pipewire issue, tools for it are very minimal and not well documented yet.

I did wonder though, maybe portaudio is seeing pipewire’s version of jack when it does it’s enumerate API’s sweep, but perhaps pipewire has changed the name for Jack somehow in the string you get back so Mixxx doesn’t recognise it? Would be nice if it was that simple.

I don’t know, and again, I encourage you to discuss this on PipeWire’s issue tracker. The PipeWire developers are probably the most knowledgeable people to suggest a solution.

Minor update for anyone thinking of moving to pipewire:

You can define named pipewire outputs in your .asoundrc, then just use ALSA in Mixxx and select the devices you set up.

“pw-cli dump short Node”
Will give you a list of your audio devices as seen by pipewire and the names they use.

An example entry in .asoundrc:

pcm.HDA {
	type pipewire
	playback_node "alsa_output.pci-0000:08:00.4.analog-stereo"
	capture_node "alsa_input.pci-0000:08:00.4.analog-stereo"
	hint {
		show on
		description "HDA Audio"
ctl.HDA {
	type pipewire

If it’s just a capture or playback device just delete the node line you don’t want, change “alsa_output…” to whatever the name was you found with pw-cli above.

In Mixxx select “HDA” or whatever you called it in Preferences and it will send audio to the right place.

As far as I can tell this gives you pretty much direct pipewire access from Mixxx.

1 Like

I tested PipeWire with some curious results. At first, Mixxx did not show any outputs for JACK, but I can no longer reproduce this. I posted more details on the PipeWire issue tracker. I think the JACK PortAudio backend will generally work for Mixxx with PipeWire, however, long term we should implement a new PipeWire PortAudio backend because JACK cannot support hotplug. The ALSA PortAudio backend is not nice to use with PipeWire because of the lack of ability to select specific devices and channels in a user-friendly way as you detailed above.

Being able to get Mixxx to see it as Jack is odd. Maybe it’s a config or version change in pipewire? I was using Arch versions, looks like you tried Fedora nightly. For the moment I’ve gone back to using Jack with Pulse as a dumb plugin to Jack because I was getting some other glitches in pipewire as well, so I’m not able to quickly see if an arch update has fixed that issue. But it does look like pipewire is unavoidable in the future, so the portaudio compatibility does seem the only sane solution long term.

@Mogs could you please comment on my PortAudio pull request asking the maintainers to merge it for their upcoming release so Mixxx can reliably with PipeWire?

After upgrading to portaudio 19.7.0, I am still getting the “jack server is not running or cannot be started” error, and a Jack option is not available. Mixxx 2.2.4

Did you start mixxx via pw-jack?

Yes, of course. More accurately, I have overridden libjack via /etc/ld.so.conf.d/ .