HDRBench: High Dynamic Range Latency Measurement

HDRBench is a latency benchmarking tool designed for Linux audio systems that takes a high dynamic range approach to capturing and representing interrupt scheduling latency. The core problem it addresses is one that conventional latency measurement tools handle poorly: the behavior that matters for real-time audio is not the average case but the tail -- the rare, large latency values that cause audible glitches and XRUNs. Standard histogram approaches compress resolution at the extremes to keep the typical values legible, which is precisely backwards for audio work. HDRBench uses a log-scale bucketing strategy that preserves meaningful resolution across the full range of observed values, from sub-millisecond timing to multi-millisecond outliers. Below I cover what HDRBench measures, the trace format it accepts, how to read the graph output it produces, and how to integrate it into a complete measurement workflow. For context on the broader measurement stack, see the benchmarks hub.

I have used HDRBench and related tools across many years of evaluating Linux audio systems, and the high dynamic range approach consistently reveals behavior that conventional timing measurements miss. A system that looks acceptable under a median-latency measurement might still carry a tail distribution that disqualifies it for live performance work. HDRBench makes that tail visible and quantifiable, which is the prerequisite for doing anything useful about it.

What HDRBench Measures

HDRBench measures scheduling latency: the delay between when a real-time task is due to run and when the kernel actually dispatches it. This is the metric that directly governs whether a Linux audio system can sustain a given buffer size without dropping audio. When JACK or PipeWire is running at a 64-sample buffer at 48 kHz, the audio thread must complete its processing cycle in roughly 1.3 milliseconds. If the kernel delays scheduling that thread -- because an interrupt handler is running, because a spinlock is held elsewhere, because DMA activity is consuming CPU cycles -- the buffer empties before the refill arrives and an XRUN occurs. HDRBench captures the distribution of those scheduling delays across an entire measurement run, building up a statistical picture of how the system behaves rather than reporting a single representative value.

The high dynamic range aspect is what distinguishes HDRBench from simpler latency probes. A conventional histogram with fixed-width buckets forces an uncomfortable tradeoff: either buckets are narrow enough to resolve sub-millisecond behavior (which makes the large-value end of the axis uselessly coarse) or they are wide enough to span the full observed range (which flattens the detail in the region where most samples fall). HDRBench uses proportional bucket sizing on a log scale, allocating resolution proportionally across the range. Values in the 10-20 microsecond range receive the same relative precision as values in the 10-20 millisecond range. The histogram is therefore informative across its full width rather than readable only in one region.

Trace Format: What Data HDRBench Works With

HDRBench works with latency trace data captured from the Linux kernel's timing measurement infrastructure. The standard source is the output of cyclictest, which is the community-standard tool for measuring timer interrupt latency on PREEMPT_RT and standard kernels. Cyclictest produces a stream of latency samples, each representing the measured wake-up delay for a single timer event in microseconds. HDRBench reads this numerical output, assigns each sample to the appropriate log-scale bucket, and accumulates the histogram counts. The process is straightforward: run cyclictest for a meaningful duration, redirect the output to a file, and pipe that file through HDRBench to generate the histogram data.

The measurement run duration matters. A five-minute run under light load will produce a distribution that looks better than the system actually is. For a measurement that reflects real production conditions, run cyclictest for at minimum 30 minutes with JACK active and a realistic signal processing graph loaded -- something close to what you would run in an actual session. Rare pathologies, such as the kind caused by ACPI power management transitions or USB device polling cycles, only appear reliably in longer measurements. The community resources at the LAD latency resources page document the specific measurement conditions that have been found to expose these pathologies, drawing on years of accumulated testing experience from the Linux Audio Developers community.

Reading the Graph Output

The primary output of HDRBench is a histogram image showing the distribution of measured latency values. The reference graph below illustrates what a typical HDRBench result looks like for a system in the 18-microsecond to 18-millisecond measurement range:

The horizontal axis represents latency in microseconds on a log scale. The vertical axis shows sample count per bucket. The shape of this distribution conveys more about the system's suitability for real-time audio work than any single summary statistic. A well-tuned system produces a histogram with a sharp, high peak in the low latency region and a clean, steep falloff toward higher values. The peak represents the system's typical behavior: nearly all wake-up events happen within a tight window. The falloff characterizes the tail. A steep, monotonically decreasing falloff indicates that high-latency events are rare and decreasing rapidly in frequency with increasing severity -- acceptable behavior for audio work. A flat or irregular falloff, or a secondary bump further along the axis, indicates a pathology: something is occasionally imposing an additional delay mechanism on top of the baseline scheduling behavior.

Secondary bumps are the most diagnostically useful feature of a HDRBench histogram. A bump at around 500 microseconds on an otherwise clean distribution is a strong signal of USB interrupt contention. A bump at 1-2 milliseconds often points to ACPI timer events or SMI (System Management Interrupt) activity. A broad shoulder between 100 and 300 microseconds on a non-RT kernel is the characteristic shape of standard kernel preemption latency. Comparing the histogram before and after a specific configuration change -- enabling PREEMPT_RT, adjusting IRQ affinity, disabling a power management feature -- shows directly whether the change moved the tail in the right direction. For temporal analysis that shows when in time the high-latency events occurred, the latency-graph tool provides a complementary view.

Download HDRBench

HDRBench is distributed as a source tarball. It builds against a standard C toolchain with no unusual dependencies. Extract the archive, review the Makefile for any paths that need to match your environment, and run make. The resulting binary accepts trace data on standard input and writes histogram data to standard output, which can be piped to gnuplot or a compatible graphing tool to produce the histogram image.

Comparing Configurations with HDRBench

The most productive use of HDRBench is comparative. A single measurement run tells you the shape of your system's latency distribution, but a paired set of runs -- one baseline and one with a specific change applied -- tells you whether that change improved, degraded, or had no meaningful effect on the tail behavior. Because the log-scale histogram preserves resolution at both ends, differences that are significant for audio work show up clearly even when the overall distributions look superficially similar. A change that moves the peak without touching the tail, or that reduces the tail without affecting the peak, is immediately visible in side-by-side histogram comparison.

Keep everything constant except the variable under test. Same hardware, same kernel version differing only in the specific patch or configuration option, same workload pattern during measurement. The audio load should reflect actual production use: JACK running at the buffer size you intend to use, with a signal graph complexity comparable to a real session. An idle system will produce measurements that overstate the system's performance under load. The numbers that matter are the ones your system produces while doing the work you actually need to do. For the conceptual foundation behind this approach to audio system evaluation, the latency hub covers why worst-case characterization matters more than average-case measurement for real-time audio work.

HDRBench in the Broader Measurement Stack

HDRBench fits into a complete Linux audio measurement workflow alongside other tools. The latency hub is the starting point for understanding the measurement problem: what scheduling latency is, why the tail distribution is the relevant metric, and how to run measurements that reflect real system behavior. The latency-graph tool provides temporal visualization that complements the statistical summary HDRBench generates. Where HDRBench answers "how often did each latency value occur over the entire run," latency-graph answers "when during the run did the high-latency events happen" -- which is often what you need to correlate latency spikes with specific system activities.

For the community knowledge accumulated around latency measurement -- the specific hardware findings, kernel configuration patterns, and known pathologies documented by the Linux Audio Developers mailing list -- the LAD latency resources page is the appropriate reference. And for the full set of benchmark and measurement resources available on this site, the benchmarks hub provides an organized overview. HDRBench addresses the histogram characterization problem more thoroughly than simpler tools, and understanding what it shows is the first step toward using it productively.