[Pkg-utopia-maintainers] Bug#1011399: pipewire: create pipewire group with rlimits for rtprio/priority/memlock

[Kevin Locke]

Package: pipewire
Version: 0.3.51-1
Severity: wishlist

Dear Maintainer,

During the investigation of a scheduler priority issue in WirePlumber,
Niklāvs Koļesņikovs lamented Debian's use of RTKit for setting
scheduling priority[1], rather than a group with increased rlimits as
recommended in the Pipewire wiki.[2]  Niklāvs noted some of the
benefits:[3]

1. RTKit does not support Flatpak, whereas RLIMITs do work inside user
   namespaces.
2. RTKit usually does not go above priority 19 (though it should be
   noted that there's some level of disagreement in the pro audio
   community on what the appropriate priority for audio daemons [and
   applications] should be).
3. RTKit is known to sometimes think that its canary thread is
   starving when the system exits S3 sleep state, this will cause
   RTKit to revoke realtime from all clients until at least the
   particular client restarts (possibly also RTKit restart but I'm
   not immediately sure if it's that bad). The exact mechanism is
   unknown but speculated to happen if the canary thread or the
   watchdog ends up frozen at particular point making it perceive a
   huge realtime scheduling delay.
4. RTKit is actually abandoned with no upstream being interested or
   active in fixing bugs such as the previously described canary
   starvation issue. Worst of all the same will likely be true if a
   security issue is discovered.

Additionally:

5. It would allow raising the memlock rlimit, not handled by RTKit.
6. It would allow creating the WirePlumber GLib thread pool threads
   at a nice level matching the main thread and avoiding the
   "Failed to set scheduler settings: Operation not permitted"
   currently printed by wireplumber on startup.[4]

Perhaps it would make sense for the pipewire package to create a
pipewire group, configure the suggested rlimit values in a
/etc/security/limits.d/ file, and document use of the group in
README.Debian?

Thanks for considering,
Kevin

[1]: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/255#note_1393924
[2]: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance-tuning#rlimits
[3]: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/255#note_1394696
[4]: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/255

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'unstable'), (101, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-rc7 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pipewire depends on:
ii  init-system-helpers      1.62
ii  libpipewire-0.3-modules  0.3.51-1
ii  pipewire-bin             0.3.51-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information