VST e-drum latency chain :

1. the drum pad (drum pads / esepcially larger mesh pads can have a marginal latency according to the spot where it is hit and the position of the sensor. The internal latency of drum pads up to 14" is very low, tending towards zero in most cases.)
➜
2. the e-drum module / trigger device (manufacturer and model): especially the analog-digital conversion (as a piezo signal is an analog signal) and the "Scan Time" (adjustable on many devices). (Manufacturer and model: There are significant differences—so this is an essential point!)
➜
3. the MIDI-connection – USB MIDI or DIN 5 pole ( -> USB MIDI has speed advantages! - so use it!)
➜
4. the computer system with all hardware and software components (like USB controllers, mainboard/system drivers, CPU, RAM) + also: OS & BIOS real time audio optimization + also: Windows vs. Mac = ASIO vs. Core Audio
➜
5. Software (and software settings): drum sampler / drum instrument + DAW/3rd-party DSP tools (all that can be 0 if latency-free tools/settings are used)
➜
6. Audio interface (digital-analog conversion) + audio settings (buffer size + sampling rate)



Information about module latencies from the Internet :

The only list of module latency for various e-drum modules available on the internet to date* unfortunately makes a crucial error in reasoning**, at least with regard to the “scan time” factor:

Some of the listed modules (such as those from Efnote and certain Chinese modules, for example) do not have any settings for “scan time” - so it does not make sense to say that the scan time has been reduced to 0. And how much 0 is "0" anyway?! Some modules have a positive value in their minimum scan time setting (e.g., ChatGPT tells me that the Alesis Strata Prime module starts at 0.4 ms). How much 0 is “0” in technical detail?? (That's for sure: it cannot be 0!)
So, there's some inconsistency here, especially when you specify exact decimal places in the millisecond range...

I advised the author of that list to always include the manufacturer's “default scan time” in the test result for a module model (since it can be assumed that a manufacturer has optimized their “default scan time” for pad type "X") – anything else makes little sense.
Speaking of pad types: I would always write down the pad type and the default scan time specified for that particular pad in the test results.


...And there is another point about that list of module latency results: an app was used for the tests ➜ So how trustworthy is that app and how does that particular app exactly work? (can we get any detailed technical information about the principle of function of that app?) - I would only trust my method: How to measure software drumming latency 👉 ....or... How to measure software drumming latency with a mic 👉


* It would be nice if that list (that is available at digitalDrummer.com) could be updated, so that e-drummers can find out about their actual and consistent* module sound latency.
VST e-drummers can then use such a list to draw conclusions about the MIDI latency of a module/trigger device (the time from hit to MIDI data ready to be transmitted at the device's midi output): for high-quality devices/e-drum modules, you can then subtract an average of approx. 1 ms D/A converter latency.

* Again: very important: Leave the module/trigger device set to its default scan time for the test! + with information about the pad used for the test (rubber pad vs. mesh pad)!


( ** July 2026: ∙the author of this dubious module latency list still fails to recognize his error in reasoning. Since his list is used as a reference by AI systems like ChatGPT, this unfortunately spreads misinformation about e-drum latency. ( read more )



------



In essence, for VST e-drummers, there are a few things to consider :

Make sure your total latency does not exceed 10 milliseconds! Anything less than 10 ms is fine. The lower the latency without the following points (and therefore the greater the headroom towards 10ms that can be used for these points, which should always be taken into account), the better!

Point 1: Sloppily cut drum samples do occur, so one should not categorically assume that there is no silence (or near silence—or, for our purposes, wasted pre-time) before relevant audio material. I have seen hihat pedal “Chick” samples that wasted 3 ms, for example.

Point 2: “Hidden buffers”, which are not specified in the latency report of an audio app or DAW.

Point 3: Possible latency caused by the virtual drum instruments themselves:
∙ through resampling (i.e., when the native sampling rate of the drum samples is not used as the audio setting),
∙ through latency-inducing DSP audio effects,
∙ or even due to a general fixed latency of a VSTi / AUi (such as the recent latency deterioration of Toontrack drum samplers (SD3 and EZ3) with a general latency of 16 samples since v3.4.1 for SD3 and v3.1.1 for EZ3 in the plug-in versions [...Update: SD3 was fixed with v3.4.3 and can be set to behave like before 3.4.1]).

Point 4: Use of DSP audio effects that introduce slight latency in the DAW, independent of the drum sampler/drum instrument. Example: I want to make the sound cooler and louder by using a good-sounding clipper in oversampling mode (SubMission Audio's ”Flatline2” adds approx. 1.5 ms at 16x oversampling (at 44.1 or 48 kHz) -> I have to factor this additional latency into my headroom for this extra sound).


And be critical of latency reports from audio apps, as these can be very generic mathematically and completely ignore DA converter latency (then the audio app is the culprit) or there can be audio interfaces that do not report reliably (then the audio interface is the culprit).

Example for an optimal setup and audio settings :

Roland module (like the "V51") (default Scan Time (like 2ms)) or an eDRUMin (Scan Time not more than 2.3ms)
➜ USB MIDI ➜ computer
➜ connected is a fast audio interface (like RME or Motu devices) : audio settings (ASIO / Core Audio): 16 or 32 (not more than 64) samples buffer size at 44100 or 48000 Hz sampling rate

my newly conducted latency measurements for LOWEST VST e-drum latency (May 2026) 👉


Trigger device : Roland V71 (connected via USB midi (!)) at default Scan Time ( = all pads have max 2.0 ms Scan Time. For Kick pads that exceed 2ms, the Scan Time has been set to 2.0 ms.
The test pad has been set to a Scan Time of 2.0 ms.)

Good news for eDRUMin users: the eDi (at the Scan Time of 2.3ms) is no more than ~0.7 ms slower than the Roland V71 ( -> Tested with an eDRUMin12 device connected to a MacMini)

In order to get the lowest latency performance : Always connect your trigger devices to the computer via USB midi ❗️

Reaper 7 + Superior Drummer 3 -> ( Here you can download the project for your own latency tests ( password: BecauseDrumGeek ). Use such a Y-cable ➜ LINK )
(SD3 settings: note 36 triggers a Oneshot snare sample that was set to ~ -9ms sample Offset in order to not have to deal with settling time / rise time. All incoming velocities are translated to maximum velocity ; SD3 version > v3.4.3 : checked "Lower latency" setting in the Performance tab)
( Tweaking REAPER for lowest Software Drumming latency 👉 Link )




Measurements :


∙ RME AIO Pro (tested on a Windows machine):

32 samples ASIO buffer size at 44100 Hz :
5 ms



∙ RME Babyface Pro FS (tested on a Mac computer):

Without "Short Safety Offset" / "Safety Offset: Normal" :

32 samples buffer size at 44100 Hz :
5.5 ms

16 samples buffer size at 44100 Hz :
4.6 - 5.0 ms


With "Short Safety Offset" / "Safety Offset: Short" :

32 samples buffer size at 44100 Hz :
5.0 - 5.3 ms

16 samples buffer size at 44100 Hz :
4.3 - 4.5 ms


RME Babyface Pro FS (tested on a Windows machine):

48 samples ASIO buffer size at 44100 Hz :
6 ms
(Note: For 44.1 kHz, the lowest RME ASIO driver setting is 48 samples. This applies to all RME USB devices on Windows)



∙ Motu M2 (tested on a Mac computer):

32 samples buffer size at 44100 Hz :
5.5 ms

16 samples buffer size at 44100 Hz :
5 ms


Motu M2 (tested on Windows machine):

With the option checked: "use lowest latency safety offsets"

32 samples ASIO buffer size at 44100 Hz :
6 ms

16 samples ASIO buffer size at 44100 Hz :
5 ms
(Note: For 44.1 kHz, the lowest Motu ASIO driver setting is 16 samples (which is awesome!))



∙ RME Babyface (old Babyface 1) (tested on a Mac computer):

Without "Short Safety Offset" / "Safety Offset: Normal" :

32 samples buffer size at 44100 Hz :
6 ms

16 samples buffer size at 44100 Hz :
5 - 5.5 ms


With "Short Safety Offset" / "Safety Offset: Short" :

16 samples buffer size at 44100 Hz :
5 ms



∙ RME Fireface UC (tested on Windows machine):

48 samples ASIO buffer size at 44100 Hz :
6 ms
(Note: For 44.1 kHz, the lowest RME ASIO driver setting is 48 samples. This applies to all RME USB devices on Windows)



The (midi) jitter was super low on all test runs / all configurations : < 0.5ms






...RME Babyface Pro FS connected to my MacMini: Top value of 4.3 ms for one of the measured strikes :




ENJOY ❗️😊


...To be continued...



PS: related thread: VST e-drumming stress test : achieving the lowest possible latencies (such as 5 ms total latency) on the most affordable hardware 👉

Why you probably shouldn't use a Roland module as an audio interface, why a Focusrite Scarlett is likely not the best choice, and—above all—why using a MacBook without an audio interface is absolutely out of the question :

Quite simply, because it’s slower and, in most cases, less efficient (than a MOTU M-Series audio interface like the "M2").


“Lowest possible latency” really does mean “lowest possible”! And of course, 0.5 ms and above are already significant in this context; after all, with VST e-drumming, we’re dealing with a latency chain (the latency of the audio interface is just one part of it), and all parts of this chain add up.
There are many audio interface brands and models (including some that come close to the top in terms of value and performance and latency), but for my thread—which focuses on “lowest possible latency” and best performance on the tightest possible budget—there’s a clear winner, and that’s the MOTU M2.



1. Roland module as an audio interface :

Okay, it’s fair to say that the Roland ASIO drivers have improved significantly compared to the past. However, when it comes to performance under heavy real-time CPU load ("RT CPU"), they’re no match for truly good ASIO drivers like those from Motu and, of course, RME (a test project on a Windows i7 computer, which ran with Motu M2 ASIO at 32 samples buffer size (at 44.1 kHz*) ( = 6 ms total latency with Roland V71 via USB MIDI as the trigger device**) in Reaper and which was playable without glitches and which, during fast and intense drum performances, pushes the RT CPU meter (Reaper "Performance Meter") to just over 90%, is only playable without glitches with Roland ASIO at a buffer size of 128 samples, and that already puts us at 11–12 ms total latency.

(* This sampling rate will be referenced from now on.)
(** This trigger device setup will be referenced here from now on unless otherwise specified.)

If you're playing “normal” or relatively lightweight drum projects in terms of CPU usage on Windows machines, you can, of course, use a Roland module like the V71 (-51, -31) as an audio interface. And on Mac, you can use it as an audio interface, povided you're okay with the fact that it's about 1 ms slower than the Motu M2 at a buffer size of 32 samples (in the best-case scenario, I measured a latency disadvantage of not much more than 0.5 ms with a buffer size of 16 samples).
On Windows, the smallest Roland ASIO setting is 32 samples, which results in a latency disadvantage of 1.5 milliseconds compared to the lowest latency setting on the Motu M2.

So, for projects and drum samplers that place a heavy load on the RT CPU, a Roland module is not suitable as an audio interface on Windows computers.




2. Focusrite Scarlett :

Naturally, the widely cited, affordable Focusrite Scarlett had to be included in the SoftwareDrumming latency test, and I have now tested a "2i2 4th Gen" (as of June 2026, using the latest ASIO drivers).

Windows:
When testing on the Windows i7 machine with my Reaper project, it’s noticeable that the Focusrite Scarlett ASIO driver gives some strange and inconsistent results: the latency values of the measured pad strikes fluctuate significantly more than the extremely stable, very consistent values of the MOTU ASIO driver. With a buffer size of 16 samples (which, fortunately, is adjustable on Windows just like with the MOTU) and also 32 samples, this is least noticeable, which is why it’s safe to say that for projects and drum samplers that generate a relatively light to moderate RT CPU load, the small, inexpensive “Focusrite Solo 4th Gen” is perfectly suitable, and in the best-case scenario (-> 16 samples buffer), you can play with a total latency of 5.0–5.8 ms.
Starting at a buffer size of 48 samples, the fluctuations become unpleasant, and we’re already seeing fluctuations in the range of 1.2 ms. At 64 samples, the fluctuation is close to 1.5 ms, and at 96 samples, it fluctuates in the range of a rather extreme 2.2 ms. This doesn’t happen at all with the MOTU ASIO! (The test configurations on the computer were, of course, exactly the same: same trigger device, all devices connected to the same USB ports, same Reaper project.)

There’s also a very noticeable jump in latency when switching from the 64-sample setting to the 96-sample setting : starting at a 96-sample buffer, we’re running at an uncomfortably slow 12.0–14.2 ms (which makes the 96-sample setting of the Scarlett an absolute no-go for VST e-drumming. — ...Btw, that's where RME audio interfaces (like the Babyface Pro FS) are super strong: 8ms total SoftwareDrumming latency at 96 samples buffer size).

Another thing that stood out—and I have to say, it was really, really strange (I have never seen that on an audio interface before)—was that a high-load SD3 project (btw, I tested two different high-load projects: both of which trigger this “Scarlett ASIO bug”) constantly crackles at a buffer size of 64 samples (“Safe Mode” OFF)—meaning the sound is essentially distorted—and, funnily enough, no longer crackles constantly at a buffer size of 48 samples (meaning the sound is no longer constantly distorted with the smaller(!) buffer size).


Generally speaking (particularly due to latency fluctuations under ASIO), the “Focusrite Scarlett 4th Gen” is half a millisecond to just under one millisecond slower than a MOTU M-Series device.


So, based on what I’ve seen so far, the Focusrite ASIO drivers aren't on par with the MOTU ASIO drivers in terms of quality (and certainly not with RME ASIO).


Here is the test report: ***



Mac:
The "Focusrite Scarlett 4th Gen" exhibits a similar latency disadvantage compared to the MOTU M2 when used on a Mac (tested on a MacBook Air M1):
it is half a millisecond to a full millisecond slower than the MOTU. The latency fluctuations seen with the Focusrite ASIO driver on Windows do not occur.




3. MacBook operation without an audio interface (selecting "External Headphones" in the audio app/DAW) :

To anyone who keeps claiming you don't need an external audio interface for VST e-drumming if you're using a MacBook: the latency performance of the built-in "External Headphones" device is abysmal—making it a no-go for anyone aiming for a total latency well below 10ms: At an extremely low buffer size of 16 samples, we incur a poor total latency of 8.5–9.0 ms. At 32 samples, it is already 9.5-10 ms, and at 64 samples, it is around 11 ms.

This is also evident from an audio app's/DAW's latency report: while the MOTU M2 reports an impressively low "0.9"ms output latency at a buffer size of 16 samples at 44.1 kHz, the onboard "External Headphones" device reports an alarmingly high "5.1"ms.

In any case, one conclusion that can be drawn from all this is that if, for example, your only trigger device is an eDRUMin (and not a modern(!) Roland module), it’s a no-go to play e-drums on a MacBook without a fast, external audio interface.




***
Focusrite 2i2 4thGen (+MotuM2 for a comparison of fluctuations) -- Windows10 ∙i7 machine ∙ test report :
Focusrite Control 2 / Driver : (June 2026) v1.1014.0.0

44.1kHz Reaper project :
"SoftwareDrumming - Latency Measurement -- Focusrite 2i2 4thGen (+MotuM2) -- Windows i7 machine"
Download ∙( password : BecauseDrumGeek )

(Always 6 pad strikes per take)

"Safe Mode" OFF :

Buffer-Setting: 16 Samples :
5.2 ms
5.7 ms
5.2 ms
5.3 ms
5.0 ms
5.8 ms

32 Samples :
5.8 ms
6.6 ms
6.3 ms
6.0 ms
6.2 ms
6.5 ms

48 Samples :
7.5 ms
7.0 ms
7.0 ms
7.5 ms
8.2 ms
8.0 ms

64 Samples :
9.1 ms
8.0 ms
8.7 ms
7.7 ms
9.0 ms
8.3 ms
(By the way, it’s TOTALLY WEIRD! The 64-sample setting crackles constantly in a heavy load SD3 project, whereas the 48-sample and 96-sample settings (i.e., both the lower and higher buffer settings) don't crackle at all! WTF!)

96 Samples :
12.0 ms
13.4 ms
13.4 ms
13.0 ms
14.2 ms
13.9 ms



"Safe Mode" ON :

16 Samples ∙Safe Mode ON :
6.7 ms
6.9 ms
6.8 ms
6.4 ms
6.6 ms
6.9 ms

32 Samples ∙Safe Mode ON :
8.0 ms
7.4 ms
7.1 ms
6.9 ms
7.2 ms
7.3 ms

64 Samples ∙Safe Mode ON :
10.0 ms
9.7 ms
9.8 ms
8.5 ms
9.0 ms
9.5 ms




. . . ∙a∙n∙d ∙ F∙O∙R ∙ C∙O∙M∙P∙A∙R∙I∙S∙O∙N∙ :

MOTU M2 ∙at 64 samples buffer size ("use lowest latency safety offsets" ACTIVE)

(Same trigger device ( -> V71 in "Generic Mode"), same Reaper project, same computer, same USB ports)

Take 1 + Take 2 :
All 12 pad strikes are stable at 8.3–8.5 ms.

A comparison of the sound quality of the various audio devices tested (headphone output and line output) has been deliberately omitted here, as it is not relevant to the topic of latency.
For anyone who is still interested in this aspect, it should be noted that none of the devices’ headphone outputs can match the sound quality achieved when using a high-quality headphone amplifier (connected to the line outputs of the respective devices). My recommendation for enjoying drum sounds when playing e-drums (and with the superb sounds from good drum samplers and DAW projects, we VST e-drummers are, after all, able to get the crème de la crème out of e-drum sound: which, in my opinion, deserves to reach your ears through the best sound transducers) is definitely to use a device like this (I use Lake People headphone amps). The line-out sound of the best value-for-money winner, the MOTU M2, connected via balanced cables to a Lake People G111, is definitely top-notch: the definitive ticket to e-drum heaven 😊.