ASIO guard suddenly overloads when plugin is loaded, and won't calm back down

Cubase
,
1

Hello fellow Steinbergers,

Last night I was mixing a fairly large 48/24 project, hundreds of tracks and plugins in C14 pro (not Rosetta) on our M1 Ultra Mac Studio. Buffer at 2048, ASIO guard on full, multi on - Ran like a charm. I found a VST instrument track lurking in a folder of the project loaded with NI Massive, and it was armed to monitor. This was once used to send synths into guitar amps so had routing to hardware outputs FWIW.

So for whatever reason I turned off the monitor arm on the track, and immediately playback stopped. ASIO guard metre went straight to full. I set it back to monitor, but that didnt change anything. I assumed this had somehow woken up the VSTi and added it to the list of things the computer had to think about, so I disabled the channel, but no change. I then deleted the channel and checked the VSTi panel to be sure it was gone, still no change. Reset the ASIO driver, reset the IO config, changed buffer around, changed ASIO driver back and forth, toggled ASIO guard and multi processing settings, reset the project, restarted Cubase, rebooted the computer, power cycled the interfaces, reset Cubase preferences, deleted project cache, still no change - Massive allegedly doesnt exist in the project anymore but the ASIO guard metre is dimed and the project would not playback at all. Splendid!!

I loaded the backup from half an hour earlier, which worked perfectly fine, making sure not to disturb the Massive track that was still monitor armed. Only lost half an hour but surely a major pain in the arse if its crunch time and you’re going crazy, never stopping playback and therefore not autosaving, and the project is suddenly maimed.

I’ve actually been having this issue one way or another for as long as I can remember (started on SX3) but it was never so cut and dry - Usually i’d be loading plugins on a master bus and it would start to sputter, and after removing said plugin, it wouldnt improve. Just got used to running Audiogridder or Reaper with UA virtual channels for big subgroups or master busses to offload poor Cubase’s senile engine.

Purely talking out of my arse here but it seems as if Cubase factors in the processing for the VST or VSTi into ASIO guard, and will never let it go, even after removing the plugins. I tested it a while back and it seems the only way to “refresh” ASIO guard is to remove the majority of the plugins in one go, then add them again one by one, which then gets you back to where it was before the final straw that broke the camels back. I remember noticing on our 6800k pc from 2+ years ago that when this would happen, one CPU core would suddenly get pinned, while prior to loading the offending plugin, it was (relatively) more evenly spread. I have a basic understanding of how Cubase ~utlizes~ cores and has to funnel everything into one core to maintain sync between tracks feeding into groups, but that doesnt explain how eg. the 7th plugin on the master bus stooges the whole system when it was perfectly fine with 6 heavy ones on there before.

This is also not isolated to any particular plugin, OS, CPU architecure or Cubase version. I will admit things are running a lot smoother on C14 native compared to C12 Rosetta though!

Apologies, I’m not succinct. Anyone else experience this? Any thoughts or suggestions are more than appreciated!!

2

Yes I have seen this too, although not recently, but I was not looking for it and don’t have that complicated projects atm.
But I was involved in DAW Bench years ago and what we found out there when testing audio hardware and cpu’s for the audio performance, is that when loading plugins one by one until small dropouts occur then removing the last till good again and the saving, that the saved project will have many crackles and you need to remove quit a few plugins before ok again (something like a 100 multiband compressors before saving and 90 with a reloaded\saved project). Apparently this has never been fixed, or can not be fixed if it is under the control of the OS (scheduler).
Then there was no asio guard, so I don’t think that is the cause, although it might complicate things.
Massive X is a good candidate for this issue, since it uses AVX and depending on what CPU you have AVX can change the voltage and speed and max turbo of your CPU. So if there was no AVX used before you activated massive X, things could change dramatically. Did you try removing MX from the working project right after loading, before playback?
And also I noticed that the risk of this happening seems greater if the project is playing, so cubase might be tripping over its attempt for gapless playback.
We also noticed that RME drivers sufferd less from it then others on windows.
Cheers

3

Glad to hear I’m not cursed. Interesting that this happened before ASIO guard.

The track is using Native Instruments Massive (not Massive X), hadn’t heard of AVX but seems that it isnt a thing on Apple Silicon / ARM. Just tested removing the track before interacting with it in any other way, and before any playback, and that did seem to prevent it from bottoming out. Thanks for the suggestion.

If i understand correctly, being on MacOS, its always the Apple Core Audio driver, just applied in different ways to whichever interface, unlike Windows where there’s a noticeable change in performance between different proprietary drivers.

4

Ah massive not X. That one doesn’t need avx. Avx has been on CPUs for 8 years so I guess also in some form on new apple.
I am no apple expert at all, but on Mac audio devices also use a driver but most use the universal class compliant one. Some like most rme can also use a custom driver, but if that has any gain for low latency performance I am not sure, I guess yes. Core audio is a layer on top of that.
I am glad stopping playback helped somewhat, I sometimes need to do that too, although it’s unclear why and when exactly. In principal I never stop playback, until it goes wrong and then I am aware of it, just as you are now😀.
It is not perfect, but on the other hand pretty incredible what we can do, coming from budget analog studios in a now distant past like I do.
Cheers, nice to have this conversation!