Well, to simplify things for VST e-drummers and get to the point for them, here 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 10 ms 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
