Audio Performance goes to the roof

I have Cubase Pro 14.0.32 running on Mac Studio M1 Ultra 128GB RAM / 4TB SSD.
When I have a project with a dozen VSTi, the Audio Performance Monitor shows that I have plenty of room (in terms of processing power). All is good. Except that this is true ONLY if I have the focus on a non-MIDI track (e.g. a folder or an audio track). But as soon as I select a MIDI track (or monitor it) the Peak indicator goes wild and I get a lot of dropouts (playing), or overflows in idle mode (not playing, see attached pictures).
Now of course if I increase my audio buffer size things get better, but then I have annoying real-time delays (which is normal).
My point is that I understand that some processing is needed to capture MIDI inputs, but the amount of power needed seems extravagant. Does everyone sees the same behavior ? Any way to improve this without a large audio buffer ?
Audio Perf.pdf (110.0 KB)

When you select an instrument track, per default it gets record enabled, which means that Cubase puts it in the realtime path of its audio engine (whereas if not record or monitor enabled, it is in the ASIOguard path which has extra safety buffers), which is of course directly affected by the buffer size setting of your audio interface.
The performance increase is normal and also depends on the VSTi in question, how ressource hungry it is, and on other plugins you may have in the signal path, e.g. on groups or the master, as they also get moved to the realtime path and consequently CPU usage increases, which is measured by the peak indicator in the performance window.
It is always a balance act between buffer size and plugins involved (unless there is something seriously wrong with your system)

2 Likes

Thank you for your comments. I know what you are saying.
My question is more about the amount of processing power involved. When I play all the VSTi instrument notes at the same time there is a tremendous amount of processing going on in real-time , with the “help” of the ASIO-guard and buffer size. And yet my system handles that very easily (eg. peaks will not exceed 10% of the available power). I am just “surprised” that merely handling midi information to be input to a VST takes in comparison much more processing resources. Furthermore, since this performance issue occurs even when there is no input sent, the thread that sends data to the final output buffer has virtually nothing to do other that sending 0’s…
But of course, if you believe, like everyone reading this (?), that this is normal behavior, then I am probably underestimating the tasks needed to achieve real-time MIDI inputs, and generation of 1 VSTi output in real-time.
Anyway, thanks again for taking the time to respond.

This is definitely normal.

As @fese mentioned, there is a lot that comes into play on this. The one thing I wanted to add, specifically with respect to your comment about playing “all the VSTi instrument notes at the same time” is that some VST instruments (e.g. a number within Arturia’s V Collection, including, but not limited to, Pigments) can use a lot of CPU resource when playing polyphonically. If you don’t need to be playing as many notes, you can reduced polyphony on the instrument to save some CPU power. In these cases, it will also depend on the specific patch being used (e.g. granular synthesis seems to be a particularly heavy contributor, not just in Arturia’s products), where some patches may be perfectly okay, but others might get problems early – it just depends what is going on in that patch.

My CPU is pretty old and underpowered, so I end up doing a lot of freezing of tracks, or sometimes even rendering a submix of some tracks to track other tracks against, if an instrument I’m trying to track is one of the heavy duty sort. :frowning:

1 Like

@rickpaul Thanks for the comment. In my example I didn’t use Pigments (which I use a lot in other projects). My hardware gear is pretty powerful. I just ran a test with 20 different Pigments tracks, removed ASIO-Guard, and still only used around 15% of the resources, according to the Cubase Audio Performance monitor (with 128-byte buffer and 5ms latency…)

I finally found the problem (I think…). I am using an excellent reverb called Sonsig RevA. Unfortunately it seems to be very power hungry. When I replaced it with Cubase Revelation, the problem disappeeared…

1 Like

I remember when this was a required, expected workflow “best practice.” I’d go as far as to say it was a “dependency,” really. I wonder how many performance-related posts would vanish if people built it into their “24/7 Live VSTs” workflows? Off topic, but potentially relevant.

@Thor.HOG yes I remember that too…That’s why I bought a good system, to avoid this hassle…
:slight_smile: