How we measure latency, why it matters, and why we stand by our numbers
For as long as digitalDrummer has been reviewing electronic drum modules, latency has been one of the most contested and least understood metrics in our field. We have been measuring it, publishing the results and defending the methodology for well over a decade. Recently, a handful of voices have been questioning our numbers with increasing volume, so it seems like a good time to explain exactly what we do, why we do it, and what the criticism actually amounts to.
How we measure latency
Our original method was developed from first principles, and it is about as direct as a measurement can get.
We split the output signal from an electronic snare pad into two feeds. The first went to the module being tested. The second went directly into an audio interface, bypassing the module entirely. The module output also fed into the same interface, giving us two simultaneous signals in Reaper: the raw pad hit, and the module’s processed response to that hit. The time difference between those two signals is the latency.
Before measuring, we stripped every parameter back to its minimum: scan time, mask time, crosstalk cancellation, retrigger correction. All effects were turned off. The thinking was straightforward: to give the clearest possible picture of how fast a module’s signal processing could actually be, with nothing in the way.
We used this method for years. The results were consistent, the approach was reproducible, and the numbers were widely quoted across the e-drum community, in forums and in conversations with manufacturers who took them seriously.
We later discovered an app that automated the same fundamental measurement, running continuous test hits and averaging the results, rather than relying on individual captures. Before switching, we retested a number of modules using both methods. The results were consistent enough to give us the confidence to adopt the app for ongoing testing, knowing that our historical data remained valid and comparable.
What sub-2 ms latency actually means
In recent years, the top-of-the-line modules have started returning measurements below 2 milliseconds in our testing. This has generated scepticism in some quarters, which is understandable, because 2 ms is fast.
Some context is useful here. The ddrum 4 SE, released in 2001, clocked 2.5 ms in testing at the time, a figure that stood as the benchmark for dedicated hardware modules for the best part of two decades. It took until the launch of the Roland TD-27 in January 2020, nearly 19 years later, for a module to better it in our measurements. That is not a story of inflated numbers. That is a story of how hard it is to move the needle in hardware signal processing, and how significant it was when the TD-27 finally did.
Sub-2 ms latency from a premium dedicated module is not only possible, it is exactly what you would expect from a purpose-built hardware processor. A modern e-drum module does two things in sequence: a trigger engine converts the pad impulse into MIDI, and a sound engine maps that MIDI to audio output. Both stages run on dedicated hardware with firmware optimised for exactly this task. Unlike a general-purpose computer, a drum module typically runs either bare-metal firmware or a real-time operating system (RTOS), engineered for deterministic, low-latency performance with minimal and predictable overhead. The entire signal chain is purpose-built around a single workload. These are not exotic figures pulled from questionable methodology. They are the logical outcome of dedicated engineering applied to a constrained problem — and 19 years of history supports that conclusion.
There is one further dimension worth considering, and it is one that VST advocates rarely acknowledge. Many e-drummers use a hybrid signal chain: a hardware module converts pad and cymbal impulses to MIDI, which then feeds a computer running a VST instrument through an audio interface. In this configuration, the module’s latency is not an alternative to computer latency, it is additive to it. Whatever delay the module introduces in converting a physical hit to a MIDI signal is baked in before the computer’s processing, VST translation and audio output add their own contributions on top. A module that takes 2 ms to generate a MIDI note, feeding a VST chain with a further 6 ms of processing and buffer latency, produces a combined response time of 8 ms or more. The module’s performance therefore matters whether you are running sounds from the module itself or routing MIDI into a computer. It is not a choice between two separate latency figures. It is the first number in a sum.
On the criticism
Measurement methodology should be open to challenge, and we have never claimed our method is the only valid one. If someone has a specific, reproducible objection to our approach, we want to hear it.
However, what we have less patience for is criticism that appears to serve an agenda rather than advance understanding.
One recurring critic’s concern seems less with the accuracy of our measurements than with what those measurements imply about alternative set-ups. If a dedicated hardware module achieves sub-2 ms latency and a computer-based VST set-up running through an audio interface achieves 5 ms or 8 ms or more, that is a meaningful difference, and one that matters to players who care about feel and response. Disputing the hardware figure does not change the VST figure. It just muddies the comparison.
VST-based set-ups have genuine and substantial advantages: sound library depth, flexibility, updateability and cost. There is a compelling case for them on those grounds. That case does not require our hardware measurements to be wrong. It requires an honest acknowledgement that latency is one factor in a multi-dimensional choice, and that different players will weight those dimensions differently.
We have no interest in telling anyone their set-up is inferior. We do have an interest in ensuring that the data we publish is accurate, that our methodology is transparent, and that readers can make informed decisions based on real measurements rather than contested ones.
An invitation
If you have a specific, testable objection to our methodology, we are genuinely interested. Tell us what you think we are measuring incorrectly, propose an alternative approach, and we will run the comparison. We have done this before and we will do it again. That is how rigorous reviewing is supposed to work.
digitalDrummer has always tried to bring discipline and consistency to a field dominated by subjective impressions. Our mesh head comparisons, for example, include audio level measurement, bounce and decay measurements taken using a custom-built rig, and even a visual transparency check. We are not writing for a science journal, but we are doing something more than posting a YouTube reaction video, and our readers deserve the difference.
When it comes to latency, we will not quietly retire a decade of careful, consistent, independently validated work because it produces numbers that are inconvenient for someone else’s business model.
The latency table stands.