Realtime settings package

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Realtime settings package

David Runge
Hey all,

I'd like to discuss the split-out of the realtime settings for
jack{,2}* (see also the discussion on arch-proaudio [1]) to a separate
Currently they all ship

Redundancy alone would suggest moving these to a separate package, but I
think there is something more to gain from it: Other packages -
potentially requiring realtime scheduling - can benefit from these
settings (by depending or optdepending on such a "settings package").
Currently I am not aware of another use-case, but that might just be me
working on a subset of what is available out there. Any hints or
suggestions on what other software can possibly benefit from this are
very welcome!

The coupling with the audio group is more of a flaw, than anything imho,
as every member of the group "audio", used for e.g. accessing MIDI
devices, is automatically a realtime user (once jack is installed). I
would want to create a dedicated group, e.g. "realtime", that will hold
those limit permissions.
Also rtprio should be reduced to 95, as it is actually rather dangerous
having daemons run at the same pace as the kernel services themselves
(this is a definite upstream documentation flaw [2]!).
This means having a dedicated realtime group, that other packages can
depend on. The only thing needed to use it, is to add a user to a group.

Maybe there are even some ways to do this all with systemd by now?
I have been running jack2 successfully using a systemd user service [3]
for quite some time now (and eventually I plan on integrating it,
because it enables a lingering user to auto-start jack as a service).
However, this would only be a use-case for jack and jack2, but not for
jack2-dbus, as there the request of other applications requiring the
start of jack will not lead to using /usr/bin/jackd, but
/usr/bin/jackdbus by default.

I have looked at how Debian ships jackd2 [4] and they don't use the udev
rule at all. So I'm a little hesitant on whether to continue shipping
it and whether it is actually required. See also this very old bug
report [5], `man 5 limits.conf`, `man 8 pam_limits` for more info on the
overall topic.

Any input is very welcome!




signature.asc (849 bytes) Download Attachment