Latency Benchmark: 2.4.0-test6-preemp-rtsched

Buffer size: 2048 samples  ·  Kernel configuration: PREEMPT + real-time scheduler priority

This page records the scheduling latency benchmark result for the 2.4.0-test6 with preemption patch and RT 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 + real-time scheduler priority

This configuration combines the voluntary preemption patch for the 2.4.0-test6 kernel with explicit real-time scheduling priority assignment for the audio thread. The preemption patch reduces kernel hold times by inserting voluntary preemption points into long-running kernel code paths. The RT scheduling priority elevation moves the audio thread above competing tasks in the scheduler queue. The combination targets the two distinct sources of audio thread latency: long kernel hold times and competing task interference.

The 2.4.0-test6 series was a development milestone during a period when low-latency Linux audio was being actively explored at the kernel level. The preemption work during this era produced several competing patch families, each with different approaches to the tradeoff between latency and throughput. The rtsched suffix indicates that this benchmark run additionally elevated the audio process scheduling priority, which is a configuration step separate from the kernel patch itself.

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

Systems under this configuration generally show improved tail latency relative to stock 2.4 kernels, particularly in mixed workloads where the audio thread competes with non-real-time tasks. The voluntary preemption approach introduces overhead compared to a fully preemptible kernel, but avoids the deeper integration work required by full preemption patches. Whether the combination of voluntary preemption and RT scheduling priority is sufficient for a given buffer size depends heavily on the hardware and workload.

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.