FS#71063 - [pipewire-jack] pipewire-jack should provide jack and libjack.so=0-64

Attached to Project: Arch Linux
Opened by Thomas Girod (tgirod) - Sunday, 30 May 2021, 20:50 GMT
Last edited by David Runge (dvzrv) - Sunday, 16 January 2022, 14:53 GMT
Task Type General Gripe
Category Packages: Extra
Status Closed
Assigned To Jan Alexander Steffens (heftig)
David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

pipewire as a dropin alternative is getting more and more interesting - it would make sense for it to provide jack and libjack.so=0-64 so one can install many pro-audio packages without pulling jack as a dependency.
This task depends upon

Closed by  David Runge (dvzrv)
Sunday, 16 January 2022, 14:53 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with pipewire-jack >= 1:0.3.43-2
Comment by Mark Wagie (yochananmarqos) - Sunday, 30 May 2021, 20:59 GMT
"...install pipewire-jack-dropin or uninstall jack/jack2 to let JACK clients load the compatible libraries automatically."

See https://wiki.archlinux.org/title/PipeWire#JACK_clients
Comment by Eli Schwartz (eschwartz) - Sunday, 30 May 2021, 21:04 GMT
I don't see how this could possibly work since the libraries are in /usr/lib/pipewire-0.3/jack/ and they won't be found by ld.so without being explicitly pointed there at build-time using rpath, or at runtime using ld.so.conf (which the package does not provide).

Actually using this dependency provider would simply break every program trying to link to libjack...
Comment by Eli Schwartz (eschwartz) - Sunday, 30 May 2021, 21:07 GMT
Note the pw-jack manpage specifically points out that you use the pipewire-jack software by running pw-jack which "modifies the LD_LIBRARY_PATH environment variable so that applications will load PipeWire's reimplementation of the JACK client libraries instead of JACK's own libraries."

https://man.archlinux.org/man/pw-jack.1


Apparently it is possible to install as the system jack implementation too, which I think is what you actually wanted.
Comment by Mark Wagie (yochananmarqos) - Sunday, 30 May 2021, 21:19 GMT
@Eli: Were you referring to the origninal query or my comment?
Comment by Eli Schwartz (eschwartz) - Sunday, 30 May 2021, 21:37 GMT
The ticket itself, not your comment.
Comment by Thomas Girod (tgirod) - Monday, 31 May 2021, 07:27 GMT
alright, that makes sense! I just didn't find how to install pipewire as a system-wide replacement for jack.
Comment by David Runge (dvzrv) - Monday, 31 May 2021, 08:10 GMT
It is currently not possible to use pipewire for hardware that relies on e.g. the FFADO driver stack.

While this setup is not super common but affects pro-audio devices, I would be much more happy with a solution that still allows both use-cases.

An intermediate package that introduces the required symlinks or modifies ld.so.conf (similar to how it is done in pipewire-jack-dropin [1]) and conflicts/provides/replaces jack would be much more flexible for the time being, as it will take some time for things to be fully compatible (if at all possible e.g. via ALSA drivers). The current setup allows people to check for compatibility or even attempt a hybrid setup, while still relying on jackd, which is able to use the FFADO driver stack.

[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pipewire-dropin
Comment by David Runge (dvzrv) - Friday, 17 December 2021, 21:15 GMT
As a short update to this topic:

I have created a new upstream project [1] which will allow us to devendor the existing tooling from jack1 and jack2. The effort is tracked in a ticket [2].
Afterwards I will change the pipewire build to have pipewire-jack provide jack.

[1] https://github.com/jackaudio/jack-example-tools/
[2] https://github.com/jackaudio/jack-example-tools/issues/9

Loading...