Low Latency Audio Checklist for 2026: CPU Governor, IRQ Behaviour, USB Power, and Small Buffer Reality Checks

You have installed an RT kernel, configured PipeWire, set your quantum, and it still crackles. Or it works perfectly for twenty minutes and then drops out during the bridge of the third song. Low-latency audio on Linux depends on a stack of settings, and missing any single one can undo everything else.

This is the checklist. Each item is independently verifiable with a terminal command. Work through it top to bottom. Every item you skip is a potential source of XRuns at quantum 128 or below.

1. Kernel preemption model

Check what preemption mode your running kernel supports:

uname -v
# Look for PREEMPT_RT or PREEMPT_DYNAMIC

cat /sys/kernel/realtime
# Returns 1 if full PREEMPT_RT

If you see PREEMPT_DYNAMIC, you have a standard kernel with voluntary preemption. This is fine for quantum 256 and above. For quantum 128 or lower under load, you want PREEMPT_RT. See the kernel guide for how to get there.

Target state: PREEMPT_RT for serious low-latency work. PREEMPT_DYNAMIC acceptable for quantum 256+.

2. CPU frequency governor

The governor controls how the CPU scales its clock speed. Audio threads need consistent performance, not power-saving behavior.

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | sort -u

If it says powersave or schedutil, your CPU is dynamically clocking down between audio cycles and ramping up when PipeWire wakes. That ramp takes microseconds to tens of microseconds depending on your processor, eating into your quantum budget.

Set performance mode:

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

To make it persistent, create a systemd tmpfiles rule or use a udev rule:

# /etc/tmpfiles.d/cpu-governor.conf
w /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor - - - - performance

On laptops: The performance governor prevents the CPU from entering low-power states. If you need battery life when not doing audio, create a script that toggles the governor:

#!/bin/bash
# toggle-audio-mode.sh
if [ "$1" = "on" ]; then
  echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
else
  echo schedutil | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
fi

Target state: performance during audio sessions, confirmed on all cores.

3. Real-time scheduling for PipeWire

PipeWire needs SCHED_FIFO priority to preempt normal processes. Verify it is active:

ps -eLo pid,tid,cls,rtprio,comm | grep pipewire

Look for FF (SCHED_FIFO) in the CLS column and a number in the RTPRIO column. Priority 88 is the default when rlimits are configured. Priority 20 means RTKit is the active mechanism.

If the CLS column shows TS (SCHED_OTHER, normal scheduling), PipeWire has no real-time priority at all. This is the most common cause of unexplained XRuns.

The real-time scheduling guide covers the fix in detail. The quick version:

# ~/.config/systemd/user/pipewire.service.d/realtime.conf
[Service]
LimitRTPRIO=95
LimitMEMLOCK=infinity
LimitNICE=-20

Then reload and restart:

systemctl --user daemon-reload
systemctl --user restart pipewire pipewire-pulse wireplumber

Target state: PipeWire running at SCHED_FIFO priority 88 confirmed via ps.

4. Memory locking

Audio buffers must stay in physical RAM. If the kernel swaps audio buffers to disk, you get multi-millisecond stalls that blow any quantum.

ulimit -l

This should return unlimited. If it returns a number, your memlock limit is capped. Fix it alongside the rlimits configuration above, or through limits.conf:

# /etc/security/limits.d/audio.conf
@audio   -  memlock    unlimited

Also verify PipeWire's actual locked memory:

cat /proc/$(pidof pipewire)/status | grep VmLck

If VmLck is 0, PipeWire is not locking memory despite having the rlimit. This can happen if the PipeWire build was compiled without mlock support.

Target state: ulimit -l returns unlimited, VmLck shows non-zero.

5. USB power management

USB autosuspend is the single most common cause of intermittent audio glitches. The USB subsystem puts idle devices into a low-power state. When PipeWire sends audio, the device has to wake up, which adds milliseconds of delay.

Check current autosuspend status for your audio interface:

# List USB devices and find your interface
lsusb

