can you explain why a new group was needed? why remove functionality from the audio group - that is the commonly expected purpose of the audio group on every distro i have used that caters to A/V use-cases - conversely, what purpose would the audio group now serve? The audio group is installed via syusers.d with the systemd package (defined in /usr/lib/sysusers.d/basic.conf). It's one of the system's default groups, which grants access to /dev/audio and /dev/snd/* [1] (/dev/rtc0, mentioned last, got dropped in by jack/jack2 a few years back). The accompanying udev rule can be found in /usr/lib/udev/rules.d/50-udev-default.rules (also part of the systemd
On 2018-07-29 18:52:36 (-0400), bill-auger wrote: package). Traditionally, other software installing own rules, relies on this group and its settings (e.g. libffado, as found in /usr/lib/udev/rules.d/60-ffado.rules). The compromise introduced a long time ago for the jack and jack2 packages (as described upstream on the realtime topic [2]) also relies on the audio group. However, acquiring realtime privileges and accessing audio hardware are two separate things. Note, that while acquiring realtime privileges can be benificial for pro-audio applications, it is not the only use-case! To make things more clear: audio - access specific audio hardware realtime - acquire realtime privileges (which you can use for pro-audio)
most such distros (including the arch derivative i use) also have a package which is usually named similarly to 'proaudio-settings', that depends on JACK and the kernel-rt and provides optimizations for real-time audio use - but the JACK package should not require the kernel-rt nor any privileges or optimizations; simply because JACK itself does not require those and is intended to be fully usable without them That's exactly why the realtime group will exist and realtime-privileges will become an optional dependency for jack and jack2.
i proposed before the idea of maintaining a consistent 'proaudio-settings' optimizations package in the arch upstream - does this 'realtime-privilege' package do nothing more than create 'realtime' group, with no other optimizations? - if it also has other general optimizations for real-time audio, then i suggest it be renamed to a commonly recognizable name like: 'proaudio-settings' - if not, then i still propose such a 'proaudio-settings' optimization package - such a package would necessarily depend on JACK and the 'realtime-privilege' package - but that would make it clear that it is the optimization package that provides realtime privileges and not the JACK package The "optimizations" (which are more capabilities given to the realtime group) are now all in the realtime-privileges package, instead of redundantly packaged in jack/jack2 and being bound to the audio group (which is there for accessing audio hardware, not for acquiring realtime
It doesn't make any sense to have realtime-privileges depend on linux-rt and or jack/jack2, as realtime-privileges is meant to extend the capabilities of what a certain user group is allowed to achieve with the system (and the system's hardware) and therefore is an extension of what said group can achieve with linux-rt and/or jack/jack2. privileges). Again: Acquiring realtime is not a pro-audio only thing. jack/jack2 can work without acquiring realtime (mind [2]). However, one can extend reliability of some software by acquiring realtime privileges. Therefore it makes no sense to have separate settings for pro-audio, as realtime-privileges is a more general approach to whatever one wants to achieve with that. In other words: You wouldn't want to have to install jack/jack2 just to acquire realtime privileges for another piece of software, that is non pro-audio related, but you can now optionally extend jack/jack2's capabilities by using realtime-privileges (with a more clear distinction as to what the groups you're in actually stand for). I hope this answers your questions. Best, David [1] https://wiki.archlinux.org/index.php/Users_and_groups#Pre-systemd_groups [2] http://jackaudio.github.io/faq/linux_rt_config.html -- https://sleepmap.de