[arch-proaudio] limits.conf for jack

[Joakim Hernberg]

I think that quite possibly the change in skype priorities might be
exactly because we use the audio group.  I know that using the audio
group for this isn't popular with the systemd/*kit group, since it
gives access to audio devices, etc.

My original suggestion to Rashif many years ago :) and David recently
was exactly to create a realtime group in order to de-couple realtime
permissions (rtprio & memlock) from access to audio devices.  After all
they are completely orthogonal to each other.  I could imagine that
there could be more uses for realtime, so the audio group seems badly
chosen, and I suspect that this is just a bad legacy from the past.

My suggestion is a meta package called realtime or some such, which
sets rtprio to 98 (as there are kernel house keeping threads running
 at 99), and sets memlock to unlimited.  What to do with access to the
 hpet device I'm not quite sure, maybe you guys have some opinions.

This would allow an administrator to add a user to the realtime group
to actually give him access to the needed privileges without giving
him access to the sound devices...

Regarding other thoughts expressed, imo limiting rtprio to 10 is
quite moronic just because jack defaults to 10, there are definite
advantages to setting it above 50 for instance..

I suppose that any package that really needs rtprio access but not as
high as that as the realtime group, could just create it's own group?

There is also the simple option for the administrator to give a specific
user privileges by simply adding a user name instead of a group to
limits.conf, which is how I've run my system for many years now :) This
mainly because I wanted to decouple rt privs from access to audio
devices...

Over to you, as this inconsistency is something that has bothered me
for years.  We could also investigate if the user really needs access
to the hpet device, I'm not sure but I think it's not necessary for
JACK to work properly.

-- 

   Joakim