# Check autosuspend for all USB devices
for dev in /sys/bus/usb/devices/*/power/control; do
  echo "$dev: $(cat $dev)"
done

If any device shows auto, autosuspend is enabled. Disable it for your audio interface:

# Find the device path (example: bus 3, device 2 shows as 3-2)
echo on | sudo tee /sys/bus/usb/devices/3-2/power/control

To make this persistent with a udev rule:

# /etc/udev/rules.d/90-usb-audio-power.rules
# Disable autosuspend for all USB audio devices
ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="01", TEST=="power/control", ATTR{power/control}="on"

Reload udev:

sudo udevadm control --reload-rules
sudo udevadm trigger

Target state: Audio interface shows power/control = on, confirmed with cat.

6. USB polling interval

USB audio class devices have a fixed polling interval. Check what your interface reports:

cat /proc/asound/card*/stream0

Look for Momentary freq which shows the actual sample rate the USB subsystem is maintaining, and the endpoint descriptor which shows the polling interval.

For USB 2.0 high-speed devices, the microframe interval is 125 us. At quantum 64 / 48 kHz (1.33 ms period), you have about 10 microframes per audio cycle. That is tight. If your interface is USB 2.0 class-compliant and you want quantum 64, expect some USB-related jitter that no kernel tuning can eliminate.

Target state: Know your interface's polling interval. Set quantum expectations accordingly.

7. Timer resolution

Verify the kernel tick rate:

grep CONFIG_HZ /boot/config-$(uname -r)

You want CONFIG_HZ=1000. If you see CONFIG_HZ=250 (4 ms tick), wakeup granularity is too coarse for quantum 128 at 48 kHz (2.67 ms period).

Also verify high-resolution timers are available:

cat /proc/timer_list | head -20
# Look for "hres_active : 1"

If hres_active shows 0, high-resolution timers are not functioning. This is rare on modern hardware but can happen with certain virtualisation setups or broken ACPI tables.

Target state: CONFIG_HZ=1000, hres_active = 1.

8. BIOS/UEFI settings

Several BIOS settings affect audio latency. These vary by motherboard, but the common ones:

C-States. Deep CPU idle states (C6, C7, C10) save power but increase wakeup latency. Disable C-states deeper than C1 in BIOS, or limit them via kernel parameter:

# Add to kernel command line (GRUB: /etc/default/grub GRUB_CMDLINE_LINUX)
processor.max_cstate=1 intel_idle.max_cstate=1

Verify current C-state behavior:

cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name
cat /sys/devices/system/cpu/cpu0/cpuidle/state*/disable

Hyperthreading / SMT. Two logical cores sharing one physical core can cause scheduling jitter when the audio thread shares a core with a competing thread. Disabling SMT is the conservative choice for audio:

# Disable at runtime
echo off | sudo tee /sys/devices/system/cpu/smt/control

# Or via kernel parameter
nosmt

The performance tradeoff: disabling SMT halves your logical core count. If your audio workload is heavily multi-threaded (many plugins in a DAW), the lost parallelism can hurt more than the scheduling jitter. Test both configurations with your actual workload.

Turbo Boost / Precision Boost. Dynamic frequency boosting adds variability. For absolute consistency, disable it. For most audio work, leaving it enabled with the performance governor is fine because the governor keeps the clock high.

Target state: C-states limited to C1, SMT decision based on testing, turbo boost your call.

9. Network and Bluetooth interference

Network adapters and Bluetooth controllers share system interrupts and can generate thousands of IRQs per second.

WiFi power management adds latency spikes:

# Check current power save setting
iw dev wlan0 get power_save

# Disable it
sudo iw dev wlan0 set power_save off

Bluetooth is particularly problematic because Bluetooth audio profiles (A2DP, HFP) compete with the audio subsystem. If you are using a wired audio interface, disable Bluetooth entirely during sessions:

rfkill block bluetooth

Or at the adapter level:

bluetoothctl power off

Ethernet is generally fine, but high-throughput transfers (large file copies, NFS mounts) generate interrupt storms. If possible, pin network IRQs to a different CPU core than your audio workload:

