[arch-proaudio] limits.conf for jack
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
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.
-- GPG/PGP ID: C0711BF1
I just realized I sent this only to Ray. Sorry, that you'll get this twice. On December 27, 2017 12:28:41 AM GMT+01:00, Rashif Ray Rahman <schiv@archlinux.org> wrote:
Do you want to have a go with the meta package and group creation? I can then revise and push to testing.* Sure, I'll have a look at it by the end of the year. Have an upcoming performance to take care of first.
* After of course pushing the packages still in line for which you have already nudged me several times! Hehe, that would be great. Especially lilv, liblo and ardour.
On 27 December 2017 at 04:39, David Runge <dave@sleepmap.de> wrote:
Addditionally, it should create the system group realtime (using systemd-sysusers), to decouple the realtime priorities from the audio group.
This has the additional benefit of other packages being able to depend on it (although I'm not aware of any requiring it), for e.g. realtime video processing. AFAIK, pulse still has contradictory realtime settings to jack, when ran in a joint fashion. So, for 'real' work I usually disable it or have it only take care of the internal (laptop) hardware. Any opinions on it? As a sidenote: I think software such as skype (if it has to be run), should be jailed and restrained to the maximum amount possible. It has access to the user's home, is closed source and well, you know the rest ;-) Best, David -- https://sleepmap.de
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.
On Wed, Dec 27, 2017 at 12:56:16PM +0100, David Runge wrote:
On 27 December 2017 at 04:39, David Runge <dave@sleepmap.de> wrote:
Addditionally, it should create the system group realtime (using systemd-sysusers), to decouple the realtime priorities from the audio group.
I'm not sure this is a good idea. There is no reason why application classes that require realtime or locked memory (audio, video, sdr,...) should all have the same limits. The way limits.conf works is that you can have any matrix of users/groups vs. limits. Accessing each individual limit (e.g. realtime) only via a single dedicated group (which seems to be the underlying idea) takes away that degree of freedom. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Hi Fons, On December 27, 2017 1:59:17 PM GMT+01:00, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Wed, Dec 27, 2017 at 12:56:16PM +0100, David Runge wrote:
On 27 December 2017 at 04:39, David Runge <dave@sleepmap.de> wrote:
Addditionally, it should create the system group realtime (using systemd-sysusers), to decouple the realtime priorities from the audio group.
I'm not sure this is a good idea.
There is no reason why application classes that require realtime or locked memory (audio, video, sdr,...) should all have the same limits.
The way limits.conf works is that you can have any matrix of users/groups vs. limits. Accessing each individual limit (e.g. realtime) only via a single dedicated group (which seems to be the underlying idea) takes away that degree of freedom. This is actually how it has been done by packaging jack/jack2 [1] [2] for years in accordance to upstream documentation on the topic [3]. As you can see in the first two links, this has been bound to the "audio" group, that is also used by alsa for device permissions.
Do you have an alternative suggestion that is packageable? Best, David [1] https://git.archlinux.org/svntogit/community.git/tree/trunk/40-hpet-permissi... [2] https://git.archlinux.org/svntogit/community.git/tree/trunk/99-audio.conf?h=... [3] http://jackaudio.org/faq/linux_rt_config.html -- https://sleepmap.de
On Wed, Dec 27, 2017 at 04:44:19PM +0100, David Runge wrote:
Do you have an alternative suggestion that is packageable?
It's not entirely clear to me what you understand by 'packageable'... But what I mean is this: - If creating a 'realtime' group (and associated limits) is 'packageable', then so is creating an 'audio' group, it's just a different name. - So if either is done, I'd say the 'audio' option is the better one, because it doesn't interfere with realtime limits required by e.g. video or sdr, which may be different. So my preferred way is that groups should reflect classes of applications or activity (like audio, video,...), and not individual limits. In other words I don't really agree with your [3] which suggest using 'realtime' as the group name. Jack, or audio isn't the only application that may require realtime. What group name should the others use if Jack has already taken 'realtime' ? Something different which you may understand better than I do : I noticed after a recent update that the usb-modeswitch for my Huawei LTE stick didn't work anymore. I now have to do this manually in the script that starts my internet connection using wvdial. Can this be related to systemd-sysuser ? If so, what is the 'official' solution ? Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
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
On 2017-12-27 16:56:49 (+0000), Fons Adriaensen wrote:
On Wed, Dec 27, 2017 at 04:44:19PM +0100, David Runge wrote:
Do you have an alternative suggestion that is packageable?
It's not entirely clear to me what you understand by 'packageable'... "Packageable" would mean to ship system configuration in a way, that it can be easily used. In this specific case I am referring to the mentioned udev rule and the limits.conf snippet (which are already packaged, but redundantly). Additionally, when talking about a separate group to be able to map jack's specifically required settings to it, that would also be shipped (i.e. packaged).
But what I mean is this:
- If creating a 'realtime' group (and associated limits) is 'packageable', then so is creating an 'audio' group, it's just a different name. Exactly. In this case "audio" is already created by the systemd package and mainly used for alsa purposes (access to audio devices). The jack/jack2 package then installs additional files (see above) to elevate that group's permissions.
- So if either is done, I'd say the 'audio' option is the better one, because it doesn't interfere with realtime limits required by e.g. video or sdr, which may be different. That is exactly why you would not want to couple it with the audio group though, if you can have a separate group, specifically for realtime and/or jack's required settings.
So my preferred way is that groups should reflect classes of applications or activity (like audio, video,...), and not individual limits. In other words I don't really agree with your [3] which suggest using 'realtime' as the group name. Jack, or audio isn't the only application that may require realtime. What group name should the others use if Jack has already taken 'realtime' ? Which is why I am proposing a separate group, as the "audio" group is already used for access to sound devices. The group name "realtime" might be somewhat too generic though, if not aiming for an "accesss all areas" pass ;-) Something similar to "jackusers", etc. would work too.
Apart from that: There currently is no "realtime" group, so it could be used for generic settings that can be used by jack and/or other packages requiring it.
Something different which you may understand better than I do : I noticed after a recent update that the usb-modeswitch for my Huawei LTE stick didn't work anymore. I now have to do this manually in the script that starts my internet connection using wvdial. Can this be related to systemd-sysuser ? If so, what is the 'official' solution ? Sorry, but I haven't used that package in a long time, so I don't really know any specifics. AFAICS it is not relying on systemd-sysusers [1]. If something doesn't work as expected, you might want to open a bug report for it though, or look at those currently open [2].
Best, David [1] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa... [2] https://bugs.archlinux.org/task/56372?project=5&string=usb_modeswitch -- https://sleepmap.de
participants (5)
-
David Runge
-
Fons Adriaensen
-
Joakim Hernberg
-
Ralf Mardorf
-
Rashif Ray Rahman