Latency Benchmark: 2.4.0-test7-lowlatency-A0

Buffer size: 2048 samples  ·  Kernel configuration: Low Latency patch (A0 revision)

This page records the scheduling latency benchmark result for the 2.4.0-test7 with Low Latency patch revision A0 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: Low Latency patch (A0 revision)

This configuration applies the Low Latency patch in its A0 revision to the 2.4.0-test7 kernel. The Low Latency patch takes a more targeted approach than blanket preemption: it identifies the specific kernel code sections responsible for the worst-case latency outliers and modifies those sections to release locks and yield more frequently. The A0 revision designation indicates a specific iteration of the patch that was in circulation during the benchmark period. The Low Latency approach is more surgical than the PREEMPT approach, with different tradeoff characteristics.

The Low Latency patch family and the PREEMPT patch family represented two philosophically different approaches to the same problem during this period. The Low Latency approach prioritised targeted intervention with minimal overhead; the PREEMPT approach prioritised completeness of coverage at the cost of somewhat higher overhead in non-latency-critical code paths. Both produced real improvements over unpatched kernels. The relative merits were debated extensively on the Linux audio development lists, and benchmark data like this informed those discussions.

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

Low Latency patched kernels typically show good improvement in worst-case scheduling latency for audio workloads without the across-the-board preemption overhead of PREEMPT patches. The A0 revision was an early iteration, and subsequent revisions of the Low Latency patch improved both coverage and stability. The 2.4.0-test7 base is one step ahead of the test6 series, which introduces minor differences in the baseline kernel behaviour that affect latency measurement comparisons between this result and the test6 variants.

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.