A little guidance please on how asio guard works

Hi All

I have been using Cubase for a while (since 7) Can anyone give a none qualified user an idea of how asio guard works and how it reacts with regard to sample settings. I run an old 4690k processor oc’d at 4.1 ghz. The system has 16gb of ram. I am aware that the system is getting ready for a change as it certainly is starting to limit track count and vst’s however, it is and has been rock solid. I have been fortunate with 12 and all things considered the upgrade went well and apart from one crash caused by me has worked well. I am seeing the asio guard sitting permanently at 60% with a 20 track mix up and a couple of vsti’s and the usual comps eq’s from cubase. This has never been so high before. The reason I ask is that I am seeing others with very upto date pc’s having similar readings. If this is the case I don’t really see the point in a new machine to only give a similar return. I suspect it is my ignorance around this and I’m not sure if my question is relevant. I just feel a better understanding of asio guard would help my decision making re a new system.

Thanks in advance for any input.

Best Regards


The way ASIO works is by double buffering. While the sound card is playing a block of, say, 256 samples, the DAW is busy filling the other block of 256 samples. As long as the time to fill 256 samples is at least slightly less than the time to play 256 samples, you should have perfect playback, because the new block will be ready by the time the sound card needs it. And if it takes LONGER to fill 256 samples, than to play them, then nothing you do will work – you have too much processing, it won’t play in real time.

With 256 samples, and 48 kHz, you will need one buffer every 5.3 milliseconds. Let’s say that you have a pretty heavy mix, that takes 4 milliseconds to generate a single buffer – leaving 1.3 milliseconds of “free time” for each buffer. This will all work swimmingly, in theory.

Now, that’s the theory. On an actual computer, there are always random things that happen. Keyboard drivers might suddenly need to download new firmware, network cards may need to re-train their equalizers, graphics cards lose sync with the monitor, Chrome decides to phone home and ask about updates, and so on, and so forth. Any one of these events may be not that long – let’s say that the graphics driver decides to monopolize your computer for only 2 milliseconds.

Unfortunately, 2 milliseconds is longer time than the 1.3 milliseconds you have available in the example above, so that buffer won’t be produced in time, and you will hear a glitch.

ASIO guard works by adding a queue of buffers in front of the sound card. When the sound card is done with a buffer, it immediately takes another one out of the prepared queue, which only takes a fraction of a millisecond, so as long as the queue is not empty, there won’t be a glitch. If the queue is at least 3 buffers deep (about 16 ms) then this 2 ms delay caused by the graphics card (in this example) woudn’t be a problem, there would be enough “free space” to catch up again, and the sound card would never run behind on available buffers.

The drawback is that the queue adds latency. The buffers need to be produced ahead of time, enough to buffer against those drop-outs.

So, with ASIO guard on, you can generally reduce the size of your buffers a fair bit – the buffers only need to be big enough to compensate for hardware interrupt latency and high-priority thread scheduling to put in a buffer out of the waiting queue. The length of the ASIO guard queue then needs to be long enough to give enough slack based on how heavy your project is, compared to how frequently/long your computer will “do other things.” If you run at 4 ms time to generate a buffer, for a 5.3 ms buffer size, that gives you 1.3 ms of headroom per queued buffer. If the queue is 21.2 ms, that gives you 4 buffers of headroom, or about 4*1.3ms == 5.2 ms of additional glitch that can be assimilated.

But if the project runs at 98% load, then you only have 2% of 5.3 ms, or about 0.1 ms of slop per buffer. To absorb a 2 ms glitch, you’d need (2ms / 0.1ms) == 20 buffers of ASIO guard. So, the higher the interrupt latency in your system, the larger your ASIO buffer size needs to be. Meanwhile, the heavier your project is (in % of full CPU,) the longer the ASIO guard needs to be, with some kind of practical upper limit around 95% CPU load.


Thanks for that explanation.

Do you know exactly what happens when a track is record armed? Does asio guard turn off altogether?

Record enabled or monitored tracks are processed in realtime, the rest is pre-processed by ASIO-Guard. It doesn’t turn off but this track will simply bypass ASIO-Guard.

Unlike the driver buffer, ASIO-Guard does not add latency but permits to reduce it.
It does that by separating real-time tasks from those that need to be processed.
The two are then calculated in parallel by the CPU.

Since ASIO-Guard works on a buffer, it adds a delay between manipulating Effects, Instruments and MixConsole parameters and hearing the actual change.
It does NOT add input/output latency and only serves to relax the real-time processing, mainly when there is a lot of automation being read at the same time.

ASIO-Guard is only used during playback and permits to use a smaller buffer while reducing dropouts, and thus, having a lower latency.

ASIO-Guard is completely ignored when exporting or rendering the audio as this only relies on the main buffer.

Additional info here :

And here :

1 Like

This is what I meant by “latency.” Turn the knob on the VST effect, or press the MIDI key for the VST instrument, and it takes longer before you hear it. There are indeed many kinds of latencies involved!

For those of us where the DAW is reality, and the only live input we might have is direct-monitored in the interface/mixer anyway, ASIO guard doesn’t change our monitoring latency (because it’s already zero) but it does add in-DAW operation latency, including playing VST key instruments. So, whether it “reduces latency” or “increases latency” depends entirely on which latency you’re measuring!

You are completely wrong !
ASIO-Guard has never played any role in live playing VST Instruments, since it is bypassed as soon as you monitor the tracks.
ASIO-Guard on High setting adds 106 ms of latency.
Do you realize that if the ASIO-Guard latency was added to the input latency that would much likely be a major issue that absolutely everyone would complain about ?
The only latency we can measure and hear is the main buffer latency, the one you set on the driver.
The ASIO-Guard latency is only added during playback for pre-processing non-realtime calculations but isn’t added to the audible round-trip latency at all.
You should really inform yourself about this feature before divulging false information


I thought I was informed, but it seems I’ve missed this bit. I could have sworn I felt more latency that went away when turning off ASIO guard. Need to experiment some more.
It may very well be that I mistook controller latency for instrument latency.
Thanks for the update!

I really appreciate this information. Sorry for the late reply.