On many (most?) modern desktop systems access to audio devices is controlled by elogind or systemd-logind, and granting permanent access to audio devices by adding users to the audio group goes against this mechanism. For example this may break fast user switching functionality: switching to another user may leave the new user without access to sound devices. So please choose a different group name to raise memlock limit.
It's not that simple. We discussed this in deep in detail in May. Test results are: > Fast-switch without being member of audio group > > 1. User user1 and user2 aren't member of audio group. > 2. user1 will login and starts playing a YouTube video. > 3. user1 will now fast-switch user to user2 (while video is still playing) > 4. Audio will immediately stop playing. > 5. user2 will login. > 6. user2 can open another YouTube video and start playing without any issues. > 7. user2 now switches back to user1 > 8. user1 will be unable to resume YouTube video where he/she left. Website must be reloaded. > 9. Same for any programs, i.e. you would need to stop and start again, i.e. you will lose state. > > Fast-switch while being member of audio group > > 1. User user1 and user2 are member of audio group. > 2. user1 will login and starts playing a YouTube video. > 3. user1 will now fast-switch user to user2 (while video is still playing) > 4. Audio keeps playing, even in login screen. > 5. user2 will login (and user2 will still be able to listen to audio from user1 without being able to stop it) > 6. user2 cannot start playing any other audio because sound device is still in use by user1. > 7. Once the video from user1 ends, user2 maybe able to to start using audio device. > 8. user2 now switches back to user1 > 9. user1 will be able to resume video/audio where he/she left > At the moment we believe that this is the best experience for most users which is BTW in sync with handbook where we instruct new users to add their user to audio group so we can assume they did that already and which is also in sync with latest Fedora release and others. Some power user might want a different experience. However, they know what to do and are also probably using sys-auth/realtime-base already...
As I pointed out and stressed back then: the observation 9. [in case of no audio group] is a bug or teething issue, since /usr/bin/pulseaudio can do it, pipewire-pull should and, I'm sure, eventually will also handle it gracefully. One would wish for JACK applications to also gracefully handle that (and maybe it's possible) but to the best of my knowledge fast user switching or any other dynamic device hotplug/swap is not a common if at all supported use case in the JACK ecosystem, so it may be beyond pipewire's control to make it work gracefully with JACK applications. However this observation does not really make it acceptable to just discard fast user switching, because it currently is rough around the edges. In the end it breaks for one of the users at some point, which is all the more a reason, in my opinion, to prefer the more correct long term solution, if one must be chosen (personally I still think that raising the default for everyone is a better solution overall). The audio group itself is completely orthogonal to the original issue of lockable memory limit and any other name could have been used (which is something obvious that I did point out and, IIRC, also plead for). I explicitly rejected foisting the audio group on Gentoo PipeWire users by quitting, and I'm not aware of anyone else you're working with on PipeWire and specifically that issue, so use of "we" there might not be grammatically correct. ;) Finally pointing to Fedora while tempting is likely not correct, since it seems that wtay as Red Hat employee is in packaging decisions even more constrained than I was as a non-developer - for one an ebuild can install limits.d files for giving people larger lockable buffers, while Fedora doesn't seem to let even its developers do that.
As I was reading the man limits.conf I realized that they only apply when going through Linux PAM such as when doing login. This almost certainly exempts system daemons from being affected by it, therefore the only reason why we are using any group at all rather than raising the default limit like we used to is actually invalid, because it will only affect real people, who 1) are far fewer than system daemons 2) on a desktop system inherently more trusted (due to risk of 0-day privilege escalation bugs) and 3) in the modern day almost certain will want to have good audio experience. In short, it's safe to go back from @audio to * in the /etc/security/limits.d/40-pipewire.conf file: * - memlock 256
This is a bit of a tangential trivia but here's what I have learned about limits.conf since my last message: 1) I have not tested this myself but according to some C developers, it's possible for an application with sufficient capabilities to set whatever RLIMITs it wants on itself at runtime (or perhaps only before forking?). 2) Contrary to the manpage the /etc/security/limits{conf,d/} could in principle be read by other software but it's only worth a thought if they have the capability to raise their own limits as per point 1. 3) When a user logs in if pam_limits.so is included (which should be true by default but in a rather convoluted chain of pam.d files) the RLIMITs from /etc/security/limits{conf,d/} are applied (see man pam_limits for details) *UNLESS* PID1 is systemd in which case the binary is checked for any RLIMITs it has set on itself which are then used instead of the final value from security/limits* files. But only a few values are set by default so for the most part the files may appear to be applied (this subtle discrepancy had been baffling me for months). All in all, unless PAM is somehow being applied to system daemons that do not go through login (which is not impossible but I can't find any documentation stating that it should be the case or where it actually was applied), the RLIMITs changes will not affect them unless they were done via systemd PID1.
> Fast-switch while being member of audio group > ... > 7. Once the video from user1 ends, user2 maybe able to to start using audio device. It might be more complicated in practice. For example, user1 might have pavucontrol or something running, and thus will not relinquish device access. I didn't made sure that it actually was pavucontrol, but, in my experience, user1 did not ever gave up device access.
As far as I can understand, upstream has confirmed that fast user switching and audio group are by design not meant to work together i.e. either fast user switching with no one belonging to the audio group and only logind/elogind ACL being set. Or fast user switching will exhibit missing devices for someone. This is because by design the ALSA backend intentionally ignores the active seat being taken away and instead only relies on whether the HW can be opened or not. For reference: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2052#note_1228317
