PipeWire Quantum in 2026: Choosing 64, 128, 256, or 512 Without XRuns (A Repeatable Test Method)

Every PipeWire forum thread about buffer sizes follows the same arc. Someone asks what quantum to use. Twelve people answer with the number that works on their machine. None of them explain how they arrived at it.

The quantum is the number of audio frames PipeWire processes per cycle. At 48 kHz, a quantum of 256 means PipeWire must fill 256 frames every 5.33 ms. Miss that deadline and you get an XRun - a gap in the audio stream that sounds like a click, pop, or dropout. The quantum directly controls your round-trip latency, and lower values demand more from your hardware, kernel, and real-time scheduling setup.

Choosing the right quantum is not about picking a number from a forum post. It is about measuring where your specific system falls over and then backing off from that edge.

Why quantum choice matters

The quantum sets the processing period for the entire PipeWire graph. Every node in the graph - your DAW, software synths, effects plugins, system sounds - must complete its work within one quantum period. If any node exceeds the budget, the driver reports an XRun.

The relationship between quantum and latency at 48 kHz is straightforward:

Quantum	Period (ms)	Round-trip latency (ms)	Typical use case
32	0.67	~1.3	Extreme low latency, rarely stable
64	1.33	~2.7	Live monitoring, simple chains
128	2.67	~5.3	Production with moderate plugin loads
256	5.33	~10.7	Mixed workloads, most interfaces
512	10.67	~21.3	Heavy plugin loads, complex routing
1024	21.33	~42.7	Mixing, mastering, no live input

Round-trip latency is approximately two periods because PipeWire double-buffers: one period for capture, one for playback. Your audio interface adds its own fixed latency on top of this, typically 1-3 ms depending on the USB or PCIe implementation.

For a deeper look at how these numbers translate to real-world performance, see the latency measurement data we maintain.

The test methodology

Here is a repeatable method for finding your lowest stable quantum. You will need about 30 minutes and a terminal.

Step 1: Establish your baseline

First, check your current PipeWire configuration:

pw-metadata -n settings

Look for clock.force-quantum or clock.quantum in the output. If clock.force-quantum is set, that overrides everything. Note your current values.

Check what the graph is actually running at:

pw-top

The QUANT column shows the active quantum per node. The driver line at the top shows the graph-wide quantum.

Step 2: Start a representative workload

Do not test with an idle desktop. The point is to find your XRun threshold under real conditions. Open your DAW, load a typical project, and start playback. If you do not have a project ready, use a synthetic load:

pw-cat --playback --target 0 /dev/urandom --format f32 --rate 48000 --channels 2 &

This gives PipeWire something to process. For a more realistic test, run multiple instances or add a LADSPA plugin chain.

Step 3: Set quantum and measure

Change the quantum at runtime without restarting PipeWire:

pw-metadata -n settings 0 clock.force-quantum 256

Let it run for at least 5 minutes. Watch pw-top in another terminal:

pw-top

The ERR column counts XRuns per node. The W/Q column shows the wait time as a fraction of the quantum period - this is how close you are to the deadline. A W/Q above 0.8 means you are living dangerously.

Step 4: Ratchet down

Drop to the next lower quantum:

pw-metadata -n settings 0 clock.force-quantum 128

Wait another 5 minutes. Record the ERR count and the peak W/Q value. Then try 64:

pw-metadata -n settings 0 clock.force-quantum 64

Same procedure. If XRuns appear within seconds, that quantum is not viable for your hardware under this workload.

Step 5: Find your threshold

Your stable quantum is the lowest value where you can run for 10+ minutes under a representative workload with zero entries in the ERR column and W/Q staying below 0.75. That margin matters - a system running at W/Q 0.95 with zero XRuns will fall over the moment you add one more plugin or a browser starts playing a video.

Step 6: Lock it in

Once you have your number, set it permanently:

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

The min-quantum and max-quantum let PipeWire dynamically adjust within a range if you prefer that approach. If you want a fixed quantum regardless:

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

Restart PipeWire to apply:

systemctl --user restart pipewire pipewire-pulse wireplumber

Common mistakes that produce misleading results

Testing without load. An idle PipeWire graph can run at quantum 32 on almost anything. That tells you nothing about what happens when Ardour is running 40 plugin instances.

Ignoring USB polling interval. USB 2.0 audio interfaces poll at 1 ms intervals (microframes at 125 us for USB 2.0 high speed). A quantum of 64 at 48 kHz is a 1.33 ms period. If your USB interface has jittery polling, you will get XRuns at quantum 64 that have nothing to do with CPU performance. Check your interface's actual polling behavior:

