Re: Deprecation of jack2-dbus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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_section
[3] https://github.com/jackaudio/jack2/issues/429

-- 
https://sleepmap.de

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux