Latency Benchmark: 2.4.0-test6-preemp

Buffer size: 2048 samples  ·  Kernel configuration: PREEMPT patch only

This page records the scheduling latency benchmark result for the 2.4.0-test6 with preemption patch, standard scheduling priority kernel configuration, measured at a buffer size of 2048 samples. Below I cover what this kernel configuration represents, what the buffer size means in practice, and how to read the result. For the full comparison across all kernel configurations on this site, see the LAD latency resources page. For the broader latency measurement context, see the latency hub.

Kernel Configuration

Patch family: PREEMPT patch only

This configuration applies the voluntary preemption patch to the 2.4.0-test6 kernel without elevating the audio thread to real-time scheduling priority. The preemption patch inserts voluntary preemption points into kernel code paths that would otherwise hold the CPU for extended periods without yielding. The audio process runs at its default nice value and competes normally with other processes for CPU time. This isolates the effect of the preemption patch itself from the additional benefit of RT priority elevation.

Benchmarking the preemption patch without RT scheduling priority was a deliberate test condition. In practice, most audio production configurations would also set RT priority, but isolating the variables allowed clearer assessment of the patch contribution. The 2.4.0-test6 release was a pre-release candidate in the 2.4 stable series, and these benchmark results were produced during the period when the Linux audio community was actively evaluating the practical impact of the emerging preemption work.

Buffer Size Context

A buffer size of 2048 samples represents approximately 46.4 ms of audio at 44.1 kHz or 42.7 ms at 48 kHz. At this size, the audio thread has that full window to complete its processing cycle before the next buffer must be ready. For reference, a 2048-sample buffer is a relatively large buffer by the standards of live performance audio work — it provides comfortable headroom for heavily loaded systems and makes the measurement conditions less sensitive to brief scheduling interruptions, which is useful when the goal is characterising the baseline latency of the kernel configuration rather than testing the limits of the system. Smaller buffers (256, 128, 64 samples) are used in live performance contexts; 2048 is more representative of recording and mixing workloads or systems under evaluation where stability across a longer session is the primary concern.

The choice of 2048 samples for this benchmark is deliberate. It is large enough that the test is primarily characterising the kernel’s scheduling behaviour under load rather than probing the absolute minimum buffer the system can sustain. Benchmark runs at very small buffer sizes introduce their own measurement artefacts because the audio thread is running so frequently that its own scheduling overhead becomes a significant fraction of the available window. At 2048 samples, the measurement is more representative of the kernel’s general latency distribution across a realistic session workload.

Result Interpretation

Without RT scheduling priority, the audio thread is subject to preemption by other normal-priority tasks during its processing window. This configuration is generally less suitable for sustained low-latency operation than the rtsched variant, but it provides a useful reference point for understanding how much of the latency benefit in the rtsched configuration comes from the preemption patch versus the priority elevation. Under light system loads, the difference may be small; under competitive workloads, the absence of RT priority becomes significant.

When reading latency benchmark results, the metric that matters most for audio workloads is the tail of the distribution, not the mean or median. A kernel configuration that produces low average latency with occasional large outliers is less useful for audio production than one with slightly higher average latency but a well-bounded worst case. Look for the maximum observed scheduling delay and assess whether it fits within the audio thread window at your target buffer size. For a 2048-sample buffer at 48 kHz, the available window is approximately 42.7 ms. Any scheduling delay that consumes a significant fraction of that window represents a risk for sustained real-time operation.

The high dynamic range latency measurement approach used in some of the benchmarks on this site is specifically designed to capture and represent the tail distribution accurately. For details on that measurement methodology, see the HDRBench documentation.

Comparison and Further Reading

For the broader picture of low-latency Linux audio — scheduling fundamentals, measurement tools, and configuration guidance — start at the latency hub. For benchmark methodology and the high dynamic range measurement approach, see HDRBench. For general performance benchmarks beyond latency, see the benchmarks hub.