Further to this comment of mine on the forums: https://forums.gentoo.org/viewtopic-p-8823323.html#8823323 The default system-wide configuration for PipeWire includes this snippet: # Uses realtime scheduling to boost the audio thread priorities. This uses # RTKit if the user doesn't have permission to use regular realtime # scheduling. { name = libpipewire-module-rt args = { nice.level = -11 rt.prio = 88 #rt.time.soft = -1 #rt.time.hard = -1 } flags = [ ifexists nofail ] } The wiki currently notes: > PipeWire's default configuration tries to use realtime > scheduling to increase audio thread priorities. It's > recommended that users are in the pipewire group. If the user > doesn't have the necessary permissions for this, the > configuration will try to use RTKit instead, so the package > may need to be installed. This behavior is defined under the > context.modules portion of PipeWire's configuration. Unfortunately, this means that "out of the box", PipeWire won't necessarily work, depending on whether RTKit - which is certainly not a hard dependency, and is only a soft dependency in the context of a specific configuration - has already been installed. In my forums comment, i wrote: > i wonder if the ebuild should have a `realtime` local USE flag, > disabled by default, which patches `pipewire.conf` to comment > out the above section so that only users explicitly needing > realtime support will have to deal with needing to ensure > permissions are set up correctly / that `sys-auth/rtkit` is > installed. On the other hand, it might be that, practically > speaking, it might be that realtime support is actually > needed for PipeWire to 'just work' in the most common case, > so i'm not sure what would change in that case. Reproducible: Always
I have mixed feelings on this. We do recommend people put themselves in the group: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/pipewire/pipewire-1.0.4.ebuild#n384 and https://wiki.gentoo.org/wiki/PipeWire#Audio_Groups. On the other hand, one more snippet is not the end of the world. But the ebuild is already complex and a lot of that complexity can never go away.
There's a fundamental misunderstanding here that RTKit would work with system-wide deployments. It will not. At least not without hacking/modifications to RTKit, IIRC. The only method that will work with system-wide is the RLIMIts approach, which, I think, should on Gentoo already be working as-is, since the system wide daemon should be running under pipewire user and pipewire group. In short, unless there's an actual issue being observed, I think this bug is just a nothingburger. Just my two cents on a feverish wim.
Ah, I just realized that system-wide here might have been meant for the default configuration files and not the daemon deployment method (which is unsupported, naturally). Yeah, that is true. However PipeWire would work anyway. Realtime is mainly just an insurance policy to try and combat some of the scheduling issues. But it can't magically fix a broken driver or naughty firmware causing controller hangs or SMM abuse, for example.
