Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#68745 - [jack2] split jackdbus into a separate package

Attached to Project: Community Packages
Opened by hexchain (hexchain) - Wednesday, 25 November 2020, 21:08 GMT
Last edited by David Runge (dvzrv) - Wednesday, 03 February 2021, 19:43 GMT
Task Type Feature Request
Category Packages
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

Description:

Some program (e.g. Catia) tries to connect to the JACK server through D-Bus, and only fallback to use libjack if D-Bus is not available. For people like me that uses PipeWire solely, the original JACK server cannot be started due to the replacement JACK client libraries. Thus, on startup, Catia will hang for a few minutes waiting for the D-Bus activation to fail.

Is it possible (or desirable) to split jackdbus and the service file into a separate package, so that people can selectively get rid of the D-Bus part?

Additional info:
* package version(s)
pipewire 0.3.16-5
pipewire-jack 0.3.16-5
jack2 1.9.16-1
This task depends upon

Closed by  David Runge (dvzrv)
Wednesday, 03 February 2021, 19:43 GMT
Reason for closing:  Implemented
Additional comments about closing:  Implemented with jack2 1.9.17-1
Comment by David Runge (dvzrv) - Thursday, 26 November 2020, 14:45 GMT
@hexchain: Thanks for the report.

How do you start jack?
Comment by hexchain (hexchain) - Thursday, 26 November 2020, 14:49 GMT
I don't start JACK. PipeWire provides ABI-compatible libraries for libjack*.so, so applications using JACK can connect to PipeWire with these libraries. All I need to do is to put a file in /etc/ld.so.conf.d to prioritize the search path of the PipeWire JACK libraries.

However, with this ld path change in place, the real JACK server cannot be started anymore, which is fine given that it's features are now provided by PipeWire.
Comment by David Runge (dvzrv) - Thursday, 26 November 2020, 16:22 GMT
I'm not entirely sure whether we are currently the correct place to report this problem then.

In the future the pipewire-jack package is supposed to be a drop-in replacement of jack, but this is not yet the case.

Splitting out the dbus stuff is not really feasible (we have been there before actually) and is just more fragmentation and more mess.

I'll write to heftig and see whether we can provide a drop-in replacement soonish.
Comment by David Runge (dvzrv) - Thursday, 26 November 2020, 16:26 GMT
Also note: Using jack via pipewire is (still) less performant than using jack directly (and lacks hardware specific features such as libffado support, if that is required).
To my knowledge pipewire on top of jack will remain a supported use-case by upstream (according to Wim Taymans).
Comment by hexchain (hexchain) - Thursday, 26 November 2020, 16:34 GMT
pipewire-jack only provides libjack*, so it's not really a replacement for the whole jack2 package, which in addition contains jack headers and some jack tools.

Fedora also splits jack-dbus out. I'm interested in the reason why jack-dbus is no longer a thing on Arch.
Comment by David Runge (dvzrv) - Thursday, 26 November 2020, 16:51 GMT
@hexchain: The header files are build requirements for clients, not runtime requirements.

As mentioned earlier, having had jack2-dbus meant even more fragmentation. We already have jack and jack2.
The jack2-dbus package was a conflict/provides with jack2. That's not particularly great user experience.

I am not entirely sure, whether the dbus stuff can be made an optdepends of jack2 (only providing e.g. the scripts etc.). FTR: Just because $X does $Y does not mean that it is great or that it will actually work as expected or reliably in our use-case.

You are currently experiencing the forefront of missing integration :)

Joke aside: I will try and get in touch with Wim to check how he envisions this integration.

Did you try with jack(1) btw? It does not have dbus integration.
Comment by hexchain (hexchain) - Thursday, 26 November 2020, 17:00 GMT
> As mentioned earlier, having had jack2-dbus meant even more fragmentation. We already have jack and jack2.
> The jack2-dbus package was a conflict/provides with jack2. That's not particularly great user experience.
Okay, so IIUC jack2-dbus was another full jack2 build with D-Bus enabled? If that is the case, what I mean by "splitting" is something like Fedora's jack-dbus package [1].

> FTR: Just because $X does $Y does not mean that it is great or that it will actually work as expected or reliably in our use-case.
I understand that. I'm not suggesting to remove JACK and force PipeWire for everyone.

> Did you try with jack(1) btw? It does not have dbus integration.
I wasn't aware that jack and jack2 are interchangeable. Good to know!

[1] https://fedora.pkgs.org/rawhide/fedora-x86_64/jack-audio-connection-kit-dbus-1.9.14-5.fc34.x86_64.rpm.html
Comment by David Runge (dvzrv) - Thursday, 26 November 2020, 17:23 GMT
Yes, the jack2-dbus package used to be a full either/or situation with jack2 and jack. A complete mess.

I guess splitting out the dbus only files and making it an optdepend of jack2 can be a solution though. I'll check it out!

Meanwhile I wrote with Wim Taymans and he also suggests leaving dbus out of the game.
Comment by David Runge (dvzrv) - Friday, 15 January 2021, 23:13 GMT
There's now a split package in [community-testing]: jack2 and jack2-dbus

Please test integration with e.g. cadence and qjackctl. Thanks!
Comment by hexchain (hexchain) - Friday, 15 January 2021, 23:26 GMT
Thanks for taking care of this!

It seems to me that qjackctl works fine without jack2-dbus.

I think cadence can also optionally depend on jack2-dbus, because the tools that come with it do not need that (but itself isn't very useful then).
Comment by David Runge (dvzrv) - Saturday, 16 January 2021, 15:30 GMT
Yes, qjackctl by default (AFAIK) uses jackd. If the user selects configuration options for dbus, it will use jackdbus.

However, irt to cadence, it will require jack2-dbus in depends. While the catia executable can potentially use a jack started via jackd, cadence (the main application in that package) only works with jackdbus.
Upstream is about to make catia a standalone project in the future though.

Thanks for testing!

Loading...