Pipewire changing priority upon restart?

Investigating a subtle crackling problem I noticed that upon restart pipewire (and wireplumber for that matter) change priority from PRI 9 NICE -11 at boot

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                             
   3410 bruno      9 -11  655320  37176  30008 S 0,000 0,230   0:00.20 wireplumber                         
   3414 bruno     20   0   98848  11060   9524 S 0,000 0,068   0:00.01 pipewire-pulse                      
   3409 bruno      9 -11  111348  17448  11560 S 0,000 0,108   0:00.03 pipewire                            

to PRI 20 NICE 0

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                             
   4095 bruno     20   0  655324  36644  29604 S 0,000 0,226   0:00.18 wireplumber                         
   3414 bruno     20   0   98908  11052   9524 S 0,000 0,068   0:00.01 pipewire-pulse                      
   4094 bruno     20   0  111112  18268  11996 S 0,000 0,113   0:00.03 pipewire                            

after a

bruno@LT-B:~> systemctl --user restart pipewire
bruno@LT-B:~> 

A similar check in Leap 15.6 shows that even after a restart both pipewire and wireplumber stay at 9 :-11 as expected.
BTW pipewire-pulse is seen at 20 : 0 in Tumbleweed but at 9:-11 in Leap 15.6 but no pulseaudio app is in use here, so may not be relevant.
I cannot say if that is related to the recent wireplumber and pipewire upgrades since I did not check until today.

Anybody else seeing that? Or is something broken in my local config?

Yes, I do.

1 Like

Thanks, so some more test and maybe a bug report are in order.

Creating the group “pipewire” and adding users to it restores the expected behaviour:
pipewire and wireplumber stay at PRIO 9 NICE -11 even after restart.
See /usr/etc/security/limits.d/25-pw-rlimits.conf for details.
So the problem is apparently linked to rtkit dbus service.
Stay tuned.

@OrsoBruno Hmm, not seeing that here? All PRI 9 NICE -11

pipewire 1.3.82?

LT-B:~ # zypper se -si pipewire wireplumber
Loading repository data...
Reading installed packages...

S  | Name                      | Type    | Version    | Arch   | Repository
---+---------------------------+---------+------------+--------+----------------------
i  | gstreamer-plugin-pipewire | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | libpipewire-0_3-0         | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | libwireplumber-0_5-0      | package | 0.5.8-1.1  | x86_64 | Main Repository (OSS)
i+ | pipewire                  | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i+ | pipewire-alsa             | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-modules-0_3      | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-pulseaudio       | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-spa-plugins-0_2  | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i+ | pipewire-spa-tools        | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-tools            | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | wireplumber               | package | 0.5.8-1.1  | x86_64 | Main Repository (OSS)
i  | wireplumber-audio         | package | 0.5.8-1.1  | noarch | Main Repository (OSS)
LT-B:~ #

@OrsoBruno yes, my list is the same output and versions. On two Tumbleweed systems…

You do not have kpipewire6-imports of any version. If try to uninstall it, then it wants to take the whole Plasma Desktop with it.

I had plain kpipewire-imports with no 6 in the title. It was for KDE 5. I just uninstalled the old pipewire packages for version 5.

You also have nothing labeled for 6 as I do (the 6.3.0-1 packages).
Even if you didn’t upgrade to Plasma 6.3, I believe yours should have version 6.x as long as you are running Plasma 6.

I don’t see the priority and nice issue on my machine.
This machine was upgraded from Plasma 5 to 6 when Plasma 6 was first available, then it has been updated regularly.

> zypper se -si pipewire wireplumber
Loading repository data...
Reading installed packages...

S  | Name                      | Type    | Version    | Arch   | Repository
---+---------------------------+---------+------------+--------+----------------------
i+ | gstreamer-plugin-pipewire | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | kpipewire6-imports        | package | 6.3.0-1.1  | x86_64 | Main Repository (OSS)
i  | libKPipeWire6             | package | 6.3.0-1.1  | x86_64 | Main Repository (OSS)
i  | libKPipeWireDmaBuf6       | package | 6.3.0-1.1  | x86_64 | Main Repository (OSS)
i  | libKPipeWireRecord6       | package | 6.3.0-1.1  | x86_64 | Main Repository (OSS)
i  | libpipewire-0_3-0         | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | libwireplumber-0_5-0      | package | 0.5.8-1.1  | x86_64 | Main Repository (OSS)
i  | pipewire                  | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-alsa             | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-jack             | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-libjack-0_3      | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-modules-0_3      | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-pulseaudio       | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-spa-plugins-0_2  | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-spa-tools        | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | pipewire-tools            | package | 1.3.82-1.1 | x86_64 | Main Repository (OSS)
i  | wireplumber               | package | 0.5.8-1.1  | x86_64 | Main Repository (OSS)
i  | wireplumber-audio         | package | 0.5.8-1.1  | noarch | Main Repository (OSS)

Of course, I’m using Gnome.

1 Like

Reproducible with openSUSE-Tumbleweed-GNOME-Live-x86_64-Snapshot20250218 in VirtualBox, so it is definitely not (only) my local config.

An older GNOME-Live (20241001) is fine on the same VM.

Bug report Bug 1237419

How would I prevent it from lowering its priority?

See above.