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