Quick Cubase 7.5 vs. 8 performance test


I did two quick performance tests between Cubase 7.5 64bit vs. Cubase 8 Pro 64bit. I thought I’d share them with you. I’ve attached screenshots showing performance meters of both versions side by side.

In the first test I had 48 audio tracks, each of them having one instance of Thrillseeker VBL compressor.

In the second test I had only one audiotrack that was routed through 3 groups to the master bus. The audiotrack and each of the groups had one instance of Thrillseeker VBL compressor. And finally the master bus had 5 VBL’s.

In both tests I had ASIO guard on, and on Cubase 8 it was on the lowest setting. I kept buffer size at 96 samples and samplerate at 48kHz.

(I did the same tests with ASIO guard off as well but the results were actually identical. That’s why I didn’t bother posting screens of those. Well at least nothing has changed for worse after the new sound engine.)

But what’s really great is the fact that in the first test I could see (on my system at least) clear improvement in performance with the ASIO guard on. And further improvement could be achieved with higher ASIO guard settings.

But the second test is SUPER cool actually. In 7.5 the group and master processing is taxing realtime performance heavily, but in 8 you start to wonder, wether you accidentally opened a wrong Project! The difference is huge! Now this is just a very quick test, but seems like Steinberg has really done something right!

Well, see the screenshots already if you haven’t! :slight_smile:
Cubase 7.5 vs 8_1.jpg
Cubase 7.5 vs 8_2.jpg

Hmmm. don’t want to break the party, but picture 2 is a bit over the top.
OK, picture 1 shows that indeed performance is better, but picture2 is plagued by an armed channel where the asio guard is not kicking in.
Asio guard is not present in realtime asiomeasurement. It is in fact taking things away from it.
But overall indeed there is a better performance in comparison with 7.

kind regards,

Aloha guys just to chime in.

Still having some minor start-up probs with C8P but
when I do get it up-and-running, here is an observation
on this topic:

I have a ‘test project’ that is designed to push my ax to its limits.
The project does not even sound good to the ear.

That’s because it is just a bunch of diff Steiny and 3rd party plugs/FX/VSTI’s
with stereo audio/MIDI tracks etc used to max out computer performance.

This project is my yardstick and while it plays just fine, it always rides at about 95>99% of cpu juice usage.

Last night I loaded that ‘test project’ into C8P (with ASIO Guard at its full setting).
The project now rides at about 78—>81%.

Kool for sure but ‘Sup wi dat’??

Don’t know why.

Just sayin’.


So, with ASIO Guard On, go look at your VST ASIO Guard latency… Now, turn ASIO Guard off and set your audio card so that it has the same latency that you were seeing for the ASIO Guard latency. Now look at your performance.

Why do you choose a 32 bit plugin for your test?
Asio Guard doesn’t seem working fine with 32 bit generation plugins. Steinberg suggests to disable that feature for those VST, as well.

all plugs/FXs are @ 64 bit

Hmm. What do you mean By an armed channel? Do you mean record enabled, I don’t see any channels being record enabled?
What I thought from that picture was that ASIO guard is more efficient in taking away real time performance than before.

Oops. As I said this was just a quick test. And actually performed in the middle of the night, so I wasn’t at my brightest. :slight_smile: The plugins are bridged with jBridge.


Alright, I tested with 64bit plugs and I was seeing exactly same results.

Also, the huge realtime performance difference in test 2 is still there. I tried the second test with asio guard off and the performance between Cubase 7.5 and 8 was almost identical. But in CB8 enabling asio guard takes the realtime performance down, in CB7.5 not.

Seems like the old asio guard could not help with group and master processing, but the new one can.

To me this is great. :slight_smile:


I see in your pictures you use ASIO4ALL.

ASIO4ALL usually creates big problems right off the bat for PC users. I would avoid it and get a native asio driver for your hardware if possible.

Best Regards,

Does it seem to you Scott that I have big problems then? :slight_smile:
Over the years, I have switched between my native drivers and asio4all many times. Performance and reliability have always been the same on both drivers. I’m using asio4all because it’s more flexible in changing buffer size, than Edirols own driver.
I don’t think that I would see a different outcome for these tests using native drivers. (I might test it though, just to be sure…)


All I can say is that performance on my PC was very good with 7.5, but is worse and problematic in 8 Pro