Cubase 14.0.20 odd behaviour (reduce cpu usage with one simple action)

Cubase
1

I’ve encountered an unusual issue in Cubase Pro 14.0.20. In projects that demand significant CPU power—such as those with numerous VST instruments or a large number of audio tracks loaded with plugins for mixing and mastering—the performance meter consistently shows CPU usage near its maximum. This eventually leads to audible audio clipping during the work process.

However, I discovered something unexpected. When I enable the “Record Enable” button on a VST instrument track, the CPU usage drops to nearly half, eliminating the issue. After this, I can add more plugins without any further problems. I suspect this behavior is related to the architecture of my Intel 13th Gen CPU, where the processor seems to optimize its performance as intended once the record function is activated.

To clarify further:

  • More than 8 projects have been tested.
  • Buffer sizes were tested with various values ranging from 128 to 2048.
  • Projects consisting only of audio tracks were tested as well. Adding a single instance of Halion resulted in reduced CPU usage as long as Record Enable is active.
  • Activating the “Record Enable” button on an instrument track alone resolves the issue—no additional changes are required.
  • All drivers, including Windows, are fully updated.

edit :

  • The CPU reduction effect can occur with any VST instrument, but the extent may vary depending on the specific instrument being used and even the preset selected!
  • For the effect to occur, ASIO-Guard needs to be enabled.
  • This has been tested on projects containing only audio tracks (with at least one VST instrument, of course) as well as on projects where over 90% of the tracks are VST instruments, including FX tracks, group channels, and other elements.

PC Specifications:

  • Software: Cubase Pro 14.0.20
  • Soundcard: Steinberg UR24C
  • Processor: Intel Core i9-13900K
  • RAM: 128GB (XMP profile not activated)
  • Graphics Card: NVIDIA RTX 4070 Ti
  • Operating System: Windows 11 Pro, Version 23H2 (OS Build: 22631.5189)

Here are two images illustrating the effects of this action, both before and after.

1
13051×1929 396 KB

2
23028×1926 383 KB

5 Likes
2

Hi,

If you enable Record on a track, this track goes to the real-time mode. So it doesn’t use the ASIO Guard and latency-compensation mechanism. The signal is not pre-processed; it’s processed directly in real-time instead.

2 Likes
3

Thanks
Is there any way to make it permanent, allowing me to fully utilize my PC’s power for projects?

4

Hi,

In the Studio Setup > Audio System > Advanced Options, you can try to deactivate the ASIO-Guard.

5

I deactivated ASIO-Guard, but the CPU usage remained unchanged. Additionally, enabling the record track no longer reduced CPU usage. However, after reactivating ASIO-Guard and then enabling the record track, the CPU usage dropped by half.

2 Likes
6

Brilliant!! Works here like a charm, at least 25% better performance just record enabling one instrument of 50. Thanks for posting this. :clap:
Hopefully SB can take note and give us a button to make this permanent.

PC Specifications:

  • Software: Cubase Pro 14.0.20
  • Soundcard: Focusrite Scarlett Solo 3rd Gen
  • Processor: Intel Core i7-13700KF
  • RAM: 128GB
  • Graphics Card: NVIDIA GTX 1060
  • Operating System: Windows 11 Home, Version 23H2 (OS Build: 22631.5189)
3 Likes
7

Thank you for sharing this. I hope it benefits many users. I was excited to discover it about a month ago, but I decided to test it in different scenarios first to fully understand what’s happening before sharing it with the community.

I should mention that testing with different VSTs will lead to varying levels of CPU reduction.

1 Like
8

That’s interesting. I haven’t tried this in 14 yet but in 13 it was opposite. Record enabling a vsti disabled asio guard and cpu usage went up.

1 Like
9

Thanks for trying it out
In this scenario, ASIO Guard should remain enabled. Disabling it not only has no noticeable effect but also increases CPU usage, at least in the case of Cubase 14

Could you also share your PC specifications, particularly the CPU and operating system? Thanks!

10

Test in my old I5 laptop:
It´s true that Asio guard may drop a lot but real time is increased. Not worth in my case. I guess it depends on how your workstation handles the real time.
Test in my studio PC Ryzen 9 3950x:
Some tracks in record enable drop a little CPU performance and some increase it (I guess it depends on the plugins). In overall there´s no benefit in my case and maybe worse performance.
My conclusion is that may works for really powerful CPUs and depending on the project.

2 Likes
11

