Cubase 10, Windows 10 and multi-core (14+ cores)

As I wrote in the OP, the way Cubase 10 addresses resources and spawnes threads is completely re-designed - NOT just automatic detection of the max threads.

Thanks for clarifying.
Are those new techniques and complete re-design then disabled if something is specified in the audioengine.prop file?
Because otherwise I do not really get what you are trying to get feedback on, considerig thread limit of the OS stays same.
Should be same for all kind of hardware - or are those improvements only active if the CPU could hit the limits?
Seems to be irrelevant to me HOW Cubase spawns threads, as long it does not spawn more than the limit of realtime threads.

But I have to admit I have very limited insight on this - and is more or less off topic.

Still I would prefer if Cubase and MS would adress the root cause itself or at least provide a timeline for it, to allow benefits of recent of multi core processors.

The feedback I’m gathering is to get more info from users I may not be in contact with and make sure the improvement is positively affecting as many systems as possible and that it matches our expectations.

It is general and always active: by all means a different design.
The improvements should be more visible in two main cases: 1. high core-count, and 2. low latency on multi-core machines (but the processing overhead to sync the threads on the OS side is not affected, of course).

It is very relevant, as the way Cubase spawned threads previously is what made the MMCSS limitation exacly 14 (if Cubase didn’t spawn prefetch threads at all, which is not possible and just an example, the limit would have been 28).

Microsoft won’t change it, as this would have ‘system-wide performance implications’ (quoting Pete Brown here) and as mentioned previously “the long-term solution Pete talks about is something totally different and requires an engine re-write with different APIs”, and this is not something that can be done quick and without very extensive testing.

Thanks for taking the time, this is useful (interesting and motivating) information.
I will have a closer look whether the change in strategy has effect on my projects (i9 7900X).

Is there any way to influence/reduce amount of prefetch threads, e.g. by structuring the project/busses/channels in a certain way?

Be warned about the architecture of AMD’s latest multi-die CPUs. Scan Pro Audio has already shown how this configuration is not ideal for real-time audio applications. The inter-core data transfer in the interposer presents delays compared to on-die and essentially results in NUMA like a multi-socket workstation. The same reason multi-socket is not always ideal for pro audio. See the articles:

Fabio, are you saying that this “engine re-write with different APIs” is what we got with Cubase 10 or is this some interim step to get to that point?

No and no. This is what needs to be done, to fix the whole thing (or better said: this had to be started already very long time ago).
Apparently decision to do so is still not taken yet - C10 only tries to improve on the current problem.

No. Cubase Pro 10 is capable of spawning prefetch threads in different amounts, let’s say dynamicaly… or asynchronously.
It’s possible to define it in a different way, via the switches I previously mentioned. However, we’re at the point where I can’t provide more details.
Special cases should be individually discusses with Support via the proper means.

Fabio, does this mean that we can expect new improvements related to multi-core in the coming Cubase 10 updates?

Hi Jorge,

no, the fine tuning I was referring to is already in place, but we (at support) are waiting for a more detailed documentation on how to actually configure the switches correctly.
This does not exclude further improvements, that’s something that needs to be done constantly :slight_smile:


so I did some tests with my recent project (started in Cubase 9.5).
I could not observe any difference b/w C9.5 and C10 for this project, wrt dropouts/overload.
Overloads at same time in both versions (skips Audio and or automation in that case)

  • i7900x, 10 core HT, GTX970, Win10 1809, SSD, Cubase10, RME babyface, all latest drivers/versions
  • Project is loaded, will only run hassle free with AsioGuard High and 1024 samples buffer
  • will not work with AG low/mid
  • Several instances of Omnisphere2, Avenger, Geist, Effects on every track, some grouping, lots of sidechaining (to trackspacer, pro-c2)
  • Load meter is 100% for average, ~0% for realtime, disk spikes
  • Project plays (fine) without crackles (very few sometimes) in that state. If further things are added, it will show audio dropouts in both Cubase versions


How much is the cpu load with this project?

Cubase meter shows ~100% Average load continously, and 50-60 RT load when playing back
10 (20) Cores seem to be working b/w ~20-40% each in task manager

I made another weird observation: freezing one single track (Omnisphere 2.5) in this project does the opposite of easing the resources. The project becomes unplayable (only dropouts, i.e. will not even playback something, meters only flicker). Maybe any hints on this?

This could make sense only if you used a hard drive from the 90s :smiley:

I originally thought I was not experiencing any issues after upgrading to 10 Pro when I turned hyper-threading back on my 10core CPU, but something changed since then. I think a Windows 10 update may have broke something. If I do not disable hyper-threading, I get random pops and spikes. I don’t have time to fiddle around with it, so I just am leaving HT off for now.

Not used versions of Cubase 9-9.5. Tried to return to Cubase 10 Pro. I observe, like many here, the problem with random jumps of RealTime Peak, which after 40-50% of ASIO Average loads give clicks and spikes. The system is fully optimized, the latest drivers for all equipment are installed. The situation is slightly improved by disabling hyper-threading support in the BIOS. But does not solve the problem as a whole.
My system: Windows 10x64 Pro v1809, MB ASUS P8Z77-V, Intel Core i7 3770K 3.5Ghz, 16Gb RAM, ASUS Dual-GTX1060, Cubase Pro 10, RME Babyface, AKAI MPK261
I would not like to give similar examples, but I do not observe a similar problem in other DAWs. I also use the latest versions of Studio One 4, Reaper, Reason 10, Cakewalk BandLab. Therefore, I can say with confidence that the matter is in Cubase. In terms of performance and optimization, unfortunately at the moment it is inferior to them all. I look forward to future updates and solutions to these problems. Otherwise, figuratively speaking, why do you need a Ferrari, if it does not go! Good and good luck to the development team, I know that it is not easy for you now.

In my experience, getting real-time peaks is also related to having the GUIs of some effects open, in particular spectrum analyzers (Voxengo SPAN is specially prone to causing high real-time loads). This improves a lot if you disable hyper-threading, as it seems to give more time to the graphics environment.

disable record button on channel to remove realtime peaks. you ll see the difference

Yes, I knew that. Doing this effectively brings ASIO Guard into active mode, so it improves the performance as the system then plays at the additional latency dictated by ASIO Guard. Anyway, in my particular system, this still is not enough to avoid getting real-time peaks if Hyper-Threading is active and SPAN GUI is also showing. However, replacing SPAN with TDR Nova (only for the spectrum analyzer part in full screen mode) really does the trick. It seems that Nova is less demanding on the CPU when displaying its analyzer.

im confused is it better to have asio guard enabled or disabled?reason why im asking is im getting advice not too use it because it causes audio glitches but some say its better performance if i do use it.

also how do i tell if i have hype threding enabled or disabled?i never got a reply before from steinberg when i asked.

heres my system info–
intel core i7-5820k-3.30ghz
32gb ram
windows 10