# PipeWire runs without realtime priority on a stock install (`rtkit` is not included)

## Summary

Omarchy does not install `rtkit`, and PipeWire therefore never obtains realtime
scheduling. Its `data-loop` threads run as `SCHED_OTHER` priority 0 — the same
scheduling class as browsers, compositors and games.

This is invisible at idle and only shows up under sustained full CPU/GPU load,
e.g. a long gaming session, where the audio thread misses its period deadline and
capture/playback starts dropping frames. That delay makes it quite hard to trace
back to scheduling, which is why I'm filing it rather than just fixing it locally.

I hit this while chasing intermittent microphone quality in a game; the audio
thread was simply being preempted.

## Evidence

Stock install, Omarchy 4.0.2-1. On PipeWire start the journal shows:

```
mod.rt: RTKit error: org.freedesktop.DBus.Error.ServiceUnknown
mod.rt: RTKit does not give us MaxRealtimePriority, using 1
mod.rt: RTKit does not give us MinNiceLevel, using 0
mod.rt: RTKit does not give us RTTimeUSecMax, using -1
```

The actual thread policy, before installing `rtkit`:

```
$ for p in $(pgrep -x "pipewire|pipewire-pulse|wireplumber"); do
    for t in /proc/$p/task/*; do
      [ "$(cat $t/comm)" = "data-loop.0" ] && chrt -p $(basename $t)
    done
  done

pid 1246's current scheduling policy: SCHED_OTHER|SCHED_RESET_ON_FORK
pid 1246's current scheduling priority: 0
pid 1247's current scheduling policy: SCHED_OTHER|SCHED_RESET_ON_FORK
pid 1247's current scheduling priority: 0
pid 1259's current scheduling policy: SCHED_OTHER|SCHED_RESET_ON_FORK
pid 1259's current scheduling priority: 0
```

PipeWire is asking for RT — its shipped config requests `rt.prio = 88` and
`nice.level = -11` in `/usr/share/pipewire/pipewire.conf` — and is denied.

The rlimits fallback is unavailable too, so there is no second path on a stock
install:

```
$ ulimit -Hr
0
$ ls /etc/security/limits.d/
(empty)
$ id -nG
<user> ... (no realtime or audio group)
```

## Fix

`rtkit` is an official optional dependency of `pipewire` on Arch, for exactly
this purpose:

```
$ pacman -Si pipewire | grep rtkit
rtkit: realtime privileges with rtkit module
```

Optional dependencies are not pulled in automatically, so it has to be listed
explicitly. Adding `rtkit` to `install/omarchy-base.packages` and enabling
`rtkit-daemon` is sufficient.

`rtkit` is the low-friction option here compared to the `limits.d` + `realtime`
group approach: it requires no group membership, so it takes effect after a
service restart rather than a reboot or re-login.

After installing it:

```
rtkit-daemon[...]: Successfully made thread ... owned by '1000' RT at priority 20.
rtkit-daemon[...]: Successfully made thread ... owned by '1000' high priority at nice level -11.

$ chrt -p <data-loop tid>
current scheduling policy: SCHED_RR|SCHED_RESET_ON_FORK
current scheduling priority: 20
```

Priority 20 is rtkit's default cap rather than the 88 PipeWire requests, which is
fine — any realtime priority preempts every `SCHED_OTHER` thread, and that is the
property that matters. Nothing on a stock system sits between 21 and 49; above
that are only kernel IRQ threads (50) and `migration/*` (99), which should
outrank audio.

## Environment

| | |
|---|---|
| Omarchy | 4.0.2-1 |
| Kernel | 7.1.9-arch1-2 |
| pipewire | 1:1.6.8-1 |
| wireplumber | 0.5.15-1 |

`install/omarchy-base.packages` currently lists `alsa-utils` and `wireplumber`
for audio; `rtkit` appears in neither `omarchy-base.packages` nor
`omarchy-other.packages`.