C8 poor performance-compared to C7 and Reaper

I was mixing yesterday and could see my performance meters heading towards the red on a fairly ordinary project and thought to myself ‘is this normal performance?’ so I recreated the exact same project in Reaper, the ONLY differences were;

1; I used reverberate as my room verb, instead of the stienberg reverence
2; use Valhalla verb for the chamber instead of the Cubase verb revelation
3; use reaper own delay, and chorus plugs along side reapers own EQ where I’d use Cubase EQ.

I used Reapers folders as group tracks.

none of these things should make much difference really.

so have a look at the two screen grabs from more or less the same point in the song.

Cubase is showing 75% average with realtime peaks going nearly in the red.

reaper is chugging along at 12%

what’s happening here?


no one got any light to shed on this? quite a shocking difference!


Presumably you are running each project at the same sample rate? Asioguard setting?

The problem with Cubase is that it does not handle cores very well. It is supposed to be a lot better with higher clock rates, but I see that your machine(4.6) is a fairly powerful machine.

I am damned if I know what the answer is and depressingly I’m not sure that Steinberg do and if they do the worry is that it is something difficult to recode.

Reaper may or may not be more efficient than Cubase but the first thing I’d say is that you should ignore any CPU/ASIO meters. You should look at how many plugins you can run before you get audio dropouts/glitches. From what I’ve seen, the meter in Cubase tends to initially rise very quickly as soon as you add a few plugins but does not correlate that well with the actual overall plugin processing capacity.

I’ve heard a few people talking about Reaper being very efficient but why not actually document that properly with a methodical test (e.g. something along the lines of DAWBench) otherwise it’s not very useful info (although it maybe points towards something useful).

I have a 2010 vintage quad core and I had high hopes for Reaper, as I have felt the performance drop from Cubase 6 - 8. However, in my testing duplicating a Cubase project across to Reaper with lot of VSTi’s is that Cubase still performs better when under big loads. My impression is that Reaper is quite efficient, but has a breaking point when really pushed - whereas Cubase ASIO is often 80% or higher yet still playing without glitches. Hey, I’m not at all bashing Reaper - I own it, but I haven’t found its outright performance to be as dramatically different from Cubase 8.5 than I may have thought or hoped.

I think you could cast more light on this if you used task manager to open the CPU usage - you can use this to show per-core load as well - whilst running these projects in both Cubase and Reaper. I’d be very interested to see what these look like. At the moment you’re showing Reaper’s version of CPU usage and comparing it with Cubase’s readout of ASIO average and ASIO peak load. The ASIO reading is some kind of aggregated alchemy that relates to CPU power, audio interface and interface driver.


I never understood the asio performance meter (I’m a performance consultant on RDBMS systems in real life, so have a lot experience in measuring things).

Steinberg should implement things like the others (cakewalk/avid/reaper), there you see the processes and cpu’s.

I think of it as the time it takes Cubase to process all the audio for one single buffer of the sound device as a percentage of the size, or length in time, of that buffer. The meters therefore only show what’s relevant to avoiding pops and clicks due to not being able to process audio in time. Probably a slightly simplified view of how it actually works, but it is certainly a reasonable way of doing it, for example consider that some disk streaming holds up the processing of the next buffer, then this is included in the Cubase performance meter but obviously not in the OS CPU performance, so the OS performance meter would give you no indication of a problem.

We definitely need the performance meter to be broken down by plugin and possibly disk access and anything else relevant as well so we can identify problems. This may actually sort a lot of unexplained glitches for all sorts of people on this forum!!!


Unfortunately, this isn’t news. It’s the same issue I’ve been having since switching to win10 and Cubase 8.5… Steinberg’s response was, as usual, to attack the messenger, instead of acknowledging the problem. The CPU issue is pretty obvious, as I’ve had the same project open in win7 and the CPU usage was a LOT lower. So my guess is, it’s a compatibility issue with win10. Whatever the problem may be, I’m done being a free beta tester for Steinberg. Life is too short, and I’ve wasted too much time already trying to get a product I paid for to work as advertised.
But if you want this fixed, the only way is to file an official bug report, then fight with the tech support until they acknowledge the problem and agree to fix it in the future. Then wait. And pray…

Or just switch to Reaper.

Good luck :slight_smile:

Here’s the thread, for reference:

…and within that recent (short) thread you said in response to a suggestion to help you…

I think the issue you raised in your thread, like your response to this one, is about a difference you’ve noticed between Windows 7 and Windows 10, and doesn’t really help the OP.


