[arch-proaudio] limits.conf for jack

[David Runge]

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=packages/usb_modeswitch
[2] https://bugs.archlinux.org/task/56372?project=5&string=usb_modeswitch

-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-proaudio/attachments/20171227/691680a8/attachment.asc>