cat /proc/asound/card*/stream0

Look for the Momentary freq and Feedback Format lines.

Forgetting about other system activity. Run your test with your normal desktop environment active. If you use Firefox, have it open. If you run a compositor, keep it running. Test the system you actually use, not a stripped-down test environment.

Not accounting for thermal throttling. Run the test long enough for your CPU to reach steady-state thermal conditions. A 2-minute test on a laptop that has been idle will show better results than reality because the CPU has not throttled yet.

When quantum 64 is realistic

Quantum 64 at 48 kHz (1.33 ms period) is achievable on systems that meet all of these conditions:

• PCIe or Thunderbolt audio interface (not USB 2.0 class-compliant)
• Real-time scheduling properly configured (SCHED_FIFO priority 50+)
• A kernel with PREEMPT_DYNAMIC or full preemption enabled
• Modest plugin load (under 20 instances)
• CPU with consistent single-thread performance (no aggressive power saving)

If you are using a USB class-compliant interface on a laptop with power management enabled, quantum 128 is a more realistic minimum. There is no shame in running at 256 - many professional workflows operate there.

When quantum 256 or 512 is the right choice

Higher quanta are appropriate when:

• You are mixing or mastering and do not need live monitoring
• Your project has heavy plugin loads (convolution reverbs, amp simulators with oversampling)
• You are running a complex routing setup with many PipeWire nodes
• Your system is a general-purpose desktop that also does audio work
• You need rock-solid stability for a live performance or recording session where one XRun is unacceptable

A quantum of 256 at 48 kHz gives 5.33 ms per period and roughly 10.7 ms round-trip. For tracking with headphone monitoring, most musicians can work comfortably with round-trip latency under 12 ms. That puts you right in the zone.

Production tradeoffs

Lower quantum means lower latency but also means:

• Higher CPU overhead from more frequent context switches
• Less time for plugins to complete their processing
• More sensitivity to system jitter from interrupts, USB traffic, and GPU activity
• Higher power consumption (the CPU cannot enter deep sleep states)

Higher quantum means higher latency but buys you:

• More headroom for heavy processing
• Better stability under variable system loads
• Lower power consumption
• Fewer scheduling-related audio glitches

The benchmarks we have collected show these tradeoffs quantified across different hardware configurations.

A note on sample rates

Everything above assumes 48 kHz. If you run at 96 kHz, a quantum of 256 gives you only 2.67 ms per period - the same timing as quantum 128 at 48 kHz. Double the sample rate, double the processing demand per unit time. Account for this when choosing your quantum at higher sample rates.

Sample rate	Quantum 128 period	Quantum 256 period	Quantum 512 period
44100 Hz	2.90 ms	5.80 ms	11.61 ms
48000 Hz	2.67 ms	5.33 ms	10.67 ms
96000 Hz	1.33 ms	2.67 ms	5.33 ms
192000 Hz	0.67 ms	1.33 ms	2.67 ms

FAQ

Can I change the quantum without restarting PipeWire? Yes. pw-metadata -n settings 0 clock.force-quantum <value> takes effect immediately. This is how you should test.

What if different applications need different quanta? PipeWire can handle nodes requesting different quanta. The driver uses the smallest requested quantum that satisfies all active nodes. In practice, set your quantum based on your most latency-sensitive application.

Does quantum affect audio quality? No. The quantum only affects timing, not signal processing. A quantum of 1024 does not sound different from 64 in the signal path - it just adds more latency.

My interface documentation says it supports 32 samples. Should I use quantum 32? The interface supporting 32-sample buffers does not mean PipeWire can reliably process an entire graph in that time. The interface buffer and the PipeWire quantum are related but separate concerns. Test it with the method above before committing to it.

I set quantum 64 and it works, but I get occasional pops every few minutes. You are right at your threshold. Increase to 128. Those intermittent XRuns are caused by system activity that occasionally pushes processing past the deadline - a disk flush, a network interrupt, a compositor frame. Under sustained use they will get worse, not better.

Conclusion

The quantum is the single most impactful PipeWire setting for audio work, and the only honest way to choose it is to measure. Start high, ratchet down, record your XRun counts and W/Q ratios, and pick the lowest value that stays clean under a real workload with margin to spare. Your number will be different from mine, and that is the whole point.