The Performance Monitor in Cubase is confusing. I choose to ignore it. If the DAW is working and handling whatever I throw at it…all is well.

One DAW is speaking German, and the other is New York English…in terms of raw physics and math, they are both doing something very similar, and BOTH are really good audio engines for the money…

Compare them with Windows “Resource Monitor”?

Is either DAW sounding bad or breaking your projects?

Can you keep adding stuff to the Cubase project without it sounding bad?

How many CPU cycles an application uses doesn’t necessarily mean it can’t keep doing more work, or that it will stop other processes from doing their ‘real time’ jobs well. Just as an example: Finale uses 40% CPU on my system (pretty much keeping one of 6 cores maxed out anytime the program is playing a score)…with zero plugins, and using an external MIDI instrument, but it works just fine and never misses a beat. I can switch over to VST plugins (or side host them in a 64bit Bidule host) and start stacking voices…40 voices later in something Like ARIA or Halion 5, and it still asks for about 40% of the system resources and rarely more. I can start loading up other applications on the side (a browser, virus scan, encoding a video in the background, etc.) and Finale still chucks right along asking for 40 to 45% of system resources, and my other apps run just fine without noticeable lags or slowdown. Coincidently, Finale is 32bit only…and it performs about the same for me on an old single core Celeron laptop (asking for and using about 40% to 100% of system resources). So…it really doesn’t matter to me anymore as long as things work properly and my work-flow isn’t interrupted.

Streaming doesn’t really need a bunch of CPU cycles…but instead needs bandwidth on the bus, and drivers/hardware that can efficiently seek out and deliver timing sensitive data streams. Cubase can’t control how drivers and devices retrieve data from a device and present it to the OS, and Steinberg cannot rewrite their drivers for them…all it can do is use buffers to estimate issues and get ahead of the process to try to align all the incoming data so it syncs up when converted to analogue by an audio card and sounds right. Sometimes drivers for a hard disk or host controller just have lousy streaming performance…maybe they use massive and very fast ‘burst mode’ chunks of data with interrupts between them…which don’t translate well for real time streaming applications…so, a DAW is forced to ‘work ahead’ and introduce latency while it waits around for the data bursts to come in and be melded together. In addition to whatever disk/host drivers are doing…the DAW also has to contend with the driver(s) for your audio interface…

ALL real time streaming applications must do this. All DAWS…
I suspect that what the performance monitor in Cubase is showing you is buffering activity…just because the buffer is filling up and being used doesn’t necessarily mean you’re in trouble. Keep working until you HEAR a problem…then increase the buffer size and keep working. If your project gets big enough that your buffers are maxed out…then it’s time to either load more samples directly into RAM (increase their preload times if possible), or render some VSTi activity into audio tracks that don’t need to rely on ‘hard drive seeks’.

With all that in mind, I’m curious about what the OSes “Resource Monitor” shows you. Is there really that big of a difference in system resources being used, or raw performance between the two DAWs? Or is it just that the meters built into the DAWs are not trying to measure and display the same stuff? Does it really matter?

Again, DAWs are NOT ‘discrete’ applications free to run ‘as fast as possible with as few cycles as possible’…they rely on clocks and such in your audio interface. A DAW that seems to use a lot of CPU cycles or other system resources doesn’t necessarily mean it can’t take on more jobs without issue.

In windows 10, right click the start button, choose task manager, click the Performance Tab, then click “Open Resource Monitor” at the bottom of the window.

In Windows 7, hit alt-ctrl-del, then choose task manager, then Performance, then Resource Monitor.

As for the Performance Monitor that’s built into Cubase…for me it doesn’t seem to have much if anything to do with system resources or efficiency, but rather, it’s indicating audio buffers filling and emptying as it relates to disk drive activity. If the bottom bar is bouncing around and peaking a lot with a simple one or two track VSTi project (at least in my experience), it’s probably a good time to try some different hard drive(s), or a different hard drive host controller. As for the top bar…I don’t worry about that one unless I’m hearing glitches…then I make the audio interface/ASIO buffer larger.

I notice if no MIDI or VSTi tracks are armed for recording or live monitoring there is very little activity in the Cubase Performance Monitor. The more stuff I have ‘armed’ the more activity I see in that little meter.

Fortunately, any issues I’ve had with Cubase so far (from versions 7 - 8.5) have been resolved by weeding out bad hardware or drivers. I.E. I had a pair of PNY SSD drives that despite benching well and passing brutal latency checks, created glitches in the sound, and spikes in Performance when asked by a DAW to stream data (they were using an interrupt and burst mode that none of my streaming applications like). I stopped trying to stream anything from those drives…and the problem went away. In my case these drives didn’t just mess up with plugins hosted in Cubase…they were also messing up with things hosted in Sibelius, Finale, Bidule, Ableton Lite, and even in their stand alone variants.

