Summary: | media-video/pipewire: Add 'realtime' local USE flag? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexis <flexibeast> |
Component: | Current packages | Assignee: | Sam James <sam> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | 89q1r14hd, leio |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alexis
2024-04-13 08:12:33 UTC
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. |