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
