Hi there,
Audio Performance meters are peaking like crazy, even though no VSTi instruments have been loaded and no project has been created. Activating Steinberg Audio Power Scheme doesn’t make any difference… How come? Clicks and dropouts occur with just a single instance of Groove Agent 5… I have never experienced something like that with Cubase 11 …
(Cubase 12 Pro, Win 10/64-bit, Intel i-3, 32Gb RAM, buffer size 64 - 128)
Well, try deactivating ASIO guard as a first step. This was the resolution for me, for something similar, for a while, for at least a few months… until I tried again, and there was no problem.
There is a known bug where ASIO Guard gets disabled when creating a new empty project right after launching Cubase, which seems to be the case if we look at your performance meter.
After fixing it, save the project and the issue will no longer be there next time you open it.
That said, keep in mind that you are only using an Intel i3.
These entry-level processors aren’t even officially supported by Cubase, and I highly doubt you’ll be able to achieve very low latency with these. Please try increasing the buffer size and set the ASIO Guard Level to “normal” or “high”, and of course make sure the above glitch has been fixed.
If the peaking is still happening after making the changes, open Task Manager and see if there are any running programs that you don’t need, and close them. For example, 3rd party anti-viruses and “cleaner” or “optimizer” software that run in the background. By looking at your task bar there seem to be quite a bunch of programs you don’t necessarily need already. You have the Focusrite driver which is fine, but what are the other three for ? I bet if you click that arrow you have many more.
This ASIO Guard disable bug is a bit concerning. Is there any way to find out whether my output bus is impacted by that bug?
The ASIO Guard meter simply stays at zero, just like when it is disabled.
The “Average” meter in Audio Performance Meter?
I’m sorry for the lack of details.
The Performance Meter got updated in Cubase 12 and it now shows the ASIO Guard load.
This isn’t the case with C11 and earlier, the only way to see if the glitch is occurring in these versions is to watch how the Average and Real-Time meters behave. They are usually higher when ASIO Guard is disabled, but again you need to be used to how the meters behave on your system, with and without ASIO Guard, to be able to notice it.
Yeah I remember now that the performance meter got updated in C12, I’m still using 11.
I noticed that average and real time meters go a bit lower if I disable ASIO Guard, on a project with lots of VST instruments, and no Rec armed tracks.
Just thinking it through, as I seem to constantly need a reminder of what ASIO guard actually is…
ASIO guard would tend to make your CPU work harder because it allows you to have lower buffer sizes, so you can keep recording tracks easily even with lots of instruments going on. But when you’re done recording, and it comes time to mix, I guess you gain at least a little performance increase by disabling it.
Is this how you folks think of it?
I see no reason to disable it.
You haven’t yet.
ASIO guard is essentially a bigger buffer for all non realtime audio. Mixing is usually done with bigger buffers than realtime but if you get a performance increase in your system by running all tracks realtime, that’s fine by me.
I wonder if ASIO Guard is similar in functionality to the Dropout Protection feature in Studio One.
In Studio One, I get better CPU performance with Dropout Protection disabled. I just change the ASIO buffer to 64 or 128 if I’m goinh to record audio, but most of the time I keep it at 512 or 1024.
It’s the complete opposite.
The CPU won’t work harder, it will work at the same pace (assuming the workload is the same), but since you reduce the buffer size, it will no longer be able to process the audio blocks in time if you have too much things to process, and the audio will dropout.
When using ASIO Guard the CPU usage increases a bit because the audio engine has to handle two buffers separately for different tasks, but the audio processing performance itself is considerably better. The CPU usage and processing performance are two separate things.
Yes, that’s the exact same thing.
Ah, okay, the only stress then is the fact that there are two different buffers it’s handling.
I guess this extra help it’s giving is work done in advance and inserted into the buffer? I mean, since there are two buffers going on, does this mean that you get the same delay right after you press play that get if you set your buffer to something quite large, like 2048 - this being when the ASIO guard is filling up its buffer? …but that when you’re actually recording, you only experience the delay/ latency that’s associated with the smaller buffer size that you set for your project, let’s say 128 in my case?
What I never figured out was why I had to disable ASIO Guard entirely for a while. I don’t think it was related to the output bus problem you mentioned above. I thought maybe it was an Apple Silicon thing in Rosetta mode.
So does this mean I have a problem? This is with some CPU-heavy plugins (like Ozone/Gulfoss) enabled, but with the project not playing back, so they shouldn’t be doing anything:
When I disable those plugins, that ASIO Guard bar chills out somewhat…
@shagazulu The latency is added up, see the image in the first post. When you press Play you have the Output Latency + the ASIO Guard Latency, that is 4 ms + 17 ms = 21 ms of latency in total.
Audio blocks have 21 ms to be processed. Of course the latency introduced by plugins is added on top of that. When recording you still hear this same latency, simply because the project needs to play.
The Input Latency takes place when you record signals from the audio interface, but all of this is automatically compensated by Latency Compensation, you shouldn’t have to think about it. The recorded signal is automatically nudged by the Input Latency so that it is lined up with what you hear in real time from the other tracks that are playing.
@Timo00 Some plugins don’t use the CPU saving feature when there’s no signal.
As far as I know iZotope plugins indeed do not do that, so they will keep processing a null signal.
Ah, thanks @Louis_R.
Thanks for your help. Much appreciated.
Interesting. It’s a bit more confusing for me thinking in terms of output and input latency, but I see what you mean. If we just talk in terms of “delay”, ASIO Guard causes Cubase to start playing with more of delay (though not particularly noticeable) because it’s filling up that larger ASIO Guard buffer as well before it starts playing back the project. But then when the project is rolling, and you’re playing a MIDI part with your keyboard controller. say, you are not experiencing that kind of delay, but a much smaller, hopefully unnoticeable, delay from the time you hit the keyboard keys to hearing the sound playing back.
This is why I was thinking the computer was working harder, and in one sense it is, it’s just working harder BEFORE the project starts playing. Unless I’m still completely confused… 
I just wish I could understand why I had to disable the thing entirely for several months. Perhaps I will have more insight from now on. Thanks very much.
When the tracks are monitored, they bypass the ASIO Guard and are only processed with the Real-Time path (the base buffer that you set in your driver).
The Real-Time path and the ASIO Guard path are processed in parallel. During playback, the tracks that are already recorded (and not monitored) use the ASIO Guard path, and the monitored instruments that you play in real time use the Real-Time path.
This is why the delay added by ASIO Guard is only happening when you hit Play initially, and not occurring an additional time on monitored track.
You computer does not work more or less harder before the project starts playing, it always goes as fast as it can in order to render the audio in real time, just that it starts doing so in advance so that the CPU has more heardroom to process everything in time.
For example, with a given workload, if you decrease the buffer size from 1024 to 256, the performance meters will go up because the CPU has 4x less time to process each audio block.
The performance meter only represents what the CPU can achieve at any given moment, based on its frequency and current load. It does not represent how hard it is working.
If you open Task Manager you’ll see that the CPU usage remains the same wether you are using a buffer of 1024 or 256.
If you put 5 times more plugins on your tracks, then only now the CPU will work harder, as it has more stuff to process, and the CPU usage will increase. More processing to do means more time needed to process one audio block. If the buffer is too low and the processing takes longer than this, then the audio will dropout since the block won’t be entirely processed in time, before the next block starts. In this case, the Real-Time or ASIO Guard meter maxes out, whichever comes first.
I hope this helps!
Take a look at the following topic :
