…and what exactly does it do? Does it prevent the CPU gauge from clipping?
yes, that is correct.
It basically gives you 2 buffers. one (large) for non realtime tracks, and one (the one you set in your sound card setup) for real time tracks.
If ASIO guard is set to high, it gives you a 4096 samples buffer @ 44.1 for playback tracks, while input monitor/record enabled tracks have the buffer you set in your sound card settings.
1 Like
Thanks for the info, claesbjo. Does it create any kind of latency in the chain, anywhere?
No - it shouldn’t. It just delays the playback tracks. Any track armed for record has the latency set in your sound card.
John
hmmm… I disagree with the person that says it doesn’t since adding latency is exactly what ASIO Guard does. It’s easy to see. Just go to your devices panel where you turn ASIO Guard on/off. It will show you the latency of whatever you have your card set to as well as the latency ASIO Guard is using.
No latency that matters. Only on tracks you’re not currently monitoring live (monitor enabled and/or record enabled).
It will actually lower latency where it matters most.
I haven’t tested or even noticed, but it probably does increase latency for things not being actively monitored, but where an automation or mix console parameter is adjusted. These kind of mixing use-cases don’t really need super-low “performance” latency. If the “mixing” ever becomes a performance thing, then you’d just make sure the track has monitor enabled, and then it would get the lower latency treatment.
It’s only the “Input / Output” latency that matters (pick the highest number of the two – the Output latency).
ASIO Guard latency is fully “invisible” to the performer, and essentially, even invisible to the mix engineer for mixing duties.
That extra 20 ms (or whatever) when pushing a fader, before one hears the change doesn’t matter.
Again, I disagree … you will absolutely notice using editors and making automation and loop adjustments, especially as you get to a loaded project and start increasing the base latency.
Then just press the monitor button on those tracks and go into “performance mode” so to speak, if it matters, right? What am I missing here?
Automation is on a track and a track can be monitored to get that lowest latency number. Ditto for editors (they’re within a track signal path).
If you are pushing the project you won’t be able to do that on all the tracks you want to automate. It also doesn’t work (under certain editing scenarios) when you have multiple tracks open in the Editors.
As I’ve said many times, ASIO Guard 2 is nice … but don’t get confused about what it is doing. It is adding buffers/latency with all of the gotchas that come with it. Yes, it is a distinct advantage to no longer have to go back and forth with the buffer size so often. However, when the project gets loaded you still have the same old problems. I’ve also found that C8 performance is actually marginally worse overall than C6 and 7. Although the new ASIO Guard is significantly better at catching ASIO Spikes.
Monitor can be enabled for more than one track. I’m pretty sure if you set monitor on for all those tracks in question they’d get the low latency in those editing scenarios (and CPU requirements would go up, probably).
I haven’t tested yet, but suspect it works that way.
Did you have monitor enabled for all those tracks?
Yeah, go for that multi-track monitor when you are at 95% ASIO load.
Right, but you’d have that issue even more, all things being equal, without ASIO Guard. Because all tracks, even ones you didn’t care about monitoring would be tapping into the limited, low-latency fountain.
So again, all things being equal, someone should be getting lower latency with ASIO Guard.
This is certainly the case for me. I have a monster project that would barely play in 7.5 with 2048 buffers (maxed) and it clipped all the time.
In v8 with ASIO Guard enabled the same project plays, no hiccups, at 512! Insane.
Also, I’ve noticed the ASIO meter can get completely pegged (fully lit up to the top) and a project still won’t hiccup as much. I think some of that is a recalibration of the meters to be more conservative.
That was my point. I always jacked up the buffers myself manually when I got to the mix stage. And, my total performance on maxed out projects is actually less now, not more. So to me ASIO Guard 2 didn’t improve performance. It improved convenience. Which I am for. But, the “improved performance” claim is smoke and mirrors. And to say that ASIO Guard doesn’t affect latency in the chain is both misleading and wrong. Affecting buffers/latency is actually what it does do.
You’re just inventing tradeoffs where there are none.
There’s too many “changing the goals posts / straw man / red herring” logical fallacies going on in your side of this discussion to keep what should be a simple, informative reply, answered correctly. But I’m up for the critical thinking challenge and debate. 
I’m saying “all things being equal” a person will experience a lower latency on the same project (all things being equal).
Unless your system is experiencing an issue that is preventing ASIO Guard from working properly (totally possible), “all things being equal” ASIO Guard will always give the performer a lower latency to play keys, twist dials and tap pads (or drag notes in an editor).
It’s the raw physics of it.
To say otherwise, is misleading.
I would call it more “slight of hand.” And it’s a good thing.
My Input / Output latency without ASIO Guard off, on my Focusrite Saffire Pro at 2048 buffer size is 48 ms.
With ASIO Guard on, it’s 48 ms.
Same number.
ASIO Guard does not “affect” my Input / Output latency.
To say it does, is misleading and wrong.
This is a “red herring” logical fallacy. It introduces an irrelevant topic that sounds like it’s relevant in order to divert attention from what is relevant. Yes, it does “affect buffers and latency” … to be lower where the performer is playing live and higher where they’re not.
Bottomline: The same project that I could not use my MIDI pads on to effectively record or mess around with, while the project was playing in v7.5, I now can in v8.
ASIO Guard v2 is letting me perform again on a project I had given up on to just being a note editor affair.
It must be very system and project dependent, what ASIO Guard 2 give you. I have projects where it has huge impact on the ASIO metering. But who knows how that metering is programmed, I would have to fill the project to its limits to measure a difference. What I do notice is I can using ASIO Guard 2, I can have email, word, Dropbox, backup, etc running without Cubase skipping a beat.
I am not certain, but here is my understanding and experience with what it does…
ASIO Guard looks ahead and pre-calculates audio where it can. The amount that it looks ahead is determined by the ASIO Guard setting. That is why when a fader or knob is moved, there is a delay in seeing its effect, because there will be no effect until the audio gets past the part that was already calculated when the knob or fader was moved.
I think this is independent of the real-time physical input/output latency.
Example… The other day, I was doing some recording on a project with some recorded guitar and some VST instruments. The ASIO Guard was on the highest setting. During recording, I put the audio card latency to the lowest setting. The project still ran very smoothly because the instrument tracks and other, non-monitored, tracks are being pre-calculated (by the amount in the ASIO Guard setting). I also had no noticeable latency on the guitar as I was recording (just a few .ms as the audio card latency is reporting.
Bottom line is that I don’t think the ASIO Guard latency is “in addition” to the audio card buffer latency. It is a different animal. It is how much Cubase looks ahead for pre-calculation. This is based on my understanding from the manual and videos here on the website and my own usage experience but I may have it wrong…
1 Like
I’ll ignore the rest because it again avoids the issue which is “what is ASIO Guard”. But, the above statement is exactly what it should do. That’s what ASIO Guard does. I’m assuming that with ASIO Guard ON, you have your buffers set much/much lower than 2048. Then it f’n increases your buffers/latency to reduce the ASIO Load except on the channels where you monitor. You can manually do the manipulation of the buffers and get the same results (or in some cases less results). If it can’t reasonably increase the buffers it throws an error saying so.
The point is, that a project running at a very high latency will have automation issues. Even the manual tells you that. The example from the manual does not fully explain the automation issues high latency causes, but it does let you know it will happen.
High ASIO-Guard levels lead to an increased ASIO-Guard latency. When you adjust a volume fader, for example, you will hear the parameter changes with a slight delay.
ASIO Guard simply shifts the audio to another path with increased buffers/latency to reduce the real time load on your sound card. That’s what it does, that’s what it is. Adding latency is EXACTLY what it does to achieve the ‘mythical’ performance improvement.
However, as I’ve said several times, the updated version does improve on dealing ASIO spike issues. And it is nice not having to manually switch back and forth between latency settings for tracking and mixing.
Anyhow, that’s enough on this for me. If you guys want to believe in the data reduction fairy, go for it.
I believe that JMCecil’s comments are an accurate technical expansion on my simplified (as was intended) response to the OP.
John
Exept that Asio guard does exactly what it should do.
With it enabled I can record a gutar through an amp sim with 48 samples latency to a foll project.
With Asioguard off I can not. What id doues internal is absolutely irrelevant here.
Jeez…
1 Like
I thought I was through … but just for the record 
Yes, that works great and it is nice and is a benefit and I like it and hurray. It is awesome that we can live record into large projects …
But the OP asked what it does …
Someone said it doesn’t add latency
I said actually adding latency is exactly what it DOES do.
Someone else decided to chime in with more mythology.
folkfreak … if you ever get your project to a point where your ASIO load is 90% + with ASIO Guard on, you may no longer be able to click the monitor button without getting dropouts. Then you are right back to using direct monitoring … which is how we get around it prior to C8. Also, if you then decide to MIX that project with Asio Guard on, and you for example use a control surface … you may find you can’t use that mixing device efficiently. AND … for many of us (yes many, I’ve had this conversation even with Steinberg), the actual total load you can put on C8 is less than C7 which was less than what you could put on C6. This isn’t subjective. Hmm … I have a test project but it is too big to attach to the thread …
Here’s you test project. Generate a sine wave for about 4 bars. Add 8 Borg basic compressors to the track. make real copies of the sine wave file and duplicate the track xxxx times. Begin looped playback. Now, turn on compressors until Cubase pukes. C6.5 > C7.5 > C8 for ME and several people I know.
It is very dependent on the audio card and drivers. Audio drivers can be very efficient at one sample rate/buffer setting and not so good at another.