I see your point, and it’s valid. I ran this test because I have an Intel Core i9 CPU, and I wasn’t expecting the performance to be this low — which made me suspect something was wrong, and it turns out I was right.
It seems Cubase still isn’t fully utilizing the capabilities of 13th Gen Intel CPUs.
I’m sharing this because I believe it could help improve Steinberg’s software.
By the way thanks for trying it out.

1 Like
12

There is an old thread on the same (or maybe just very similar? – I don’t recall all the details at this point, and it’s a very long thread with multiple people reporting their experiences and my also adding subsequent findings after my original post) that I started on this back in Cubase 13 days after reading a similar tip in a Facebook group:

Note that my CPU is decidedly not one of those ultra-modern ones – it’s an i7 5820k (from memory, I think I built the system in late 2014). The basic finding, though, was that this “trick” seemed to get Windows 10 to balance CPU usage better, and I put some CPU usage graphs from Task Manager in the post that showed that.

I’d totally forgotten about this over time, and I don’t recall if it just stopped working for me, was too inconvenient to use for some reason, or … The bottom line, though, is I haven’t even tried it with Cubase 14. Hopefully I can remember to do that soon. (Needless to say, with such an old CPU, my performance at mix/master time, when there are some heavy-duty plugins running, can be way less than adequate.)

1 Like
13

@rickpaul , @MaArt91

It has to be Halion?

It doesn’t have to be record enabled?

Thanks!

14

You may want to read through the original thread I linked, but I found it did NOT have to be HALion. In fact, I mentioned later in the thread (which I just reread) that I got a more evenly-distributed CPU graph in a test with Kontakt 7 than I had in my initial test with HALion, and I also did similar tests with a number of other virtual instruments. However, I suspect the distribution may depend on what is going on at the time. One guy in the thread mentioned it had to at least be monitor-enabled, but, at least on my system, I found the key was having the focus on that track, which, because it was an enabled instrument track, automatically record-enabled it (based on my preferences).

I think the key, though, was that it has to make the HALion track go on a real-time thread, instead of the ASIO Guard threads.

1 Like
15

Thanks for sharing but there is an important information missing.
You write “CPU usage”. What are you looking at exactly? Windows Task Manager CPU usage? Cubase performance meter - ASIO Guard? Real Time? Peak?

1 Like
16

thanks I’m going to try this on Mac & see if it does anything on my big projects. it makes sense because a lot of us saw increased CPU loads after upgrading versions. with many having to use a different ASIO host like Audiogridder.

it reminds me a bit of the the template issue where the first track of the project doesn’t have ASIO guard enabled because of some odd bug of adding the track to a new project in a fresh session. deleting & readding the track resolves. i’m wondering if this one isn’t tied to project / template file too.

i get the feeling the vst host portion of cubase hasn’t been quite right for a while & the fact that this problem still remains in 14… they just letting the issues pile up.

2 Likes
17

