Cubase multiprocessing synths unecessarily when record enabled?

[VilleK]

While I was gathering some more data regarding audio spikes that I’m getting with low buffer sizes, I found something else that seems quite odd.

When testing with only a single synth in a project, I noticed that Cubase still spreads the load on multiple cores. I wouldn’t mind that otherwise but with low latencies (buffersize of 64 here) and record enabled it seems to waste a lot of cpu resources.

The same synth, same chord, same everything except “Multi processing” disabled from “Studio” → “Studio setup” → “Audio system” and the load with this heavy patch is three times less.

Now imagine a bigger project and you wanted to record a software instrument on top.
Shouldn’t Cubase rather process an instrument on a single core when record enabled?

Ville

[glennloopez]

you mention no OS, no type of computer etc. anyways, I don’t have that on my computer. Multi processing is best for my setup

[Kouros]

I’ve noticed this recently as well but I can’t remember if it already behaved like this before x.60. Audio tracks still behave as expected, only VSTi’s appear to be taking up all the cores. Tried enabling/disabling multi core in Halion and it makes no difference.

[VilleK]

Sorry about that. This was a bit of a sidetrack when investigating the audiospikes on my system with Cubase. (System specs were in the “main” thread here: Audiospikes with multi processing enabled)

But here goes:
Cubase 12.0.60
Windows 10, v1903
Intel core i9 7900x
X299 Gigabyte aorus Ultra gaming
AMD Radeon rx580
RME Babyface Pro

[VilleK]

Did you guys try disabling multi processing in Cubase’s Studio setup? Buffersize should also be low enough (in my example 64) and the instrument should be record enabled.
If you did this but didn’t see a difference in cpu utilization I’m starting to wonder wether there’s something really funky going on with my system. Since I’m seeing cpu utilization go from ruffly 9% (multi off) to 28% (multi on).

[Kouros]

Yes, I am experiencing the same.

[VilleK]

Ok, thanks for confirming

[Louis_R]

Same issue here with Intel i7-9700K.
Instrument used is XLN Audio Addictive Keys.
(Note : This plugin also exhibits the OpenGL bug so I took it into account during my tests)

Cubase.exe CPU usage :

Multi-Processing = Enabled
When playing, usage increases moderately on all cores.
GUI greatly increases usage on 4 cores and slightly loads the 4 other cores.

Buffer = 32	GUI = Closed	GUI = Open
Idle	10%	30%
Monitored	13%	33%
+ Playing	25%	45%

Buffer = 1024	GUI = Closed	GUI = Open
Idle	< 3%	22%
Monitored	< 3%	22%
+ Playing	6%	26%

Multi-Processing = Disabled
When playing, moderately loads only 1 core.
GUI maxes out 1 core, moderately loads a second core and slightly loads all remaining cores.

Buffer = 32	GUI = Closed	GUI = Open
Idle	5%	25%
Monitored	5%	25%
+ Playing	7%	27%

Buffer = 1024	GUI = Closed	GUI = Open
Idle	< 1,5%	21%
Monitored	< 1,5%	21%
+ Playing	3%	23%

---

So from what I have tested, the CPU usage indeed does increase when the instrument is monitored or playing, and this effect is more pronounced at lower buffer sizes. When Multi-Processing is enabled, the CPU usage increases even further.
These results may differ depending on the instrument used. In my case the plugin isn’t consuming any resources when it isn’t playing since it is sample-based, but some synths however may load the CPU whether they are playing or not, so please do not be fooled by my results. If your synth happens to works all the time under the hood, you’ll have the “Playing” value in place of the “Monitored” line, so it correlates with @VilleK 's results.

The wild thing is that while the CPU usage is greatly reduced when disabling Multi-Processing, the CPU temperature remains the same as when it is enabled. So the additional load Multi-Processing imposes seems to be fake or not reported properly as if some junk instructions were going into circles without having the CPU to actually compute them.

Furthermore, this heat test has been tested with Spitfire Appassionata Strings, and the maximum polyphony count I can reach at a buffer size of 32 is roughly the same in both cases.
With M-P enabled I can reach 210 polyphony before it starts crackling, and with M-P disabled it is 200, so that’s only a 5% decrease. However what I have noticed is that as the voice count increases, the core usage increases exactly the same way, whether M-P is enabled or not, except when it is enabled it increases on 7 cores, and when disabled only a single core is used. At let’s say 100 polyphony the cores % usage show 50% whether it is 1 or 7 cores. I hope you get what I mean. Consequently, with an equal voice count, the total usage reported is much higher when M-P is enabled.
So this is very weird, it really uses more cores than necessary.

Note that the OpenGL bug consistently takes 20% CPU on my system (can vary depending on your specs), so if your project is highly loaded already, opening one of these buggy plugins can max out your CPU and performance will fall apart, so keep that in mind.

---

Additional test with multiple instances of the same instrument, for instance Spitfire BBC SO.
Patch = Violins 1 Long on all instances.
Buffer size = 32
Test method : Holding the sustain pedal and pressing a key repeatedly until I hear significant crackling.

Normal lettering = Voice count per instance
In bold = Total voice count

Instances	M-P = Enabled	M-P = Disabled
1	260	220
2	240 (480)	110 (220)
3	240 (720)	72 (216)
4	200 (800*)	52 (208)

*In the case of BBC SO the voices start to flush after you go above a certain amount, so with 4 instances I cannot go above 200 and it doesn’t crackle (yes I have set the polyphony to the max which is 999, but it starts flushing too early anyway). I’m sure it could go up to 240 as with two or three instances, so the total would be 960 voices .

