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