zzyzx.sh \ email: zzyzx(at)zzyzx{dot}sh

Keyboard latency testing


Keyboard latency can be measured with nothing but a microphone.

Keyboard latency has been bothering me for a while. There’s a lot of room for one keyboard’s latency to differ from another’s, but it isn’t something that’s regularly tested. If you’re a latency-sensitive buyer it’s less than clear how your options stack up.

This is just what I could cobble together in an afternoon with no special tools, not an ideal setup, but it gets the job done. In short, I hammer a key, the keypress plays a sound (a hi-hat) via LMMS, a mic records both the sound of the physical keypress and the sound LMMS plays, and then the recording precisely shows the gap between keypress and result. The extra latency between LMMS receiving the keypress and the hi-hat sound reaching the mic is long but fairly consistent, so while this isn’t any good for figuring out the absolute latency of a keyboard, it’s plenty to figure out the differences between keyboards.

It’s an opportune time to work on this because I’m reviewing the Roccat Vulcan TKL Pro, which has low latency as one of its main selling points. I’ll post the rest of that probably Friday. In the meantime, here are the results of this testing:

Relative keyboard latencies
average / 90th percentile latency over reference; lower is better
Roccat Vulcan TKL Pro (Titan Switch Optical linear): +0/+3 ms (reference)

G.Skill KM360 (Cherry MX Red): +16/+20 ms

WASD V2 87-key (worn Cherry MX Brown): +23/+28 ms

Kensington K72357USA (membrane): +25/+29 ms

29 ms
0 ms

If you’re just here for the results, that’s all for now; the rest is all about how I got those numbers.

If this topic interests you, you might also want to check out Dan Luu’s excellent post on the subject and/or RTINGS’ data (the most extensive I know of).

Test setup

This is what the mic picks up for one keypress:

Recording of a keypress and results

The easily-visible sounds are when my fingernail first contacts the keycap and when sound starts coming through the headphones, and that’s the delay we’re measuring. The mic is as close as feasible to the keyboard, and one side of the open-back headphones rests directly on the mic, so the recording stays fairly clean.

Also visible but more subtle (it gets better with proper zoom and more screen space) is where the key bottoms out. This is important because I’m pressing keys manually and the delay between first touching a key and reaching its actuation point matters. To keep things consistent, I hammer the keys fairly hard so travel time will be low regardless. The recordings verify that the time between first touching a key and bottoming out a key with 4mm travel is 3 to 5 milliseconds, so with 2mm actuation points (half the variance) this shouldn’t be able to add more than a millisecond of error.

Actuation point, spring strength, and in principle how freely the keys move and how much the keycaps and plunger weigh all affect latency more in reality than in this testing. In the interest of low variance, the keystrokes are unrealistically hard, to the point that debounce struggled occasionally on all tested keyboards except the Roccat (which uses optical switches).

It seems to take 35+ milliseconds with this setup after LMMS recieves the input for the sound to make it all the way out to the headphones, even with LMMS’ buffering turned all the way down. It’s not clear why this takes as long as it does or what could be done to improve it, but for this purpose it isn’t important (if anything it helps keep the results easy to look at by separating the sounds better); what matters is the consistency (so we can compare one keyboard to another), not the absolute latency. The results do have a bit more jitter than expected, but it’s quick and easy to take a lot of samples with this setup, so it’s entirely manageable.

LMMS test setup

I test with 5 presses each of z, x, c, v, b, n, m, s, d, g, h, j, l, and semicolon. Not all keys are easy options because of how LMMS is set up, but the variety of keys should catch some potential issues, and 70 total presses gets past the bulk of the jitter.

I kept background load to a minimum and made sure the different keyboards were all connected to the same USB port. Too many things can (and probably will) change about the setup, and it won’t be safe to compare numbers across different rounds of testing; I’ll have to retest at least one keyboard I tested today (preferably the optical one since it’s least likely to degrade) to line up today’s numbers with future rounds of testing.

After aggregating all the keypresses and testing a few more keyboards, we get something that looks like this:

Keyboard latency distributions