← Back to team overview

debcrafters-packages team mailing list archive

[Bug 2107340] Re: [SRU] Pipewire fails to reacquire a realtime priority when restarted

 

** Description changed:

- [Impact]
- Restarting the pipewire user daemon causes it to lose realtime privileges, potentially resulting in hard-to-diagnose choppy audio.
+ [ Impact ]
+ Restarting the pipewire user daemon causes it to lose realtime privileges, potentially resulting in hard-to-diagnose choppy audio. (xruns)
  
- [Test plan]
+ [ Test plan ] 
  1. Fresh boot machine
  2. See expected realtime parameters
  ps -e -o pri,ni,comm | grep wire
   30 -11 pipewire
   19 0 pipewire
   30 -11 wireplumber
   30 -11 pipewire-pulse
  3. Restart the services
   systemctl --user restart pipewire wireplumber pipewire-pulse
  4. Ensure the realtime parameters are unchanged from before the restart,
  ps -e -o pri,ni,comm | grep wire
   30 -11 pipewire
   19 0 pipewire
   30 -11 wireplumber
   30 -11 pipewire-pulse
  
- [Regression potential]
- Backporting both commit dd08d451e3019f4ec6285ecb14d4c746b6e1d420 and 522236e41043a558a825da4cee70ee31ce607147 has a very low regression potential. The first change is purely refactoring commit, which enhances code clarity by renaming functions and variables to better differentiate between pidfds and /proc/$PID directory file descriptors without altering any underlying logic or behavior. The second fixes a specific bug where a function was incorrectly called with a pidfd instead of a /proc/$PID directory file descriptor, introducing a new, correct pidfd-aware function. The PIDFD_GET_PID_NAMESPACE ioctl is a standard Linux kernel interface for interacting with PID file descriptors. Its usage here is straightforward and unlikely to cause unexpected side effects if the underlying kernel support is present.
+ [ Where problems could occur ]
  
