At my wits end with vst performance...please help guys

Have you tried starting Cubase in safe start mode? See this link in the Steinberg knowledgebase if you are not familiar: https://www.steinberg.net/en/support/knowledgebase_new/show_details/kb_show/safe-start-mode-resetting-the-cubase-preferences/kb_back/2020.html?tx_p77sbknowledgebase_pi1[filter_2]=17

Have you created a support ticket under mySteinberg? I suggest that as a support agent here in the US will call you. Its part of what you pay for when you buy the software and a great resource. Messageboards can be helpful, some times less.

I will open a ticket tonight.

Also, is the auto arm thing normal? When you guys select a track, does it auto arm for recording?

For your viewing pleasure:

I have no idea man…just none. Without reloading my entire system (which will take a month), I am not even sure where to go to trouble shoot it. Then, if I reload it, whose to say they problem is not right back?

First, it doesn’t matter that it’s not playing. The audio engine is working even when it’s stopped. And, there’s nothing wrong with your system.

Here’s what’s going on…

The higher CPU load with Record Enabled is normal and how ASIO Guard 2.0 works. Just leave Record Enabled off on all the channels (except for the one you’re currently recording on).

Since ASIO Guard is a dual buffer system (a large buffer and small one for low-latency stuff) that smaller buffer (for Recording at low latency) is the weakest link in the ASIO-Performance-Chain, as far as the meter is concerned.

You’re seeing your CPU try to crunch 4 VSTi’s into that smaller “Record Enabled” buffer.

To make matters worse, my guess is that the smaller buffer used for low-latency recording has to “fit” all on one CPU core (you have 6 cores).

Another way of saying this: my guess is that only the larger buffer (non-Record Enabled tracks with ASIO Guard on) gets to enjoy splitting up the audio workload across cores (a.k.a. multicore “audio scheduling” is the technical name for it). This is how Sonar’s audio engine works.

So it’s many things working against you:

  1. The smaller “Record Enabled” buffer (with 4 channels trying to squeeze into it).

  2. The strong likelihood (based on the evidence) that Cubase has to do all that work on a single core, whereas when you uncheck Record Enable for a given channel, it can not only shift to the larger buffer, but shift across other cores.

  3. The fact that Intel CPUs with higher core counts (6, 8, etc.) tend to see lower performance per-core, but greater overall performance due to the extra cores. So, if my suspicion that #2 is correct (and I think it is), then you’re trying to squeeze those 4 channels on a single, lower performing core (compared to cheaper 4 core CPUs), at that. So the premium 6 core CPU may be hurting you a bit for this use-case. A cheaper, 4 core of the same generation and same clock speed may have just enough more performance per-core, to pull it off (or not).

Overclocking would probably solve the issue then, because you just have to get a little more juice out of one core.

But, if you can, just disable those Rec buttons (except one). Problem solved.

(There’s a pref setting to turn off the auto-Record-Enable that will make this easier.)

But it craps out with just one instance of Kontakt and a medium (400 meg) instrument. This just can’t be right. How can anyone work like that? If that is truly the case, I will have to leave Cubase. Man…I am really depressed at this point.

A rapid read of this thread shows me that this hasn’t been mentioned (sorry if it has!) but are your CPU settings in “Control Panel > Power Settings” set to “High Performance”? If not, this could definitely be your problem.

High Performance sets your CPU cores to max and avoids core parking and SpeedStep. It turns out that if you can get quite granular in the power settings of Windows 7 (probably W8 as well). If you go to “Change plan settings” and “Changed Advanced Power Settings”, you can see some but not all of the parameters that can be adjusted (check this page). A better utility for this is ParkControl, but even that doesn’t cover all the options which you can only see directly in the registry or using some advanced sys info programs.

IMO, Steinberg should set up some ideal power settings for W7 and 8 and make them available to their users. I think a lot of reported issues regarding performance have to do with this. On my system, the difference between having power settings on “Balanced” and “High Performance” is dramatic, stuttering and glitching vs smooth sailing.

Hi,
I also get very high real-time-peaks when pushing the “monitor”- or “record”-button on midi-tracks and also when opening any midi-editor-window (as long as this window is the active window). But only on midi-tracks related to Kontakt 5.

Turning Kontakt off: no peaks.

Does not really help - but try it.

Grüße
grello

Turning off the “ARM” button before trying to load the first instrument does not help, although it does seem that the load gets farther along before failing. – got up to 0.92 Gb on a 1.25 Gb instrument. Again, plenty of memory, 64 bit system. Standalone can keep loading instruments until I get bored … haven’t yet found a limit.