sorry been away for a couple of days,

Thanks for the replies people. I’ve read through and my immediate thoughts are; this could indeed be a Cubase 8/ windows 10 thing. I have a windows 8.1 backup disk I think that I might throw in the machine to check.

the other points about the cpu meters; I know Cubase meter is as ASIO meter as they call it but, if it hits the red then you’ve got drop outs, so it doesn’t matter what it’s called if it’s in the red then it’s BAD.

My machine is pretty powerful and if you look at the screen grabs I was mixing a fairly modest, by modern standards track and was seeing high usage which was why I did the experiment. I’ve A/B’d Cubase and Reaper over the years and never found much difference performance wise. THis time I was shocked at the difference!!! hence my posting.

I’m going to do and exact project test tomorrow so will post the results. I’ll keep adding a set of plugins until there’s overload and see how they both compare. I’ll use the same audio as before, and set up a set of FX channels and groups too so it’s a real world project mix.


Hello Norbury Brook - Great idea, thanks, can’t wait to see the results.

Also, I hope someone with 8.5 will do the same thing.

Will be interesting to see the results.

If you have the time, it might be worth making two different tests. One ‘real world’ kind of session, as you describe, with a selection of groups/FX tracks and perhaps some master buss processing and then another session with no groups/routing/FX/mater processing. Just individual tracks with let’s say 4 plugins on each, and test how many times the track can be duplicated before audio dropouts occur.

Just think this might provide some useful info on what the strengths/weaknesses of each DAW engine are.

An idea, keep only standard stuff in the project so others can do the test and compare results.

I think it’s actually a lot simpler than that. The ASIO meter shows how much data is residing in the ASIO buffer.
When the ASIO meter lights up fully, it’s because the buffer was empty, because Cubase couldn’t stuff it with data in time.

Also, I believe Reaper is coded far more efficiently. The Reaper executable is only 6MB!

It’s true that Reaper (225.00 USD) has some positive MOJO going on under the hood. It has a great reputation for stability. It also has some unique capabilities that nothing else has yet (that I know of) like OSC support.

However…on the whole, it is totally missing MANY editors and features present in Cubase Pro ($550 US) that will necessitate a much larger main executable. Reaper’s feature set falls somewhere between Cubase Elements ($99 USD), and Artist ($299.00 USD)…so it’s important to keep that in mind when considering the ‘size of the main executable’. So, comparing the executable size of Reaper to Elements or Artist would be a bit more in line.

Just a few features missing from Reaper (as compared to Cubase Pro or Nuendo) I can think of off the top of my head:

  • Score Editor/interpreter/printer with XML support?
  • Full user access and built in editors to build and edit remote control and instrument profiles?
  • VST connect and Cloud?
  • Integrated Media Browser with full relational database?

Such an assumption based on ‘the size of the main executable’ is kind of like thinking Notepad is more efficient than Word because it has a ‘smaller executable’.

Less code in the main executable doesn’t necessarily mean ‘more efficient’. If an application has 1/2 or less of the feature set of another…of course it will have a ‘smaller executable’.

Also, what is very efficient for a given CPU and chipset, might well be very inefficient on a different hardware architecture. Often applications are ‘compiled’ with a lot of system checks to optimize itself for a plethora of different CPUs and system architectures…flags set to take advantage of extra hardware ‘if present’, but it still needs the ‘fall-back’ code to use alternatives when needed (sometimes that’s not provided by the OS…or can be better done with custom libraries that the OS offers, that the compiler will throw into the final executable). The ‘larger’ executable that ‘can’ take advantage of extra hardware or CPU feature sets will indeed be ‘more efficient’ on more different systems precisely BECAUSE it has extra code. Etc…

The ASIO meter is pretty useless, ran a project with 25 plugins and the ASIO meter is around 40-50 %.
I then piled on plugins, some heavy ones too, and ended up with 355 plugins before it started stuttering.
I just ignore it now, and all is good :wink:

So then the improvement in performance Steinberg are going to do will be to make the meter less sensitive? :unamused:

So are we learning that the title of the OP maybe ought to be, “ASIO meter in Cubase takes a long time to go from 60% to 100%”?

It’s been posted that Cubase does not distribute work among the cores equally well. Did you happen to notice if that was the case?