Linux Audio Latency

Latency is the central technical problem of real-time audio work on Linux. It touches the kernel scheduler, the audio driver stack, the sound server configuration, and the hardware itself. Getting latency right means understanding each of these layers and how they interact, not just adjusting a buffer size and hoping for the best. This page is the top-level reference on this site for all things latency: what it means in the context of audio production, how to measure it accurately, what the standard kernel and configuration approaches do, and where to find the detailed resources that cover each aspect in depth. For the detailed practical reference covering PREEMPT_RT, scheduler tuning, IRQ handling, and measurement interpretation, see the LAD latency resources page.

What Scheduling Latency Means for Audio

Scheduling latency in the Linux kernel is the delay between the moment a task becomes runnable and the moment the kernel dispatches it to a CPU. For a real-time audio thread, this delay is the primary determinant of how small a buffer you can sustain. At 48 kHz with a 64-sample buffer, the audio thread has approximately 1.3 milliseconds to complete its work before the next buffer must be ready. Any scheduling delay that pushes the thread past that deadline produces an XRUN -- an underrun or overrun that manifests as a glitch, click, or dropout in the audio output.

The metric that matters is not average scheduling latency but worst-case scheduling latency across the duration of a session. A system that delivers 1 millisecond average latency with occasional 10 millisecond spikes is less usable for live audio work than a system that delivers 3 millisecond average latency with a hard ceiling at 4 milliseconds. The spikes are what your audience hears. This distinction -- between the typical case and the tail of the distribution -- is the core of everything else on this page. Measurement tools, tuning approaches, and kernel configurations are all in service of understanding and controlling the tail, not just the average.

The Kernel Configuration Foundation

The standard Linux kernel is not designed for hard real-time guarantees. Certain code paths in the kernel run with preemption disabled, meaning that no matter how high-priority your audio thread is, it cannot be scheduled while those paths are executing. The PREEMPT_RT patch set addresses this by making nearly all kernel code preemptible, including interrupt handlers, which run as threaded interrupts with schedulable priority. The practical effect on audio latency is significant: worst-case latency values on a PREEMPT_RT kernel are typically an order of magnitude lower than on a comparable stock kernel configuration.

Beyond the kernel preemption model, IRQ affinity -- which CPU cores service which hardware interrupts -- has a measurable effect on audio latency. If the same CPU core that is running your audio thread is also servicing a busy network interface or storage controller, the contention produces latency spikes. Pinning the audio thread to a dedicated core and steering other interrupts away from that core is one of the most reliable tuning steps available after the kernel configuration choice. CPU isolation, set via the isolcpus kernel boot parameter, takes this further by removing the isolated cores from the general scheduler pool entirely.

Measurement: How to Know What Your System Is Actually Doing

The standard tool for measuring scheduling latency on Linux is cyclictest, which runs a high-priority real-time thread that sleeps for a fixed interval and measures how late the wakeup is. Running cyclictest for an extended period with the system under realistic audio load produces a sample set that characterizes the latency distribution. The key is running it under realistic conditions: with JACK or PipeWire active, with a representative signal processing graph loaded, and for long enough that infrequent pathologies have a chance to appear.

Raw cyclictest output is a stream of numbers that is difficult to interpret directly. The measurement tools on this site address that problem. The HDRBench tool processes cyclictest output into a high dynamic range histogram that preserves resolution across the full range of measured values, making the tail of the distribution as legible as the peak. The latency-graph tool provides temporal visualization, plotting latency values against time to reveal periodic patterns and correlate spikes with specific system events. Together these tools give you both the statistical shape and the temporal structure of your system's latency behavior -- both are needed to diagnose problems effectively.

Benchmark Resources on This Site

The benchmarks hub organizes all of the measurement and analysis resources on this site. It covers the HDR benchmark approach, the latency graph tools, the community-sourced latency reference material, and the relationship between latency measurement and audio signal quality assessment. If you are new to Linux audio latency measurement and want to understand how the pieces fit together, the benchmarks hub is the starting point.

For the detailed community knowledge base on latency -- specific hardware findings, known kernel configuration pitfalls, and measurement methodology accumulated through years of LAD mailing list discussion -- the LAD latency resources page is the primary reference. That page covers the practical tuning knowledge that complements the measurement tools: what to do with the data once you have it.

Latency and Audio Quality Together

Latency is not the only dimension of audio system performance. Signal quality -- the accuracy, dynamic range, and noise floor of the audio path -- is a separate concern that interacts with but is distinct from scheduling latency. A system can have excellent worst-case latency but poor signal quality due to driver-level processing, hardware limitations, or the interaction of sample rate conversion stages in the signal chain. The audio quality section covers that dimension: how to assess and improve the signal quality of a Linux audio system independently of its timing behavior.

For serious audio production work, both dimensions matter. The latency tools tell you whether your system can sustain real-time processing without glitches. The quality tools tell you whether the audio the system produces at that latency is worth keeping. Starting with latency is usually the right order, because a system that cannot sustain reliable real-time operation is not worth optimizing for quality until the stability problem is solved. But both are necessary for a system that is genuinely ready for professional work.