Xruns and driver election

Symptom

Clicks, ticks and short dropouts. The xrun counter in the surface's telemetry panel climbs. Often worse on a rig that has an audio interface plugged in but unused.

What a driver is, and why it matters

Every PipeWire graph has one node acting as its driver: the node whose clock the whole graph follows. Every other node runs to that node's cadence.

The election is automatic, and it does not know which device you care about. A capture device that is present but doing nothing can be elected the driver, and then the entire console — including playback — is being timed by a device with no reason to be timely. That produces exactly this symptom.

Check which node is driving

pw-top

The driver is at the top of each group. Look for a device you are not using appearing there, and for the xrun columns.

Fix: get the idle device out of the way

The clean solution is for the device that actually carries your audio to drive the graph. Options, in order of preference:

Unplug or disable the unused interface. If nothing needs it, this ends the problem.
Suspend the unused node. Suspending an idle capture device stops it being a candidate; the playback side then drives.
```
pw-cli list-objects Node | grep -i node.name    # find the offender's name
```
WirePlumber's device configuration is where to make this permanent for a given card.
Set an explicit profile on the interface so the ports you do not use are not presented at all. On a card with a pro/DAW profile, choosing it deliberately usually removes a pile of unused endpoints.

Fix: give the graph enough time

If the driver is right and xruns persist, the graph is running out of time rather than being mistimed.

Quantum. The telemetry panel reports the buffer quantum. A larger quantum buys headroom at the cost of latency.

# ~/.config/pipewire/pipewire.conf.d/20-quantum.conf
context.properties = {
    default.clock.quantum     = 1024
    default.clock.min-quantum = 256
}

Plugin load. The per-channel, per-plugin latency breakdown in telemetry shows where the time goes, and channel latency badges turn hot when a path runs long. A single expensive plugin on many channels is the usual answer.
CPU governor. A laptop on a power-saving governor will xrun under load that a performance governor handles without effort.
Real-time scheduling. PipeWire needs it. If the session has no real-time limits the whole graph is at the mercy of the scheduler.

Fix: stop the contention

Another application fighting the mixer for the same card produces periodic dropouts that look like xruns. The console can take exclusive control of the device sinks — severing every non-mixer application link, while those applications stay visible in the patchbay for manual patching. It is opt-in; see environment variables.

If it is a stagebox that sounds wrong rather than the whole graph

Xruns make everything click. A stagebox that sounds granular while the rest of the graph is clean is a different fault: see granulated or stuttery box audio.