This behavior is consistent with the use of Multi-Processing. The plugin detects the instances and use a different core for each instance, so the maximum polyphony count increases accordingly.
Nevertheless Task Manager still reports the same core usage whether you are using only one or multiple instances, even though the total polyphony is much different.
Example : 1 instance with 200 voices shows the same core usage as 3 instances with 600 voices.
That’s where lies the issue. Why do a single instance reports the same usage as when using three at the same time, if my total voice count is divided by 3?

As expected, without Multi-Processing the voices are split across all instances.

In any case there is a real advantage of using Multi-Processing when using multiple instruments, or specifically when using multiple instances of the same instrument – assuming the instrument is optimized for this and “instance-aware”, although the CPU usage doesn’t seem to scale with the number of instances and seems to have a fixed initial “dummy” load.

[Kouros]

Can anyone confirm if we are all crazy here or instruments used to behave like audio tracks in this regard when on the realtime path?

I honestly don’t remember a single instrument using up all the cores in equal fashion but I probably only focused on that while testing amp modelling VSTs.

Audio track with Tonex:

Instrument track with Vital (8x OS):

Tonex and Vital:

[Kouros]

Well, now that the can of worms is already open…

Here is one track with Tonex and another with Neural Amp Modeller:

Shouldn’t these tracks be using one core each?

Adding a third audio track with NAM, the second core gets utilized:

[fese]

First of all, enabling multiprocessing produces overhead and uses more CPU, initially. Cubase spawns an additional DSP thread per logical CPU (probably even two, one each for ASIOguard and realtime), and these have to be synchronized, so even when nothing ist computed, you have additional CPU usage due to thread synchronization. You can see that even in an empty project, every core is used a little bit even when not playing.
When having record enable on, the instrument is of course placed in the realtime engine so CPU usage increases, the lower the buffer, the more. That is a given.

Then it depends very much on the instrument in use. Usually, yes, Cubase renders one VST(i) on one thread, but there are also instruments that have their own multithreading (the before mentioned BBC SO e.g.), and there is nothing Cubase can do about that.

That all being said, I can confirm the behavior in a test with one instance of Diva (8 voices, “initialize” patch, multicore disabled) in an otherwise empty project.
When just playing, you get the expected result, one core with a higher CPU usage, two or three a little less (whatever they’re doing), all others just the usual background noise with ~5% usage.
Now when enabling record, thus putting Diva from ASIOguard to realtime, all cores jump to ~25%, except the one with Diva on it which is a bit higher. So this is definetely not Cubase multiprocessing the synth in question, but somehow all realtime threads waking up and doing, well, whatever. The really weird thing is that this increase on all cores depends somewhat on the CPU usage of the VSTI, i.e. with the free Charlatan plugin, the effect is still there, but less pronounced, with all cores going from ~5% to ~8-10% when record enabled.
I admit, I cannot really explain this behaviour.

Edit: Did the same test again in C11. Similar behavior, although C12 performs better in ASIOguard mode with Diva (less than half of the CPU compared to C11!). Realtime, not that much of a difference.

[Louis_R]

I have just updated Synthmaster Player to its latest version and now performance is awful with Multi-Processing turned on, at buffers 256 and lower.

Nothing better than a video to show you guys, you won’t believe what’s the fix to this.

Cubase 12 : Multi-Processing CPU Glitch

As we can see at a buffer of 512 everything runs smoothly, but as soon as I set the buffer size to 265, the audio starts dropping out and the performance meter goes crazy. The dropouts are more intense at lower buffers.

When I tweak the core affinity for the Cubase.exe process, the issue goes away instantly. If I tweak the buffer size afterward (or reset the audio engine by any mean, for example inserting/removing a plugin), the dropouts come back again. Afterward, tweaking the core affinity fixes it once again.

We can also notice that when Cubase is in the glitched state, the dropouts are even more prominent the fewer cores are selected, but even then, tweaking the core affinity to as low as 2 cores still fixes it and permits an almost flawless operation (there’s just a few dropouts here and there because I was at lowest buffer, but only 2 cores isn’t very stable either).

Also note that tweaking the core affinity can be done at random and in any direction in order to fix the glitch, not just going down starting from core 0. You can still check back all core and it will fix it until next time the audio engine is reset.

It seems like Cubase is sending the instructions erratically and is having a hard time to synchronize the tasks between all of the cores. Tweaking the core affinity seems to rearrange the instructions and synchronize everything properly.

When we disable Multi-Processing in Cubase settings, the dropouts do not occur anymore and we do not need to tweak the core affinity any longer.

This is exactly the same issue as the one with Spitfire that I have discovered earlier, as the fix is the same. This would definitely prove that this very specific bug originates from either Cubase or VST. And I’d rather opt for VST because Cubase itself is VST-based, and the Multi-Processing option actually controls how the whole VST system behaves (Cubase AND plugins).

Some people will start saying this is not the appropriate topic to post this… But it concerns the Multi-Processing option and would indicate the presence of an even more severe underlying issue which is the one that was discussed in all the posts above.
How do you guys explain that when this glitch is occuring I have all cores loaded evenly (prior to tweaking the core affinity), and after reducing Cubase.exe core count from eight to 2 or 3, the glitch goes away and now only 2 or 3 cores are loaded instead of all 8 cores, which greatly reduces the global usage?
Of course if we lower the core count we won’t be able to work on large projects nor reach a high polyphony count, but still what kind of weirdness is that?

We are on to something very serious once again but I have a feeling this will continue to be ignored by the developers.