FS#68848 - [pulseaudio-jack] Incompatibility with pipewire-pulse due to 'pulseaudio=14.0' hard dependency

Attached to Project: Arch Linux
Opened by Alexander Michalopoulos (Nocifer) - Friday, 04 December 2020, 11:36 GMT
Last edited by David Runge (dvzrv) - Tuesday, 08 February 2022, 17:29 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Pipewire is quickly approaching the point where it can completely replace Pulseaudio for everyday use, but for the time being I find myself in need of running Jack through Pulseaudio (instead of running Jack directly through Pipewire) so I can keep using the various GUI tools like session managers, DE sound applets, etc that only know how to talk to Pulseaudio.

The problem here is that pulseaudio-jack (the Jack -> Pulseaudio bridge) conflicts with pipewire-pulse (the Pulseaudio -> Pipewire bridge), because it's set to depend on 'pulseaudio=14.0' and pipewire-pulse does not satisfy this version requirement (I suppose it reports its own version string, 0.3.17 at the time of writing this), so pulseaudio-jack tries to instead pull its parent package pulseaudio (which is what really produces the conflict with pipewire-pulse), despite pipewire-pulse being fully compatible in all other respects.

Manually changing pulseaudio-jack's requirement from 'pulseaudio=14.0' to simply 'pulseaudio' and building the package results in everything working smoothly.

If there is no real reason for specifically depending on 'pulseaudio=14.0' (i.e. some known incompatibility with Pulseaudio<14.0) I would propose that pulseaudio's subpackages like pulseaudio-jack are set to depend on 'pulseaudio' instead, so that they can be installed alongside Pipewire.
This task depends upon

Closed by  David Runge (dvzrv)
Tuesday, 08 February 2022, 17:29 GMT
Reason for closing:  Won't fix
Additional comments about closing:  The specific requirements are there, because pulseaudio introduces breakage on minor version bumps and thus the components must not drift.
Comment by Robert Cegliński (codicodi) - Friday, 04 December 2020, 12:49 GMT
pipewire-pulse actually pretends to be pulseaudio 14:

$ pactl info | grep -P 'Server (Name|Version)'
Server Name: PulseAudio (on PipeWire 0.3.17)
Server Version: 14.0.0

...so I guess providing pulseaudio=14 makes sense
Comment by Alexander Michalopoulos (Nocifer) - Friday, 04 December 2020, 13:23 GMT
Yeah, I failed to mention that it could also be the other way around, i.e. making pipewire-pulse provide 'pulseaudio=14.0' instead of just 'pulseaudio'. Both would fix this issue (pulseaudio-jack et al would be satisfied) and actually it makes more sense that pipewire-pulse should be packaged according to pulseaudio's already established packaging standards.

On a side note, there is also the fact that pipewire-pulse.{socket,service} should be part of pipewire-pulse and not the main pipewire package, but that should probably go to a different bug report.
Comment by Philipp (hollunder) - Saturday, 06 March 2021, 00:55 GMT
I'm surprised no one seems to have noticed and reported this issue yet.
Apparently something in my system update tries to pull in pipewire-pulse, resulting in a conflict that seems related to this old issue.

