rtkit is silently failing to set real time audio on pipewire / NixOS.
rtkit is saying it's supervising 18 threads, but htop is only showing about 5 realtime threads. Audio also stutters on occasion due to this.
How can I debug this?
❯ journalctl -r --unit=rtkit-daemon.service | head -n 10
Feb 25 16:07:37 Purple-Sunrise rtkit-daemon[1583]: Supervising 18 threads of 10 processes of 2 users.
Feb 25 16:07:37 Purple-Sunrise rtkit-daemon[1583]: Supervising 18 threads of 10 processes of 2 users.
Feb 25 16:07:26 Purple-Sunrise rtkit-daemon[1583]: Supervising 18 threads of 10 processes of 2 users.
Feb 25 16:07:26 Purple-Sunrise rtkit-daemon[1583]: Supervising 18 threads of 10 processes of 2 users.
Feb 25 16:06:45 Purple-Sunrise rtkit-daemon[1583]: Supervising 19 threads of 11 processes of 2 users.
Feb 25 16:06:45 Purple-Sunrise rtkit-daemon[1583]: Successfully made thread 485488 of process 85503 owned by '1000' RT at priority 20.
Feb 25 16:04:36 Purple-Sunrise rtkit-daemon[1583]: Supervising 18 threads of 10 processes of 2 users.
Feb 25 16:04:36 Purple-Sunrise rtkit-daemon[1583]: Supervising 18 threads of 10 processes of 2 users.
Feb 25 15:52:09 Purple-Sunrise rtkit-daemon[1583]: Supervising 18 threads of 10 processes of 2 users.
Feb 25 15:52:09 Purple-Sunrise rtkit-daemon[1583]: Supervising 18 threads of 10 processes of 2 users.
htop sorted by

Same issue, but affected a lot of other process (not only pipewire). Did you get some solution?
This might be a kernel issue. I switched from xanmod to zen and it works like a charm.
I had the same problem:
- Skipping audio for jack clients (quantum=128, rate=48000)
- This was under NixOS also (it wouldn't normally relevant except that nixpkgs carries a few patches to fix logging, etc.)
- Linux 6.7.9
- pipewire
client-rt.confwas configured with"rtkit.enabled" = true, "rlimits.enabled" = false.
Turns out it was due to #13. @YellowOnion Try restarting pipewire.service and checking whether you still get audio skips. If the skips have stopped after restarting pipewire then it suggests that rtkit may have given then later taken away SCHED_RR.
This happens to me constantly on NixOS after resuming from standby.
Here is a "fix" (more like workaround) for NixOS:
# Fix rtkit bug from 2011: https://github.com/heftig/rtkit/issues/13
# As per https://wiki.archlinux.org/title/PipeWire#Missing_realtime_priority/crackling_under_load_after_suspend
# Note: existing entry for ExecStart needs to be cleared using ""
systemd.services.rtkit-daemon.serviceConfig.ExecStart = [
""
"${pkgs.rtkit}/libexec/rtkit-daemon --no-canary"
];