[arch-proaudio] Deprecation of jack2-dbus
Hi all, I've just completed the further decoupling of libffado from jack/jack2 (libffado had a dependency on jack, but was required for jack2) by turning it into an optional dependency. Besides that, looking at our current setup of the jack2 package, I would like to deprecate the jack2-dbus package. Its sole purpose is to *only* be able to use dbus for starting jack. However, we're the only distribution doing this (IMHO weird) separation (AFAIK) and the standard daemon way of starting it will not go away any time soon. This schizm creates further confusion about what to use (the jack/ jack2 schizm is already confusing enough). jack2 features: * supports classic mode (start with jackd) * supports dbus mode (e.g. start with jack_control or cadence) * defaults to jackd (classic mode) jack2-dbus features: * supports dbus mode (e.g. start with jack_control or cadence) * defaults to dbus Caveats: With the jack2 package defaulting to jackd (classic mode), it means, that as soon as jack is not yet started, any program requesting it, will start jack via the jackd executable. However, jackd will remain started with the settings that application has chosen, once the client quits. If the user wants to use the dbus way of starting jack, then it has to be used explicitely (e.g. with jack_control or a client like cadence), *before* any other client wants to start it. With jack2-dbus an application requesting the start of jack will use the dbus interface (AFAIK). The jack instance will remain running, but due to the more flexible nature of the dbus mode, its parameters can be changed on the fly (e.g. changing the periods). With helper tools, such as cadence it should be possible to start jack with one's session. However, users are not able to use jackd when they have jack2-dbus installed (it's not build). Upsides: In the upcoming jack2 1.9.13 there will a templated systemd user unit, which is able to start jackd (in a more or less static way) based on profiles, defining the parameters. This enables the user to achieve something similar to the dbus-start-with-the-graphical-session way, by enabling starting jackd with the user session (even before login of the graphical session). This is quite a benefit to systemd managed (minimal and especially headless) systems, but is of course more generally applicable. Closing, I would like to add, that it can usually be considered the *easiest and best way* (TM) to start jack *before* any client wants to use it. However, setups vary and what works for one, might not work for the other. I would like to hear your concerns regarding this matter (if any). Best, David P.S.: I'm not using DEs such as Gnome or KDE, so my assumptions about integration might be contrary to what your setup is and I might be missing valuable workflows someone is having. -- https://sleepmap.de
Hi David, you bring up a couple of issues here. I'll try to comment on some of them. Am 10.04.19 um 23:06 schrieb David Runge:
I would like to deprecate the jack2-dbus package.
Fine by me, as long as running a system *using* only jackdbus remains easy.
Caveats: With the jack2 package defaulting to jackd (classic mode), it means, that as soon as jack is not yet started, any program requesting it, will start jack via the jackd executable.
(Aside: Technically, not any programs, only those, which use the autostart flag when connecting to jack. This flag is enabled by default, but programs can choose to turn it off.) I always have "export JACK_NO_START_SERVER=1" in one of my shell/session startup files, which prevents autostart of jackd. I wish distributions would do that by default. The whole jack autostart thing is misguided, IMHO.
With helper tools, such as cadence it should be possible to start jack with one's session.
Or, for example, qjackctl or jack-select.
In the upcoming jack2 1.9.13 there will a templated systemd user unit, which is able to start jackd.
Great, another place for jack configuration parameters! :-/
Closing, I would like to add, that it can usually be considered the *easiest and best way* (TM) to start jack *before* any client wants to use it. However, setups vary and what works for one, might not work for the other.
There are people (like me) who only use jack for external audio/midi interfaces and prefer not to have it running all the time (for example, it often does not survive a standby, e.g. on laptop systems). So my stance on this: more options to run and configure Jack might or might not be a good thing, depending on whether they enable additional usage scenarios and not just provide a different way to do the same as was possible before. Anything potentially tying jack closer to systemd will be watched warily by me. Chris
On 2019-04-12 13:53:43 (+0200), SpotlightKid wrote:
Fine by me, as long as running a system *using* only jackdbus remains easy. The 'classic' and 'dbus' will both remain enabled configurations (as it is now the case for the jack2 package).
(Aside: Technically, not any programs, only those, which use the autostart flag when connecting to jack. This flag is enabled by default, but programs can choose to turn it off.) Good point.
I always have "export JACK_NO_START_SERVER=1" in one of my shell/session startup files, which prevents autostart of jackd. I wish distributions would do that by default. The whole jack autostart thing is misguided, IMHO. I agree with that, as it often leads to confused (new) users.
Exporting `JACK_NO_START_SERVER=1` should go to the wiki [1]. Please add it in a "Tips and Tricks" section [2] if you find the time!
With helper tools, such as cadence it should be possible to start jack with one's session.
Or, for example, qjackctl or jack-select. Didn't mention qjackctl, because dbus has to be selected in the settings (it is not chosen by default) to be compatible with jack (1). Otherwise, yes! :)
In the upcoming jack2 1.9.13 there will a templated systemd user unit, which is able to start jackd.
Great, another place for jack configuration parameters! :-/ No, same jackd parameters, but in a more or less standardized way of using a templated systemd user unit.
Closing, I would like to add, that it can usually be considered the *easiest and best way* (TM) to start jack *before* any client wants to use it. However, setups vary and what works for one, might not work for the other.
There are people (like me) who only use jack for external audio/midi interfaces and prefer not to have it running all the time (for example, it often does not survive a standby, e.g. on laptop systems). I have a very similar usecase. The user unit can be enabled (to start with the user's session), or started on demand. I specifically like the integration with journalctl here, but usually start jack on demand (because of external gear).
So my stance on this: more options to run and configure Jack might or might not be a good thing, depending on whether they enable additional usage scenarios and not just provide a different way to do the same as was possible before. Anything potentially tying jack closer to systemd will be watched warily by me. Hm. Well, it is an additional way of starting jackd. There is no "tying" implied here (as far as I'm concerned). Whatever worked before, will continue to work. A templated unit only gives the possibility to use this in a systemd context (if one chooses to do so). It's totally fine to run jackd in a user session scope (unless systemd upstream messes up their setup with limits.d again ;-) [3]). That being said, the diversity of how people like to run their sessions on the various distros is very high.
All in all, it would be very benificial for all users to have better documentation on how to use jack in different use-cases in the wiki, but also to have less fragmentation (concerning which package to install, etc.). Best, David [1] https://wiki.archlinux.org/index.php/JACK_Audio_Connection_Kit [2] https://wiki.archlinux.org/index.php/Help:Style#%22Tips_and_tricks%22_sectio... [3] https://github.com/jackaudio/jack2/issues/429 -- https://sleepmap.de
Am 12.04.19 um 15:00 schrieb David Runge:
but also to have less fragmentation (concerning which package to install, etc.).
Speaking of which: when Jack2 1.9.13 comes around, can we get rid of the python2 / python2-dbus) dependency? Chris
On 2019-04-12 15:56:10 (+0200), SpotlightKid wrote:
Speaking of which: when Jack2 1.9.13 comes around, can we get rid of the python2 / python2-dbus) dependency? Yes. The included waf is compatible with python3.7 again and jack_control has also been changed to work with python-dbus (finally).
Sadly I still have a bunch more python2 based waf setups... :( -- https://sleepmap.de
On 4/10/19 2:06 PM, David Runge wrote:
In the upcoming jack2 1.9.13 there will a templated systemd user unit, which is able to start jackd (in a more or less static way) based on profiles, defining the parameters. This enables the user to achieve something similar to the dbus-start-with-the-graphical-session way, by enabling starting jackd with the user session (even before login of the graphical session). This is quite a benefit to systemd managed (minimal and especially headless) systems, but is of course more generally applicable.
I'll be paying close attention to this, as I've been managing a bunch of service files and helper scripts to manage headless jack systems. I've been focusing it on running out of the top level systemd instance, only enabling linger if I need VNC or something like that to save cycles on some of my wimpier machines. -Sam
participants (3)
-
David Runge
-
Sam Mulvey
-
SpotlightKid