looking for conflicting packages...
:: pipewire-pulse and pulseaudio are in conflict. Remove pulseaudio? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: removing pulseaudio breaks dependency 'pulseaudio=14.2-2' required by pulseaudio-jack
Comment by Philipp (hollunder) - Saturday, 06 March 2021, 09:15 GMT
I figured out that the silly application demanding pipewire-pulse over pulseaudio is ... pulseeffects!
Comment by Alexander Michalopoulos (Nocifer) - Saturday, 06 March 2021, 10:03 GMT
@hollunder Indeed, PulseEffects just recently decided to go pioneer and adopt Pipewire as its backend instead of the original Pulseaudio; which wouldn't and shouldn't be an issue for the end user if packages could depend on/provide an agreed upon 'pulseaudio' or 'pulseaudio=14' *consistently* across the board, because then pipewire-pulse could transparently replace pulseaudio during a system update (like it tried to do in your case) and all would be well. I mean, it's a real shame, since otherwise Pipewire works flawlessly for my everyday needs and it's only this silly thing with pulseaudio dependencies that's ruining the whole experience.
Comment by Philipp (hollunder) - Saturday, 06 March 2021, 10:23 GMT
I hope these packaging issues get resolved.
Also it's a bit silly by pulseeffects upstream to first depend on pulseaudio and then make a breaking switch to pipewire with the same program.
I
t's good to hear that pipewire works fine for you, however I'm not so sure it works just fine as PA and JACK replacement at the same time and I frankly don't want to play crashtestdummy for it.
Thankfully now that I know that pulseeffects pulled in pipewire it was easy enough to work around for me, simply be uninstalling pulseeffects. I can live without that but I need JACK and PA (and ALSA ofc.) working.
Comment by Alexander Michalopoulos (Nocifer) - Saturday, 06 March 2021, 12:01 GMT
I'm sure all these issues will get resolved in time, it's just that it's still a bit early for the full Pipewire experience. My only gripe is that this particular fix is so easy to implement and would improve the Pipewire experience tenfold.

Also, I don't think PulseEffects switching backends is that silly, I mean, at some point in the near future Pipewire *will* replace PulseAudio as the default sound server, so why not do it early if the change can be transparent for the end user, which it would be if these packaging issues didn't exist? Also, do keep in mind that they keep the 4.x branch around for the time being, precisely for those of us who don't want to become crash-test dummies for Pipewire :)

As for compatibility, Pipewire still does not work properly as a full Jack replacement because among other things it does not support the D-Bus version of Jack, so most modern apps fail to recognize and connect to Jack if it's running through Pipewire (not to mention the lack of tooling for this use case). So for the time being using Pipewire on its own via pipewire-jack is out of the question, and that's why I need pulseaudio-jack, so I can use Jack as per normal and route that through "Pulseaudio", aka Pipewire emulation. When set up like this, so far everything works just fine, because Pipewire does indeed do a good job emulating Pulseaudio.
Comment by Richard Curnow (rc0) - Saturday, 06 March 2021, 18:01 GMT
Regarding "if the change can be transparent for the end user", it certainly wasn't transparent for me. I did "pacman -Syu" on one of my boxes this morning, and hit Y for the prompt to replace pulseaudio by pipewire-pulse. Now I have no sound on that machine. pactl info talks to pipewire fine, but pactl list sinks or sources reports nothing, like pipewire doesn't find my sound cards. I'm still debugging but will probably give up and (as I've uninstalled pulseeffects since I don't need it), revert to pulseaudio. But it sounds like this is a short-term fix, if pipewire will become mandatory sometime.

*Update*: in case it helps anyone else, the problem turned out to be a set of .pacnew files in /etc/pipewire/media-session.d/ that hadn't automatically overwritten their counterparts, even though those had never been edited.
Comment by Alexander Michalopoulos (Nocifer) - Wednesday, 10 March 2021, 10:45 GMT
Ah, it's good you've managed to fix your problem so easily. And thanks btw, because I just checked and I also have these .pacnew files in my media-session.d folder, and I've also been having some issues lately with my sound card not being recognized on system boot unless I restart Pipewire. But oh well, as previously mentioned, even though Pipewire already works surprisingly well (especially considering how "well" Pulseaudio used to work back in its own early days) it's a bit too early still, and between apps and DEs not officially supporting it as of yet and Pipewire itself being unfinished and thus probably buggy in some places, it's to be expected that things may go more or less haywire. But I really expect that at this time next year things will be much better, especially with Fedora adopting Pipewire as the default sound server for its next release.

Now, if only we could package pipewire-pulse and/or pulseaudio-jack in such a way that it would transparently replace pulseaudio :P

Loading...