David, Do you want to have a go with the meta package and group creation? I can then revise and push to testing.* * After of course pushing the packages still in line for which you have already nudged me several times! On 27 December 2017 at 04:39, David Runge <dave@sleepmap.de> wrote:

Hey all,

I'd like you to have a look at this bug [1]. Although, I think the whole issue with skype and pulse is a non-issue really (and probably somehow long fixed), the packaging and use of the group being allowed the realtime settings is not.

As both jack and jack2 ship the same limits.conf and udev rule, I suggest to create a "meta" package "realtime" or similar, which in turn those two packages will depend upon and will ship the configuration files. Addditionally, it should create the system group realtime (using systemd-sysusers), to decouple the realtime priorities from the audio group.

Best, David

P.S.: Also, jack2-1.9.12 is out. Use [community-testing] to try it out.

[1] https://bugs.archlinux.org/task/46058

-- https://sleepmap.de

-- GPG/PGP ID: C0711BF1

I prefer to stay with the audio group for rtprio and memlock, since migrating to a new group wouldn't be an advantage for me and only would cause work, e.g. rewriting scripts that check if a user is in the audio group or fixing scripts that chown' a directory or file for realtime users. Anything useful for those using pulseaudio, skype or similar crap is not related to the needs of realtime audio workstation users. It's a PITA that this rubbish (to care about pulseaudio and skype in the context of a realtime audio workstation) gains more and more ground, while there is lean manpower for the Linux pro-audio domain. A good reason to migrate to another OS for pro-audio, if Linux pro-audio development attracts less attention, than bonding counter-productive software. I had doubts to completely migrate to a restricted OS for pro-audio, even while I already use a combination of Linux and Pear, but I get more and more convinced that this soon or later becomes the lesser evil.

On December 27, 2017 1:31:42 PM GMT+01:00, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:

I prefer to stay with the audio group for rtprio and memlock, since migrating to a new group wouldn't be an advantage for me and only would cause work, e.g. rewriting scripts that check if a user is in the audio group or fixing scripts that chown' a directory or file for Maybe you misunderstood me here, Ralf. The realtime group is merely my suggestion, which stands for discussion of course. This is why I wrote the mail and not just dumped a change on your head. The required settings are very jack specific and in no way does it make sense to maintain them twice (in jack and jack2).

Having a separate group from "audio" [1] for the realtime settings for jack/jack2 might be debatable, I agree, but it surely is the cleaner and more modular solution. The acquiring of those limits is bound to groups, that either are created by the filesystem package [2], or by a dedicated package (although I'm still wondering where the audio group is actually being created currently). By Arch embracing systemd-sysusers, this has become properly packageable (not fumbling with creation/deletion of users and groups in install files). So, if anything, using a group called "realtime" or "jack" or whatever for these limits would actually be more specific. Changes like these sadly sometimes come with minor breakage (and changes do occur). However, I think doing a search/replace on a bunch of scripts can't be too hard for an adept user, such as yourself, if this change is properly documented.

realtime users. Anything useful for those using pulseaudio, skype or similar crap is not related to the needs of realtime audio workstation users. It's a PITA that this rubbish (to care about pulseaudio and skype in the context of a realtime audio workstation) gains more and more ground, while there is lean manpower for the Linux pro-audio domain. A good reason to migrate to another OS for pro-audio, if Linux pro-audio development attracts less attention, than bonding counter-productive software. I had doubts to completely migrate to a restricted OS for pro-audio, even while I already use a combination of Linux and Pear, but I get more and more convinced that this soon or later becomes the lesser evil. I'm not sure what you are trying to get at here though. I agree, that pulse and skype (even more so) should not be considered in the implementation of realtime settings for jack. However, Arch Linux provides the means to create systems, that fit your purpose. For some people it might be to dump pulse output in a jack sink. As this is intended behavior, especially when using the jack2-dbus package, this is a use-case, that has to be considered, too.

You might not like this, but other people do have different setups from yours. This does not, will not and should not prevent you from running a rock solid pro-audio system on Arch! We are currently en route to adopting more pro-audio related packages for [community] (after fixing the outstanding ones) and improving their usage. So there (hopefully) really is not much of a reason to rant about it. Best, David [1] https://wiki.archlinux.org/index.php/Users_and_groups#Pre-systemd_groups [2] https://git.archlinux.org/svntogit/packages.git/tree/trunk/sysusers?h=packag... -- https://sleepmap.de

Off-topic On Wed, 27 Dec 2017 16:25:20 +0100, David Runge wrote:

So there (hopefully) really is not much of a reason to rant about it.

In compensation for my Linux audio rant, I'll describe an issue I'm experiencing with the restricted iOS. To free space I removed data that already is backed up and apps I don't need with data that doesn't require a backup. However, there was one exception, I once made a session with an amp simulation app. It wasn't important that time, but yesterday I discovered that I like the sound as well as the music I made for testing purpose. However, I decided to remove several amp simulation apps and by accident I deleted this particular app and so the recording, too. I seemingly never made a backup via the file sharing option. At the moment I scanne the iOS device with free as in beer file recovery software, before that I already scanned with a 30 days free trial software, for no avail. Later I perhaps will restore iTunes in a Windows VM from a VM snapshot and then scann the iTunes backup, too. When using Linux data recovery seems to be easier to do and it's for free as in beer, let alone that I regularly back up _all installs_ and _all data_, since it's not nearly as complicated as saving data by iTunes file sharing to a drive and then making a backup to an external drive. I doubt that the VM snapshot to an older iTunes backup (sync), that has nothing to do with the file sharing option, provides data from a deleted and now reinstalled app, since this data much likely requires usage of the file sharing option to backup the data. In my experiences pro-audio for Apple has got a lot of advantages over Linux pro-audio ... as long as nothing goes wrong. There seldom happen issues, but once a problem arises, it at least for me is much more of an issue, than a similar issue happening for a Linux install.

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