Need help to analyse these numbers to optimise Cubase 10

Hi There,

Hope all is well?

I’ve loaded a very large project and am trying to understand why my buffer size selection on playback is getting these results?

At a buffer size of 4096
Average load peaking at 23%
Realtime Peaking at 0%
Disk Cache Load peaking at 23%

At a buffer size of 32
Average load peaking at 35%
Realtime peaking at 10%
Disk Cache load peaking at 0%

99% of the project contains large VST Instruments and plugins (including on the master buss) and use very little audio!

Everything is rock solid at both buffer sizes and am not getting any performance issues but I always thought that selecting the highest buffer size on playback was always the way to go to put less demands on ones PC?

As in real terms there are no issues maybe I shouldn’t worry about these results but the higher buffer size results have really surprised me?

Any thoughts would be greatly appreciated however I’m so aware that if it ain’t broke - don’t fix it! :wink:

Kind regards from London, England

James Colah

Ehh the numbers show exactly that, less demanding @ higher buffer settings ?

Hi peakae,

Many thanks for your reply.

I’m not very technical so was concerned that at a buffer size of 4096 the disk cache load was peaking at 23%?

If you have the time and inclination can you explain to me in laymens terms why I need not worry about the disk cache load - is it because the Average Load indicator is more of an indication of overall CPU performance so the lower it is the better?

Kind regards

James Colah

Hi James,

These figures greatly depends on what hardware & (ASIO) driver you use and if you’re actually playing with ‘recording’ and/or ‘monitoring’ enabled on a selected track?

For the CPU: (Avergage & Realtime load). A higher load on lower (32) or higher (4096) buffer sizes can be explained. Higher load on (32) is because your computer needs to work harder to process all the data within smaller packages. More packages is more work!

For the disk: The disk cache load can also be explained. Disks, even SSD’s still think in clusters. When you use larger buffer sizes disks need to process more data and distribute them over more clusters. Resulting into more calculating and write/read actions as opposed to using smaller buffer sizes. Which will need less clusters to write to.

Knowing that hard disks are substantially slower than the internal CPU’s cache and RAM memory, the bottle neck will always be the performance of the hard disk!

That’s why you in general see such a tremendous improvement when using an SSD as opposed to a conventional ATA drive as a computer’s system drive? But in real life even the performance of the fastest SSD is still extremely slow compared to CPU cache and DDR4 memory. The fastest SSD drive today is around 3500Mb/s read/write. For DDR4 2400 Mhz memory the transfer rate is 19.2GB/s. So you can see there’s a difference?

So it’s actually impossible to get a clear comparison with projects like these? because of this:

  • Some plugins/instruments feel better at home with lower/higher buffer sizes than others? Eaxample: NI Kontakt (large) vs steinberg’s monologue (small)? So either way it can put more strain on your computer and HD?
  • Do you use VST2 and VST3 together? VST2 will remain active while idle, whilst VST3 will go to sleep when not actively used. Even when the song is playing?

The most important thing for Cubase is that the CPU will always be awake for any instruction and not go asleep while waiting (where talking micro seconds here…but being at sleep for that long is a disgrace for a processor!). And next is that the hard disk will always be available when needed (And that’s even more important because they are by nature extremely lazy and even more lazy getting out of sleep. Even SSD’s)!

And that we can configure by using the ‘Steinberg Power Scheme’ under VST devices. Or you could create your own custom ‘power scheme’ if you want to and leave this unchecked.

Hi Nickeldome,

Thank you so much for your detailed explanation and can understand the concept better now.

Kind regards

James Colah