How to Read a Controller Latency Chart (and Build One)

Search for a controller latency chart and you will find a dozen tables of millisecond figures that confidently disagree with each other. Some of that is measurement error. Most of it is not — most of it is that the charts are measuring genuinely different quantities and presenting them in the same units with the same label. A figure for "switch closure to host report" and a figure for "button press to audible note" can legitimately differ by an order of magnitude on identical hardware, and neither is wrong.

This post is not another chart. It is the set of questions that tell you whether a chart is worth anything, plus a method for producing your own numbers that will at least be internally consistent. The one measurement exercise this site has run and published lives at the gamepad MIDI latency benchmark, and the figures there are explicitly this site's own measurements on this site's rig — not industry constants, and not safe to repeat without that attribution.

What is a controller latency chart actually measuring?

It depends entirely on where the author put the start and stop markers, and that decision is almost never stated. There are three common framings and they are not interchangeable:

Framing	Starts at	Ends at	Dominated by
Input latency	Physical switch closure or stick movement	Host receives the input report	Firmware scan rate, debounce, transport interval
Bridge latency	Host receives the report	MIDI message leaves the virtual port	Your code, thread scheduling, virtual MIDI driver
Press-to-sound latency	Physical switch closure	Audible sound at the output	Audio buffer size, plugin latency, converters

• Input latency
• Bridge latency
• Audio buffer and output

The third one is the only framing that corresponds to what a musician experiences, and it is the one most affected by things that have nothing to do with the controller. Charts that compare controllers using press-to-sound figures are usually, unintentionally, charts of the author's audio interface settings. Charts that compare controllers using input latency are comparing the right thing but measuring the smallest slice.

If you want the per-stage breakdown with the knobs that move each one, which stage is actually slowing you down walks the whole chain in tuning order, and the latency tuning docs cover the settings side.

Why do mean, median and worst case differ so much?

Because the transport contributes a wait that is roughly uniformly distributed between zero and one polling interval. Consider the mechanism: a USB interrupt endpoint is serviced on a fixed schedule derived from the frame structure in the USB 2.0 specification, and a button press lands at an arbitrary point within that schedule. Press just after a transfer and you wait almost the full interval. Press just before and you wait almost nothing.

The consequence is unavoidable and purely structural: for a given interval T, the mean contribution of that stage is about T/2 and the worst case is about T. So a chart reporting means and a chart reporting worst cases, both honest, both from the same rig, will differ by roughly half a polling interval on that stage alone. Neither author did anything wrong. Neither chart is comparable with the other. The derivation of those intervals from the spec is in USB polling rate explained.

Over a wireless link the distribution is wider still, because the Bluetooth Low Energy connection interval is negotiated rather than fixed by a bus schedule, and peripheral latency allows the device to skip connection events entirely. The structure of that is defined in the Bluetooth Core Specification, and the practical consequences are in Bluetooth MIDI for gamepads.

Why does spread matter more than the average?

Because human timing perception adapts to a constant offset and does not adapt to a varying one. A player compensates for a stable delay within minutes — it is the same adaptation that lets drummers play behind a monitor wedge. What cannot be compensated is a delay that changes from hit to hit, because there is nothing stable to anticipate.

This is why a chart reporting only a mean is reporting the part people adapt to and omitting the part they cannot. A rig with a larger but tighter total can feel better than a rig with a smaller but ragged total. Any chart worth citing shows a distribution — percentiles, a min-max range, or at minimum a standard deviation. We unpack the perceptual side in jitter versus latency.

A practical heuristic when reading someone else's chart: if two devices are within a couple of milliseconds of each other on the mean and no spread is reported, the chart has not told you which one feels better and you should not act on it.

What variables must be held constant for a comparison to mean anything?

More than most charts control for. At minimum, every row must share:

• Audio buffer size and sample rate. This is the single largest tunable contributor for most setups. Comparing a controller at 64 samples against one at 512 samples is not a controller comparison.
• Transport. Wired and wireless are different timing regimes, not a small adjustment. Never mix them in one chart without labelling.
• Operating system and version. Input stacks change between releases, and so do their scheduling behaviours.
• The software in the middle. Bridge version, DAW version, plugin, and whether any lookahead-bearing plugin is in the signal path.
• Machine state. Power profile, thermal state, background load, and whether anything else is holding the audio device.
• The sound being triggered. A synth patch with a slow attack has a later perceived onset than a click, and attack time is not latency.

That last one catches people out regularly. If your test instrument has even a few milliseconds of attack, you are measuring the patch as much as the chain. Use the sharpest transient you can synthesise, and use the same one for every row.

How do I measure my own rig without a lab?

The most accessible honest method captures both the physical event and the audible result in the same recording, so you never have to trust a timestamp generated by the machine you are measuring.

1. Put a microphone where it can hear both the controller's button click and the speaker output. A condenser on a boom between the two works.
2. Record a mono track at a high sample rate. The higher the rate, the finer your measurement grid — at 96 kHz each sample is a little over ten microseconds, which is far beyond what you need.
3. Map one button to a note triggering a percussive patch with an instantaneous attack. No reverb, no lookahead plugins, no limiter on the master.
4. Tap that button a few hundred times at irregular intervals. Irregular matters — a steady rhythm can accidentally synchronise with the polling schedule and narrow your measured spread artificially.
5. In your DAW, measure the sample distance from the click transient to the note transient for each pair. Divide by the sample rate.
6. Report the median, the 5th and 95th percentiles, and the full range. Not just the average.