- [Original report]
+ The new method of getting pid namespaces from pidfd's could itself be
+ buggy in some unknown way. In the absolute worst case, this would imply
+ no sandboxed apps could request setting threads to realtime
+ (org.freedesktop.portal.Realtime) or access the GameMode API
+ (org.freedesktop.portal.GameMode).
+ 
+ [ Other Info ]
+ This bug was only reproducible on specific versions of the kernel. The combination of this portal brittleness and the kernel currently shipped with Plucky is triggering it.
+ 
+ Backporting both commit dd08d451e3019f4ec6285ecb14d4c746b6e1d420 and
+ dd08d451e3019f4ec6285ecb14d4c746b6e1d420 has a very low regression
+ potential. The first change is purely refactoring commit, which enhances
+ code clarity by renaming functions and variables to better differentiate
+ between pidfds and /proc/$PID directory file descriptors without
+ altering any underlying logic or behavior.
+ dd08d451e3019f4ec6285ecb14d4c746b6e1d420 fixes a specific bug where a
+ function was incorrectly called with a pidfd instead of a /proc/$PID
+ directory file descriptor, introducing a new, correct pidfd-aware
+ function. The PIDFD_GET_PID_NAMESPACE ioctl is a standard Linux kernel
+ interface for interacting with PID file descriptors. Its usage here is
+ straightforward and unlikely to cause unexpected side effects if the
+ underlying kernel support is present (https://lwn.net/Articles/992740/).
+ 
+ See the xdg-desktop-portal package rebuild here:
+ https://launchpad.net/~charles05/+archive/ubuntu/ppa/+packages
+ 
+ Upstream discussion: https://github.com/flatpak/xdg-desktop-
+ portal/pull/1713
+ 
+ [ Original report ]
  Pipewire tries to acquire a realtime priority when it starts via the libpipewire-module-rt plugin. By default, it prefers to use the org.freedesktop.portal.Realtime interface if xdg-desktop-portal is running (it checks if org.freedesktop.portal.Desktop exists on the session bus). If xdg-desktop-portal isn't running, it uses rtkit directly - see https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/1.2.7/src/modules?ref_type=tags#L932.
  
  I started looking at this because I have an annoying issue with my audio
  which results in my speakers making popping noises frequently when
  they're outputting anything. I have another issue where my USB speakers
  are frequently not detected by pipewire without restarting it.
  
  When pipewire starts with a new session, it acquires a realtime priority
  by using rtkit directly because xdg-desktop-portal isn't running at this
  stage. However, if you restart pipewire manually later on when xdg-
  desktop-portal is running, pipewire uses the portal interface to request
  a realtime priority, and this fails with xdg-desktop-portal outputting
  the following error to the journal:
  
  Apr 13 02:58:01 farnsworth xdg-desktop-por[7283]: Realtime error: Could
  not get pidns: Could not fstatat ns/pid: Not a directory
  
  The libpipewire-module-rt plugin does have an option to disable usage of
  the portal interface for requesting a realtime priority
  (rtportal.enabled=false).
  
  This is tested with pipewire 1.2.7 in plucky.
- 
- [Additional information]
- See the xdg-desktop-portal package rebuild here:
- https://launchpad.net/~charles05/+archive/ubuntu/ppa/+packages

-- 
You received this bug notification because you are a member of
Debcrafters packages, which is subscribed to pipewire in Ubuntu.
https://bugs.launchpad.net/bugs/2107340

Title:
  [SRU] Pipewire fails to reacquire a realtime priority when restarted

Status in pipewire package in Ubuntu:
  Triaged
Status in xdg-desktop-portal package in Ubuntu:
  Triaged
Status in pipewire source package in Plucky:
  Confirmed
Status in xdg-desktop-portal source package in Plucky:
  Confirmed

Bug description:
  [ Impact ]
  Restarting the pipewire user daemon causes it to lose realtime privileges, potentially resulting in hard-to-diagnose choppy audio. (xruns)

  [ Test plan ] 
  1. Fresh boot machine
  2. See expected realtime parameters
  ps -e -o pri,ni,comm | grep wire
   30 -11 pipewire
   19 0 pipewire
   30 -11 wireplumber
   30 -11 pipewire-pulse
  3. Restart the services
   systemctl --user restart pipewire wireplumber pipewire-pulse
  4. Ensure the realtime parameters are unchanged from before the restart,
  ps -e -o pri,ni,comm | grep wire
   30 -11 pipewire
   19 0 pipewire
   30 -11 wireplumber
   30 -11 pipewire-pulse

  [ Where problems could occur ]

  The new method of getting pid namespaces from pidfd's could itself be
  buggy in some unknown way. In the absolute worst case, this would
  imply no sandboxed apps could request setting threads to realtime
  (org.freedesktop.portal.Realtime) or access the GameMode API
  (org.freedesktop.portal.GameMode).

  [ Other Info ]
  This bug was only reproducible on specific versions of the kernel. The combination of this portal brittleness and the kernel currently shipped with Plucky is triggering it.

  Backporting both commit dd08d451e3019f4ec6285ecb14d4c746b6e1d420 and
  dd08d451e3019f4ec6285ecb14d4c746b6e1d420 has a very low regression
  potential. The first change is purely refactoring commit, which
  enhances code clarity by renaming functions and variables to better
  differentiate between pidfds and /proc/$PID directory file descriptors
  without altering any underlying logic or behavior.
  dd08d451e3019f4ec6285ecb14d4c746b6e1d420 fixes a specific bug where a
  function was incorrectly called with a pidfd instead of a /proc/$PID
  directory file descriptor, introducing a new, correct pidfd-aware
  function. The PIDFD_GET_PID_NAMESPACE ioctl is a standard Linux kernel
  interface for interacting with PID file descriptors. Its usage here is
  straightforward and unlikely to cause unexpected side effects if the
  underlying kernel support is present
  (https://lwn.net/Articles/992740/).

  See the xdg-desktop-portal package rebuild here:
  https://launchpad.net/~charles05/+archive/ubuntu/ppa/+packages

  Upstream discussion: https://github.com/flatpak/xdg-desktop-
  portal/pull/1713

  [ Original report ]
  Pipewire tries to acquire a realtime priority when it starts via the libpipewire-module-rt plugin. By default, it prefers to use the org.freedesktop.portal.Realtime interface if xdg-desktop-portal is running (it checks if org.freedesktop.portal.Desktop exists on the session bus). If xdg-desktop-portal isn't running, it uses rtkit directly - see https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/1.2.7/src/modules?ref_type=tags#L932.

  I started looking at this because I have an annoying issue with my
  audio which results in my speakers making popping noises frequently
  when they're outputting anything. I have another issue where my USB
  speakers are frequently not detected by pipewire without restarting
  it.

  When pipewire starts with a new session, it acquires a realtime
  priority by using rtkit directly because xdg-desktop-portal isn't
  running at this stage. However, if you restart pipewire manually later
  on when xdg-desktop-portal is running, pipewire uses the portal
  interface to request a realtime priority, and this fails with xdg-
  desktop-portal outputting the following error to the journal:

  Apr 13 02:58:01 farnsworth xdg-desktop-por[7283]: Realtime error:
  Could not get pidns: Could not fstatat ns/pid: Not a directory

  The libpipewire-module-rt plugin does have an option to disable usage
  of the portal interface for requesting a realtime priority
  (rtportal.enabled=false).

  This is tested with pipewire 1.2.7 in plucky.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/2107340/+subscriptions