I just did a quick test with my latest project, which I’d left in a work mix state last time I work on that. Specifically, it currently has 9 stereo audio tracks (1 of which, the count-in, isn’t doing anything during the playback range, and 8 of which are frozen with FX, one FX track (being sent audio from 3 audio tracks), one vocal submix group (mostly to send sidechain info for now), one instruments submix group (with two live FX, both of which are sidechained from the vocal submix, and the two group tracks feeding the stereo out (which has 4 inserts as a temporary mastering chain). The project runs at 96 kHz. Here is a screenshot of the annotated MixConsole (everything else in the project is disabled, including any FX on group tracks that aren’t being used due to being rendered to audio to save on CPU):

image
image1421×970 199 KB

Playing back the project as is, has the sound cutting out on the order of every second or partial second, with a static-type sound mixed with the project playback, and here is what Windows 10’s CPU section of the Task Manager’s performance tab looks like:

CPU meter without Halion, AtLTPN
CPU meter without Halion, AtLTPN1323×713 43.4 KB

So, revisiting the “HALion trick”, which was just adding a single instrument with HALion Sonic, with no samples loaded within it as track 40, with the focus on that track (so it is in record mode), the project played back fully, without the severe interruptions it had without HALion, though occasionally there was a bit of distortion (keep in mind my CPU is an i7 5820k). Here is what the same Task Manager screen looked like at approximately the same point in playback (which was long enough that it only includes playback in the graphs, no time between or before playback):

CPU meter with Halion, AtLTPN
CPU meter with Halion, AtLTPN1326×712 44.2 KB

My observations:

There is a little more memory use with HALion added (it goes from 60% full to 69% full – though I can’t be positive if that extra 9% is totally from HALion or if some Windows something happened to strike at the same time (interestingly Disk P: shows some activity, but that is not used in Cubase at all, nor should it really be used by the OS in most cases since it is mainly a media library that is only used when I working in Lightroom, playing specific media that is stored there, or downloading certain music software updates). Beyond that, most stats are pretty similar, other than on the CPU front.

As for the CPU the Task Manager average CPU utilization goes from 18% without HALion to 22% with HALion, and I notice Speed goes from 3.33 GHz to 3.27 GHz, respectively. There are also 102 more threads and 4 more process in the snapshot with HALion. I should probably note that I forgot to take a screen shot without HALion initially, so I took that later – i.e. after removing HALion from the project after the test with it in. The audible results were the same both before HALion was added and after it was removed.

What seems to be meaningful here, though is what shows in the top 4 CPU graphs (and, maybe slightly less so, a few in the second row. In particular, without HALion the second CPU (I think it would be named CPU1 since I believe the count starts from CPU0), is relatively high, while all the others are lower, with none of those others even coming to half the level of CPU1 during the minute plus I ran that playback. However, with HALion added, CPU1’s level goes down a bit, CPU0 now comes pretty close to the level of CPU1, and both CPU2 and CPU3 also come somewhere around the halfway point, with CPU4 coming a bit closer to the halfway point – but, of course, the “halfway point” is lowered a bit due to CPU1’s level coming down a little. The rest are pretty close to where they were without HALion.

It would be interesting to know whether the HALion/real time thread now goes on CPU0, keeping the biggest part of the processing on CPU1, or if maybe HALion’s real time thread actually goes on CPU1, reducing what had been on the main previous thread more by sharing more of what was on there to CPU2, CPU3, and CPU4.

Independent of any detailed speculation on that front, the bottom line is, putting HALion in the project this way let my project play back pretty well, whereas it didn’t even come close without HALion in there.

2 Likes
18

nice work. i truly hope someone at steinberg has been taking this issue seriously & cubase gets back on track.

the graphic shows better utilization across the cores.

this is certainly a better option than hosting in audiogridder.

*edit - on second thought, i remember there is some kind of 2nd buffer added when a track is record enabled. is that what is happening?

1 Like
19

Around the same time as the original thread I linked above, there was another, at least somewhat related thread, in which @Ed_Doll of Steinberg mentioned they were looking into how processor affinity might come into play in some of the differences in audio engine performance between Cubase 12 and Cubase 13, saying there was a possibility that changes they made to improve things for newer hybrid CPU environments may have negatively affected older, non-hybrid CPUs, but they were still investigating:

I seem to remember there was a maintenance release for Cubase 13 that had a note that suggested some change may have been made in this area, but, if so, it didn’t appear to make a difference for my (older, non-hybrid) CPU. And, until seeing this thread, I’d forgotten about the record-enabled HALion track trick to (potentially) improve audio streaming behavior at mix time (when I tend to be using heavy CPU usage, and high latency plugins that often get to a point where my CPU, or at least something in the audio buffer supply path, can’t keep up).

I’m not sure what you’re alluding to here, but, just doing a quick Google search on the topic, I did come across Google’s AI-generated response that talks about the difference in buffer size behavior when there is a record-enabled track and ASIO Guard is in use. The main part of the response says:

When a track is record-enabled in Cubase, it utilizes a smaller buffer size within the real-time path, which can strain the CPU. This is because all calculations must be completed in time to fill the buffer, otherwise, audio dropouts may occur. The ASIOGuard path, used for other tracks, employs a larger buffer to prevent dropouts but introduces higher latency.

Of course, what seems to be happening here is that, although CPU usage goes up overall, Cubase does a better job of supplying the ASIO Guard-related buffers in time for streaming, assumedly due to the more balanced allocation of CPU threads that my screen shots above show. Perhaps having to give higher priority to the real time thread (which doesn’t actually have buffers to supply to the audio engine in this case) somehow lets Cubase distribute the ASIO Guard threads a bit more???

From what CPU usage would seem to show in the non-HALion case, it’s not like the system overall is overwhelmed, but the net is that Cubase can’t supply buffers quickly enough (and I’m using the highest buffer size my audio interface supports – 2048 samples at my project’s 96 kHz sample rate), so audio dropouts happen. But why this improves when the real-time thread is added???

2 Likes
20

As far as I know, it doesn’t have to be Halion or any specific VST instrument. However, two things are essential:

  1. ASIO-Guard must be active.
  2. Record Enable on the VST instrument track must be enabled.