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 use a rubber pad for testing module latency and 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 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, you can then subtract an average of approx. 1 ms 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)!



------



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”, e.g., from MacOS “Core Audio” (*), 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).

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).
An example of a hardware/software combination for reliable and authentic report: RME ASIO driver + Cockos Reaper DAW + Toontrack Superior Drummer 3 drum sampler


-----


(*) This is what ChatGPT tells you about the additional hidden latency from Apple computers :

my question:
Is, for example, an “RME Babyface Pro FS” with identical audio settings (sampling rate
(e.g. 44100 Hz) and buffer size (e.g. 32 samples)) under Core Audio overall
equally fast compared to the native RME Windows ASIO driver? I’ve read somewhere
that Core Audio has a small hidden safety buffer.

ChatGPT answer:
No – in practice, an RME interface under Windows with the native RME ASIO driver is slightly faster than under macOS/Core Audio, with identical buffer sizes. The difference is very small, but real, and it is caused by an internal safety buffer of Core Audio that does not exist in the same way under Windows ASIO.
You read this correctly somewhere – this additional buffer really exists.

Why is ASIO a few milliseconds faster than Core Audio?

Core Audio has a built-in safety buffer
macOS uses a software safety buffer in addition to the configured hardware buffer, typically:
1× additional buffer length or
a fraction of it depending on the device/host
This safety buffer exists for stability so that plug-ins have time to process and no
dropouts occur.

This buffer is not shown in the DAW, meaning you set e.g. 32 samples, but in reality
Core Audio processes 32 + additional internal samples.
Windows ASIO does not have to do this, because ASIO gives full audio control to the driver.
Therefore:
Under Windows, the actual roundtrip latency is smaller with the same buffer size.

RME ASIO drivers are extremely optimized
RME is known for delivering especially low latencies on Windows. Measurements (e.g.
from DAWbench) show:
Babyface Pro FS @ 44.1 kHz
32 samples ASIO: ~3.9 ms roundtrip
32 samples CoreAudio: typically ~4.7 – 5.2 ms roundtrip
The difference is about 0.7 – 1.3 ms, depending on the DAW.
macOS can be very stable, but not quite as “raw low-latency” as ASIO + a good
manufacturer driver.

Here is a table that compares only the output latency (D/A conversion + driver/system buffer) at
32 samples buffer size — exactly what matters if you play e-drums → VST and only listen to the audio output.
These values are typical measured output latencies of the RME Babyface Pro FS under:
Windows (ASIO)
macOS (Core Audio)
with identical buffer sizes.
Note: These values are extremely realistic (derived from DAWbench/RME tests).
They show only the output side, i.e. without the input path and without roundtrip overhead.

Audio Output Latency – RME Babyface Pro FS
(in milliseconds, based on real typical measurements)

44.1 kHz sampling rate:

Buffer________Windows ASIO_____macOS Core Audio_____Difference
32 Samples______~1.6 ms__________~2.1 – 2.2 ms_________~+0.6 ms

48 kHz sampling rate:

Buffer________Windows ASIO_____macOS Core Audio_____Difference
32 Samples______~1.5 ms__________~2.0 – 2.1 ms_________~+0.5 – 0.6 ms


✅ Essential insights:

1. Core Audio is always a bit slower
The additional internal safety buffer of Core Audio consistently produces +0.5 to +0.6 ms
more output latency.

2. ASIO is slightly more direct
At 48 kHz, 32 samples (typical e-drum setup):
ASIO output: ~1.5 ms
Core Audio output: ~2.1 ms
→ ~0.6 ms difference

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 devices) : audio settings (ASIO / Core Audio): not more than 64 samples buffer size at 44100 or 48000 Hz sampling rate