debcrafters-packages team mailing list archive

[Daniel van Vugt <2107340@xxxxxxxxxxxxxxxxxx>]

Can we clarify the status of the Questing tasks? The referenced pull
request has landed upstream but it sounds like the Questing tasks should
be 'Invalid' if not reproducible.


** Tags added: fixed-in-xdg-desktop-portal-1.21 fixed-upstream

-- 
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