the vst performance is quite poor with my cubase artist 7.0.6 it seems. i have tried various things to see if i can improve it but nothing has helped. i dont understand why in task manager my cpu and ram usage is ultra low whilst the vst performance meter (average load) is high?
why could vst performance be so bad even when having plenty of cpu and ram available - is cubase actually utilising all the resources it should correctly, or is it something else (i’ve tried various settings, tweaks and drivers etc.)?
I posted about my newly built system the other day and whatever I changed (the changes I made are in that topic), also tempered some jagged peaks in the VST Performance window, although my peaks weren’t that high they were still higher than on my previous computer. I posted a few additional findings later on in that topic as well.
thanks for that thread link, i’ve done most of those suggestions and just tried the others but no difference. so i’m still left wondering why is the vst performance/average load high when cpu and ram usage is very low?
i could be wrong but it appears to me like cubase just isn’t utilising the resources properly/efficiently. if its not that then what could it be? is it possible that my music pc’s hardware is not capable of getting on well with cubase for some reason?
It’s complicated. It’s not just Cubase, but all DAWs. It’s not really your computer, as such. But, there are DAW-oriented computers that can be purchased or built to make this inherit problem less of a stumbling block. A “better” computer will help, but it will still show the disparity between free CPU and the ASIO VST Performance Meter. All things being equal, all DAWs suffer about equally from this (to keep it simple, that’s not quite true).
In every DAW having to process live, real-time audio, there will be a huge disparity between the “real” CPU utilization and the “real-time” CPU utilization. For example, in Reaper it’s called the “RT CPU Meter.”
It comes with the territory with the problem of “live” (real-time) low-latency audio and digital signal processing of it – it’s the raw physics of it.
The working philosophy of Cubase has always put live / real-time, first.
You notice it in things like low latency performance of soft-synths, responsive mutes and solos, near zero latency monitoring (with the right audio interface, system, settings and plugins).
The tradeoff, has been a system (including ASIO) that’s tuned for that and not mixing, where live input monitoring is less important.
Since version 7+ Steinberg has addressed this issue with ASIO Guard. If you don’t have it enabled, do so, it should help your situation. It works by pre-calculating and “scheduling” the audio packets in the audio buffer, making more use of your CPU.
It’s not quite as good as Reaper’s “scheduling model” in this regard, but this is Steinberg’s first version of ASIO Guard, so I suspect it will improve.
Of course, the other biggest thing you can do, aside from the computer’s specs, is have a professional-grade audio interface that goes up to a large buffer size. The larger the better (“2048” is the largest I’ve seen – Focusrite audio drivers go that high; some brands do, some don’t.)
It’s a constant battle for those of us that use lots of plugins and effects.
You can do what I did: Recreate your most demanding project in all the DAWs you own, in every detail, so that you’re really comparing apples to apples. Don’t use a single stock plugin or effect, have them all be 3rd party (so that it’s fair). Every buss, every plugin, every setting identical between them.
It’s an eye-opener on many levels.
I did this with Cubase, Studio One, Reaper and Sonar in 2012.
I left Cubase 6.x due to constant crashing issues, which lead to the quest. Btw, my crashing issues were eventually fixed, or were otherwise magically resolved for me in 7.x. So many other plugins came out with updates and fixes, it’s hard to place fault with Cubase, or any one thing.
Reaper won in raw “performance” by a freakishly large margin. If performance is measured as being able to use every last bit of the CPU when mixing at high latency. But, there were just too many nit-picky things for me to want to use it as a main DAW. And it did not do well in low-latency use-cases, for me.
For my project, performance-wise, Sonar came in 2nd place, then Cubase, then Studio One. But Sonar was plagued by a bizarre CPU spiking issue not found in the others. I finally got it confirmed as not a bug, but a limit in how it “schedules audio” that wasn’t ideal for my mixing style.
Studio One, though the worst performer, was the holy grail with its amazing “rearrange frozen audio” feature, but ran into a size limit with the project and would crash in a repeatable and unavoidable manner, so it literally could not be used (which was a shame, cuz I loved it).
I’m back with Cubase 7.x and loving it now that the stability is there.
One thing is for sure: if you upgrade your computer, “for Cubase,” you won’t regret it even if you move to another DAW.
i am about to install a 120gb ssd for my o.s. drive and have cubase/plugins on it, thats about it with upgrades in my music pc at this moment but i’m not expecting an ssd to help out on vst performance issues.
my current lightly loaded cubase artist 7.0.6 project will not use even a fifth of the cpu and memory available when the vst performance meter is at around 33%. i’ve tried all sorts of bios settings, drivers and different configs etc and it all makes no difference. i am beginning to think that perhaps my pc setup could be causing the issue but it also looks as though cubase could actually be the problem.
i checked out the reaper website yesterday and downloaded the demo, had a browse around it, read a bit of the manual. it seems ok, especially for $60, although there are some things that werent as user friendly as cubase but no way do i want to write off cubase just yet anyway.
Let’s do scientific tests to put real specificity to what usually is watered down to “a” is better than “b,” which is something that wasn’t so clear-cut when I tested.
The DAWs have evolved since when I tested in 2012, and I did not take scientific measurements, write them down, compare them side-by-side, etc.
So, help me out; specifically:
“Higher CPU drain” – what is meant by this? The CPU, a single core, the VST “real-time” Performance Meter? Higher than which DAW(s), specifically? On what system? What audio interface? At what latency? With which plugins?
“quite easy to confirm this” – agreed. it is possible and I’m interested in doing so. i’m not sure i’d call it “easy,” however.
No more benchmark-less talk from me. I’m going to provide actual metrics, or it didn’t happen.
Just to add another angle to this which has been raised in a number of other threads - you need to consider the possibility that the ASIO meter in Cubase is itself prone to error. In other words, don’t take the ASIO meter position as gospel. The important measurement is whether your recordings/playbacks are free from pops/clicks/distortion/stutter etc.
For example, on my desktop machine, with ASIO guard off, I almost always get the ASIO meter going into the red when I START playback. Doesn’t matter where in the project I start, I nearly always get a red line. NOT in disk access, but in the ASIO meter. Now, the point is, I NEVER get any audio artifacts associated with this kind of redlining. I have no idea what this may signify, but I work on the basis that in realty my machine is handling the I/O demands of Cubase better than the ASIO meter suggests.
I remember a long long time ago in the dark ages, someone removed the whole syncrosoft protection system from Cubase, and gained a huge amount of cpu cycles. Can´t remember any specifics, but the performance increase was pretty substantial. This is probably much more optimised now(or maybe not even an issue at all),but your question definetly has some relevance when looking back in the syncrosoft protection history.
I wasn’t questioning the validity of the results, mate. I was only drawing attention to the dates of the immediately available visual figures that most people probably will bother to look at. Things do change in a couple of years, a couple of versions of things, etc… It may not change the overall behaviors of the companies involved in the benchmark, but one still has to contend with the behavior and reaction of the masses.
Unlike your assumption, I have actually invested a lot more than ten minutes on that site. A very interesting and unbiased project as you so eloquently put it. I do think however, that DAW’s, such as the ones included in the project are more like the tool arsenal a construction engineer uses, rather than just “a hammer”.
Hmmm. Yikes. Was that before that big “forum cleanup” that happened a while ago?
There are lots of performance-related discussions on here. It’s hard to imagine Steinberg deliberately quashing such dialog.
Post it again, maybe?
Btw, I posted some performance-related thoughts yesterday on this thread, with a link to an interesting video. It really demonstrates pre-ASIO Guard and also simulates hyper-threading / multi-core issues by using Vienna Ensemble Pro 5 on the same machine.
It also hints at what ASIO Guard could be. Right now, ASIO Guard may not have as much muscle as with something like VEP on the same machine, at the same time. This is an area I’d like to benchmark. That is, ASIO Guard vs Cubase+VEP running on the same machine.
In theory, ASIO Guard should be able to lift an equivalent workload.
My fear is that ASIO Guard is the “answer” to “drop-outs,” but perhaps coming from a less competitive and ambitious design philosophy. Instead of attempting to squeeze every last bit of CPU (as VEP appears to), that it’s just to “improve” drop-outs in certain cases.
I realize it’s all a balancing act with potential tradeoffs, but a Cubase that truly competes with a Cubase+VEP (on same machine) combo, or, say, Reaper, is something I’m sure many of us would welcome.
I think focusing on ASIO Guard is the approach to take, as non-ASIO Gaurd is unlikely to see any performance improvement.
I also think that the benchmarks that should matter the most are high-buffer, high-latency ones. There are so many gottchas at so many layers of the signal path, at low latency (e.g., even ASIO vs Core Audio), that removing that from the conversation should help focus on the real problem areas.
I’m also thinking that VEP + Cubase might be the solution, for me (running on slave computers).
It’s funny, with VEP and slave machines, my biggest gripes with Cubase would all be solved – disappear – in one fell swoop:
the 6 freezable-insert limit
the long load times for projects with large numbers of plugins
the performance issues
the lack of batch freeze/unfreeze
the lack of Studio One’s “rearrange frozen tracks” feature
the lack of Bounce In Place … nope, that would still be hugely welcomed.
And maybe that’s a fair point, a professional solution needs more than a single part; it needs a full, robust system. Perhaps it’s unfair to expect Cubase to do it all … Naahh.