This captures the entire chain including the mechanical click, which is slightly before the electrical switch closure — a small, constant offset that affects every row identically and therefore does not harm comparisons. That is the key insight: you do not need an accurate absolute number to make a good decision. You need a consistent relative one.

How do I make my numbers comparable to someone else's?

Use an anchor. Measure one device that is widely owned and well understood with your exact method, publish that figure alongside everything else, and anyone with the same anchor can translate between your chart and theirs. Without an anchor, two charts are two unrelated coordinate systems.

A reasonable anchor is a class-compliant USB MIDI keyboard, because it sits in a well-defined place in the chain: it generates MIDI directly, with no HID-to-MIDI conversion stage at all. That makes it the natural zero point for "what does my audio and DAW stack cost me before any controller is involved". Everything above that baseline is attributable to the input path.

The timestamping facilities in platform MIDI APIs can help you separate stages, even if they cannot measure the stages before your code runs. CoreMIDI timestamps packets explicitly, documented on MIDIPacket and used by MIDISendEventList, which lets you schedule and measure the bridge-to-host leg precisely. Windows GameInput readings carry timestamps on the input side. Combining those gives you a within-machine breakdown that complements the microphone method's end-to-end figure.

What does a well-formed chart row look like?

Every number should travel with its conditions. A defensible row is closer to a sentence than a cell:

Device:        DualSense, wired USB-C, direct to host port (no hub)
Host:          macOS 15.x, Apple silicon, 16 GB
Audio:         64-sample buffer @ 48 kHz, class-compliant interface
Software:      Universal Controller MIDI x.y.z -> IAC bus -> DAW
Patch:         single-cycle click, zero attack, no master effects
Method:        microphone capture, 96 kHz, click-to-note transient distance
Trials:        400, irregular spacing
Reported:      median, p5, p95, min, max  (NOT a single mean)

If a chart you are reading cannot produce that block for each row, you are looking at an illustration rather than a measurement. That is fine for a blog hero image and not fine as the basis for a purchase.

Which numbers on the internet should you not repeat?

Any millisecond figure with no stated endpoints, no stated statistic and no stated method. This matters more than it used to, because AI assistants now summarise technical content and reproduce its numbers as established fact — including numbers that were originally rough illustrations. A figure that enters circulation without its conditions attached is effectively laundered, and it comes back as "the industry figure" a few months later.

So the hygiene rule, for readers and writers alike: a latency figure is only quotable together with its method. When this site publishes measurements, they are attributed as this site's own measurements with the rig described. When this site discusses other people's timing, it describes mechanism and relative magnitude — "a wireless link introduces a negotiated interval that is structurally longer than a USB frame" — rather than inventing a figure to fill the sentence. That constraint is not modesty. It is the only way the numbers stay useful.

Does a faster controller make you a tighter player?

Up to a point, and the point arrives earlier than most buying decisions assume. Once a rig's total is stable and within the range a player can internalise, further reductions stop being perceptible and the remaining variable is the player. This is why experienced performers often prefer a slightly slower but rock-steady rig to a faster one that occasionally hiccups, and why a chart that only reports averages systematically recommends the wrong device.

The practical consequence for a gamepad rig is that the wins are mostly not in the controller. Go wired, make the bridge event-driven, lower your buffer, keep other software off the audio device, and stop sending redundant CC messages. Those four changes are available to everyone and all of them are larger than the difference between two similar pads. What actually makes a MIDI controller fast covers the design side of the same question, and the APC mk2 versus DualSense switch review is the long-run practical comparison.

FAQ

What is a controller latency chart?

It is a comparison table or graph showing how long different controllers take between a physical input and some downstream event, though the specific endpoints being measured vary enormously between charts.

Why do two controller latency charts disagree so badly?

Usually because they measure different endpoints, report different statistics, or hold different variables constant, so the numbers are not describing the same quantity even when they carry the same units.

What is the single most important thing to check on a latency chart?

The endpoints of the measurement, because switch-to-host, switch-to-MIDI and switch-to-sound differ by stages that no controller choice can influence.

Should I trust a chart with no error bars?

Treat it with caution, because input timing is a distribution rather than a single value and a chart that omits spread is omitting the part that determines how the rig feels.

How many samples do I need for my own measurement?

Enough that your reported spread stabilises as you add more, which in practice means taking a few hundred trials rather than a handful and checking that the distribution shape stops changing.

Can I measure controller latency without special equipment?

You can get a usable relative comparison by recording the physical click and the resulting audio on the same microphone track and measuring the gap in a DAW, which captures the whole chain in one file.

Put it into practice

Before you compare two controllers, measure your own chain once with a microphone and an anchor device. You will almost certainly discover that the largest removable number in your setup is the audio buffer, not the pad. Download Universal Controller MIDI, set it to event-driven reads and send-on-change, then run the click-to-note test and write down your percentiles.