Still waiting for the moderators to approve first posts. Meanwhile, another idea: both the original poster and I have had Sonar X3 installed … is it possible some driver or vst thing (?) from sonar is conflicting with cubase? A competitive spike-the-other-program?

Does anyone think it would help to just buy the fastest thing on the market and reload? I am considering the new Has well processor (Intel 5960), 32 gigs of ddr4 ram and an Asus Rampage motherboard. This will all set me back around $2200 but I am desperate… I really don’t want to leave Cubase.

honestly i had a less than stellar win 8 reinstall recently. before giving up completly i would suggest to try a reinstall. I have found win 8 to be more finicky to setup than 7… dont know why. i am really looking forward to win x. a win 7 instal is a good choice, also.

make sure you cpu when no programs open is under five percent… all the regular tuning stuff.


after some two weeks of tweaking i finally got 8 to perform better but i still dont think its as good and stable as 7 is.

gl…

oh and i also suggest you dont need the absolute top end cpu, just the i7 affordable should be fine.

there are also so.many other factors at play.

I can’t make it out in your video but is the Kontakt CPU meter also pegged?

I’m curious to know if Kontakt is actually doing work but I couldn’t make out it’s cpu reading in the video.

In terms of a reload, rather than removing everything I would suggest creating a small drive partition on your primary hard disk and clean installing Windows, Cubase, ASIO drivers and Kontakt on that. You can shrink your existing partition to make room for the new partition. You can then dual boot into the “clean” version and repeat the experiment without disrupting your existing setup.

MAKE SURE YOU BACKUP YOUR PC FIRST!!

If the small clean install works it would eliminate any hardware issues and tell you if you have a software conflict and if a reload is worthwhile.

Cheers

Rob

I do believe the problem is as I’ve described (in my most recent post, above).

If so, it’s possible that an i7-5960X could make matters worse. More cores could mean slightly less performance and base-clock frequency per core.

I think the Record Enabled buffer has to be processed on one core (it can’t scale to the other cores).

A response from Steinberg to confirm this would be greatly appreciated.

You might submit a support request and reference my thoughts on the matter (if I’m wrong, then I’m wrong).

The only way to know for sure, is to test.

That said, I do think certain parts of the Geekbench score might reveal the answer. I’ve seen some anecdotal evidence of this.

If I have time, I’ll take a peek at the 5960X’s posted Geekbench scores online and see if I can make a guess as to how much better (or worse) a single core on it might be.

The only other factor I can think of that may allow the 8-core to help you, is if other real-time effects, at the time of record (elsewhere in Cubase) that would have shared the “Record Enabled” core (and stealing from it), happen to get moved to one of those two extra cores the 5960X has. If so, it could be just enough to help.

But there is no way to know this and frankly, that’s a terrible strategy as it could change from reboot to reboot.

Sigh, it’s complicated.

Btw, how large the Kontakt patch is, shouldn’t matter much. Only the voice / polyphony count and real-time effects on that patch (preset) should matter.

You might try removing any Kontakt-based effects on the preset (if there are any) and move it to a group buss or send in Cubase. This might move that workload to a different CPU core and free up just enough to prevent the spiking.

Btw, I have a gut feeling that a cheaper, 4 core (but running at a higher clock, per core) would solve this issue for you. But at the cost of possible lower, overall performance for general mix duty (the larger ASIO buffer related stuff that CAN make use of all cores, for sure).

I’d try a latency monitor program and make sure you aren’t getting spikes. I recently started getting poorer asio performance and it turned out that the latest Intel nic drivers were causing it. I rolled back to the previous version and the spikes disappeared.

As some have already pointed out, record enabling or monitoring disables the ASIO guard buffer so you can play/record without the additional latency. What is your actual buffer setting ? 128 samples ?

@Jalcide,

Presumably, tuning ASIO Guard off will disable the dual buffer setup, and put everything on an equal basis?

If so, if what you write is true, the issue should disappear. Of course, capacity might be reduced.

For Win 8.x, the old dpclat.exe does not work, so use LatencyMon. Even though it is not as simple as dpclat, it gives a lot more indication of what is creating latencies.

+1 on the last post.
My motherboard has 6 additional USB-3 ports, realized using a VIA controller, that really messed up my daw after an driver update. LatencyMon was really helpful finding the culprit.

True. Good point. It’s worth a try!

It seems like the results of this test would:

a) support my hypothesis, if it works.

b) refute it, if it doesn’t AND there is plenty of ASIO performance left.

c) be inconclusive if it doesn’t work and turning ASIO Guard off overloads the audio engine (or is very near being overloaded).

Easy to test and the results should be interesting.