# Find your network adapter's IRQ
cat /proc/interrupts | grep eth0
# Set affinity to CPU 0 (bitmask 1)
echo 1 | sudo tee /proc/irq/<IRQ_NUMBER>/smp_affinity

Target state: WiFi power save off, Bluetooth disabled during audio sessions, network IRQs separated from audio if possible.

10. PipeWire quantum verification

After all the system-level tuning, verify PipeWire is running at your target quantum:

pw-top

Check the QUANT column for the driver line. Confirm it matches what you set. If it does not, PipeWire may be adjusting dynamically based on client requests. Lock it down:

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

The quantum selection guide explains how to test and lock your quantum properly.

Target state: pw-top shows your target quantum, W/Q ratio below 0.75 under load, zero XRuns.

Quick-reference command table

Every verification command from this checklist in one table:

Check	Command	Good result
Kernel preemption	cat /sys/kernel/realtime	1
CPU governor	cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor	performance
RT scheduling	ps -eLo cls,rtprio,comm | grep pipewire	FF 88
Memory lock	ulimit -l	unlimited
USB autosuspend	cat /sys/bus/usb/devices/<dev>/power/control	on
Timer tick rate	grep CONFIG_HZ /boot/config-$(uname -r)	CONFIG_HZ=1000
High-res timers	cat /proc/timer_list | head -20	hres_active : 1
C-states	cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name	Only C1 enabled
WiFi power save	iw dev wlan0 get power_save	off
PipeWire quantum	pw-top (QUANT column)	Target value, W/Q < 0.75

Testing methodology

After working through the checklist, run a proper test:

1. Start your real audio workload (DAW project, DJ software, effects chain).
2. Open pw-top in a terminal and let it run.
3. Simultaneously run your normal desktop environment - browser, file manager, whatever you use.
4. Let it run for at least 30 minutes.
5. Record the peak W/Q ratio and total XRun count.
6. If XRuns appear, go back through the checklist and verify every item.

The order matters. A system failing at step 3 (no real-time scheduling) will not benefit from fixing step 8 (BIOS C-states). Work top to bottom, verify each step, then test.

For a comprehensive view of latency measurements across different configurations, compare your results to the data we maintain.

FAQ

Do I need to do all of this for casual audio use? No. If you are playing back music or doing video calls, default PipeWire at quantum 1024 works without any tuning. This checklist targets quantum 256 and below for production and live audio work.

Which item makes the biggest difference? Real-time scheduling (item 3). Without SCHED_FIFO priority, everything else is marginal. A system with rlimits configured and no other tuning will outperform a system with every other item tuned but PipeWire running at normal priority.

Should I apply all of these permanently? For a dedicated audio workstation, yes. For a dual-purpose machine, apply items 3, 4, and 5 permanently and toggle items 1, 2, 8, and 9 when doing audio work.

My system passes everything but still XRuns at quantum 64. What else? At quantum 64, you may be hitting hardware limits. USB class-compliant interfaces have polling jitter that no kernel tuning eliminates. Consider a PCIe or Thunderbolt interface, or accept quantum 128 as your floor.

Does this checklist apply to Wayland and X11 equally? Yes. The audio stack is independent of the display server. Compositors can generate scheduling noise (GPU interrupts, frame pacing), but the tuning items are the same.

I use a Thunderbolt audio interface. Do I still need the USB items? Skip items 5 and 6. Thunderbolt interfaces use PCIe under the hood and do not have USB polling concerns. The rest of the checklist still applies.

Conclusion

Low-latency audio on Linux is not one setting. It is ten settings, each of which can independently cause failures. Work through this checklist with a terminal open, verify each item, then test under real conditions. The latency-graph data shows what these configurations achieve in practice. If your numbers match, you are done. If they do not, one of these items is still wrong.

For the audio quality picture beyond latency—sample rates, resampling traps, USB interface quirks, MIDI timing, and a practical troubleshooting order—see the Linux Audio Quality guide.