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