[arch-proaudio] Introducing: dedicated realtime group (not only for jack/jack2)
Hi all, I've created the package realtime-privileges [1], that is now an optional dependency to jack2 [2]. I have removed the realtime privileges bound to the audio group (that are redundantly packaged in jack and jack2). For now this is going to be in [community-testing], until a developer rebuilds jack [3], which will also make it depend optionally on the realtime-privilege package. Afterwards these changes will be rolled out to [community] and [extra]. To sum up, the following will change afterwards: Instead of using the audio group to acquire realtime privileges, you will have to use the dedicated group 'realtime' to which you can add your user. Being part of the audio group is only required to access certain audio hardware from then on! Thanks to Joakim Hernberg (who maintains linux-rt [4] in the AUR), I've now also added access to /dev/cpu_dma_latency, which grants applications the possibility to prevent CPU idle states on demand. If you spot anything that should be changed, let me know! Best, David [1] https://www.archlinux.org/packages/community-testing/any/realtime-privileges... [2] https://www.archlinux.org/packages/community-testing/x86_64/jack2/ [3] https://pkgbuild.com/~dvzrv/extra/jack/PKGBUILD [4] https://aur.archlinux.org/packages/linux-rt/ -- https://sleepmap.de
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? 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 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
A few observations, there might be more use cases for rtprio/memlock privileges than so called "pro audio", so it seems more correct to use a realtime group (as some other distros already do). The realtime privileges are really orthogonal to access to audio hardware.. Also giving audio group users direct access to audio hardware, breaks how the "kits" grant access to audio hardware. I'd agree that letting JACK1/2 "optionally" depend on the new package seems like the right way to do it. Note that nothing here makes it depend on the linux-rt kernel. If you look at the package, it gives the realtime group rtprio up to 98 & unlimited memlock. It also gives the group access to /dev/rtc0, hpet and cpu-dma-latency. Nothing of this is really specific to "pro" audio, but rather could be viewed as realtime related, so I'm fully aboard with this change. I think it would be bad for a package like this to depend on jack, linux-rt, etc. I might want to install and run some realtime app, or just run reaper with alsa, why should I then be forced to install jack, linux-rt, etc..? On the other hand if you need low latency audio, install whatever combination you want/need, of realtime-privileges, jack1/2(-dbus), linux-rt, (udev-)rtirq, apps, etc. -- Joakim
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
So, I don't mean to butt into this discussion or anything, but I was investigating the files the realtime-privileges package added to my system to make sure I was doing everything right, and I found what may be a typo? In /usr/lib/udev/rules.d/40-realtime-privileges.rules, line 4: KERNEL=="rtc0", GROUP="realtimrealtimee" That's supposed to say "realtime", not "realtimrealtimee", right? On Mon, Jul 30, 2018 at 4:34 AM, David Runge <dave@sleepmap.de> wrote:
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.
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.
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 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
On 2018-07-30 10:44:30 (-0700), Jimi Bove wrote:
So, I don't mean to butt into this discussion or anything, but I was investigating the files the realtime-privileges package added to my system to make sure I was doing everything right, and I found what may be a typo?
In /usr/lib/udev/rules.d/40-realtime-privileges.rules, line 4: KERNEL=="rtc0", GROUP="realtimrealtimee"
That's supposed to say "realtime", not "realtimrealtimee", right? Correct. And luckily that has already been brought to my attention yesterday (would've been not so nice to ship this). :-) I've fixed it in version 2 (and blame vim and my jazz hands).
Best, David -- https://sleepmap.de
participants (4)
-
bill-auger
-
David Runge
-
Jimi Bove
-
Joakim Hernberg