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