Realtime Peaks and Crackles during Monitoring on modern Intel Systems

Cubase
1

Title:
Realtime Peaks and Audio Crackles during Live Monitoring despite low CPU load (i9-12900 / Windows 11)

Hello everyone,

I would like to ask if anybody here has experienced similar realtime peak and crackling problems in Cubase during live monitoring and virtual instrument playback.

I have spent quite a lot of time trying to isolate the issue and at this point I am no longer sure whether this is simply a “normal system optimization” problem.

My current system:

  • Intel i9-12900 (12th Gen)

  • 128 GB RAM

  • AMD Radeon RX 6600

  • Windows 11 Pro 24H2

  • latest BIOS installed

  • latest chipset, GPU and audio drivers installed

  • several SSD/NVMe drives

  • several professional ASIO interfaces tested

The strange part is:
The overall CPU usage remains very low most of the time. Windows Task Manager often shows the system almost idle, while Cubase still produces realtime peaks and sometimes red overload indicators.

Important observations:

  • even completely empty Cubase projects already show realtime peak activity

  • the issue appears in multiple Cubase versions (tested from Cubase 11 up to Cubase 15)

  • the problem becomes significantly worse as soon as monitoring is enabled

  • peaks happen especially during live playing of virtual instruments

  • sometimes even a single instrument/plugin is enough to trigger the behavior

  • LatencyMon did not identify a clear culprit

  • disabling E-cores did not solve the issue

  • different ASIO interfaces produce essentially the same behavior

The important point for me is:
I tested the SAME realtime-monitoring situations in other DAWs on the SAME hardware and under the SAME buffer conditions.

I tested:

  • Studio One

  • Ableton Live

  • REAPER

  • Samplitude

and they all behave significantly calmer and more stable than Cubase on my system.

This is why I no longer believe the issue is simply:
“your hardware is too weak”.

I understand that monitored tracks must run in the realtime path and that low-latency realtime audio is technically demanding.

But my question is:
Why do other DAWs manage the exact same situation much more smoothly on the same machine?

At this point I suspect there may be some Cubase-specific sensitivity involving:

  • realtime scheduling

  • Windows 11

  • Intel hybrid CPUs

  • realtime monitoring

  • or the way Cubase handles realtime audio threads internally.

Has anyone with a similar modern Intel system experienced the same behavior?

And more importantly:
Did anybody actually find a real solution or workaround that improved live realtime performance in Cubase significantly?

Best regards
dimugi

2

The CPU specs don’t really matter for this. What audio buffer settings are you using in Cubase Control Panel? Have you tried increasing the buffer size?

3

Yes, I already tested multiple buffer sizes from low to very high settings, including different audio interfaces and several Cubase versions (11–15).

The strange part is:
even in almost empty projects Cubase shows realtime peaks, while other DAWs on the same system (Studio One, Ableton, etc.) remain much more stable under identical conditions.

So it does not seem to be a simple “buffer too low” issue.

4

Yes, increasing the buffer size helps somewhat, but only from around 512–1024 samples upward.

The problem is:
at that point the latency becomes too high for comfortable realtime playing and monitoring. I can clearly feel and hear the delay while playing instruments live.

So technically Cubase becomes more stable at very high buffer settings, but then realtime performance is no longer usable for actual recording or playing VST instruments.

Other DAWs on the same hardware remain much more responsive at lower latency settings.

5

Unfortunately Cubase already stated they will not do anything about it. Many have said the whole system needs to be redesigned from the ground up and this will never happen until the old guard dies off.

6

Real time audio performance depends on the interface drivers.
If the interfaces use USB, the ability for real time audio is related to the USB drivers performance too.

7

About what? Poor USB drivers? It’s up to the vendor of the USB chipset.

8

Just to clarify:

I already tested multiple audio interfaces, multiple drivers and multiple DAWs on the exact same Windows 11 system.

Studio One, Ableton Live and other DAWs run significantly more stable under the same conditions and at the same latency settings.

So this does not appear to be a general USB issue itself, otherwise the same behaviour would occur across all DAWs equally.

That’s why I currently suspect either Cubase’s realtime handling, scheduling behaviour or the interaction between Cubase and certain modern Windows 11 system components.

9

Prepare to be gaslit by the fabulous Cubase fanboys. This conversation never goes anywhere.

10

A workaround—though, of course, not a permanent solution—might be to run the “peaky” VST instruments via Audio Gridder in Cubase… there are threads discussing this here on the forum.

11

Have you checked DPC Latency with LatecyMon?

12

Yes, i have also checked with LateyMon.

13

And, what was the verdict?

14

I’m not sure if the behavior I’ve seen is identical, though there are at least similarities. For reference, the relevant parts of my Windows 11 system are Intel Core Ultra 9 285k, 64 GB DDR5 RAM, NVME drives for system and audio, SATA SSD for sample libraries, NVidia GeForce RTX 3060 video card with 12 GB VRAM, and MOTU 828x audio interface.

Most of the time, I do not experience audio crackling. However, every once in a while – I’d guess on the order of once or twice a week, even when I just start Cubase up on a project, without even playing back yet, I’ll hear some audio crackling, and I’ll also hear it during playback. It doesn’t really matter what is in the project in terms of potential for CPU load.

When this happens, I can generally get rid of it by changing the buffer size used in the ASIO driver. Here’s the thing, though: I can change it to a smaller buffer, and that will also do the trick. For example, when that happened sometime in the last day or so, my buffer had been set at 256 samples (at 96 kHz), which I arrived at on my older, slower system as a good tradeoff between latency for tracking virtual instruments and vocals and being reasonably confident that my computer could keep up. I changed the setting to 192 samples, and the problem went away. I probably could have changed it back to 256 samples after that, and it probably also would have been okay. I suspect it may relate to some weirdness in the MOTU driver’s or hardware’s state versus something in Cubase’s state, and forcing the driver state change, and Cubase’s reset to match the driver, gets things back on solid ground.

It may be worth mentioning that, on my old Windows 10 system (i7 5280k, lower-end components in general since I built the system well over a decade ago), I’d sometimes have what feels like a related issue on recording audio (only thing I do that for is vocals), where artifacts would also get into the recordings. And sometimes the workaround there could also be going to a smaller sample buffer (though it could also be going to a larger one – it seemed the change may have been more important than the direction of change).

Why does it happen sometimes and not others? I really have no clue. At one point, I was feeling like it might have mattered what I was doing while Cubase was starting up. For example, maybe there were greater odds it would happen if I was watching a video on YouTube. But there was never any definitive “do this and it will happen consistently” recipe, be it to recreate the situation or to make it go away permanently.

One other thing I never saw on Windows 10 with the older system that I have seen a few times in Windows 11 on the new one is rare “blue screen equivalents” that name a MOTU component in the crash log. This has seemed to happen specifically in some cases where I’d been working in one DAW at one sample rate then changed to another DAW at a different sample rate, thus having to let the DAW change the MOTU driver settings to suit the project. It has been extremely rare (I think maybe a max of four times since I built my computer last October), but I never saw that on Windows 10, so I have wondered if maybe the MOTU driver isn’t as solid for Windows 11 as it was for Windows 10. However, I was using the 828x over Thunderbolt 2 in Win10, but I have to use it over USB on Win11 due to the more modern Thunderbolt on the new motherboard not being backward compatible to Thunderbolt 2.

15

Interesting for me. Who is zhe vendor of your mainbord. I have an ASUS for a few months because I need Thunderbolt for my UAD Apollo and it works fine so far, as well as 32 Samples Buffersize at 48kHz. Running on Windows 11.

I had the same interface with my old PCwith windows 10. With 48kHz I had to use t least 128 samples to avoid audio drop outs even with small projects. In the setup changing between Cubase projects between 48 and 44 kHZ sometimes crashed the interface and I had to restart the system.

Now I can run the Cubse 15 Demo by Austin Hull with 32samples in a loop for hours without dropouts.

16

Yes, I already tested LatencyMon extensively before.

The system itself does not show critical DPC latency problems that would explain why Cubase behaves this badly.

What makes this strange is:

  • I tested multiple audio interfaces

  • multiple drivers

  • latest BIOS

  • latest Windows 11 updates

  • different USB ports

  • different DAWs on the SAME machine

And the important point is:
Other DAWs on the same hardware are much more stable and do not produce the same extreme real-time spikes and crackles as Cubase.

So at this point I suspect it is either:

  • the way Cubase handles real-time processing under Win11

  • or some interaction between Cubase and certain drivers/plugins/system components

But it does not look like a general hardware or DPC latency issue anymore.

17

In my case there are also certain plugins/instruments that make the situation much worse.

For example:

  • AmpleSound instruments

  • and some HALion instruments like “A.X. Machina”

Those can trigger spikes much more aggressively.

But the important detail is:
The biggest problems usually start when monitoring is enabled.

Which makes this especially problematic for recording and live playing, because of course monitoring has to be active in order to:

  • hear the instrument in realtime

  • and properly record/play virtual instruments.

Without monitoring enabled, the system is often much calmer.

Another very strange observation:
Even with a completely empty Cubase project, I can already see noticeable realtime meter activity.

I mean:

  • no tracks

  • no plugins

  • no VST instruments

  • nothing loaded at all

Just opening an empty project and enabling the realtime performance meter can already show peaks around 20–30%.

That is what makes this so difficult to understand.
Because at that point there is practically no real audio workload yet, and still Cubase already shows noticeable realtime activity/spikes.

18

My motherboard is a Gigabyte Z690 UD DDR4.

Interesting that you mention ASUS and Thunderbolt, because I increasingly wonder whether some combinations of:

  • motherboard vendor

  • chipset behavior

  • USB/Thunderbolt implementation

  • drivers

  • and Windows 11 scheduling

may influence Cubase realtime behavior much more than expected.

What makes my case strange is:
I already see realtime meter peaks even on completely empty Cubase projects:

  • no tracks

  • no plugins

  • no instruments loaded

Just opening an empty project can already produce noticeable realtime spikes around 20–30%.

As soon as monitoring and VST instruments come into play, things get worse very quickly.

The especially frustrating part:
Other DAWs on the SAME system behave much better.

So I don’t think this is simply “weak hardware”.

Your experience with the same interface behaving differently between:

  • old Win10 system

  • and newer Win11/ASUS system

is actually very interesting, because it shows how strongly platform/driver interactions may influence realtime audio performance.

19

I’m not sure if you were asking me based on proximity of your post, but both my new and old motherboards were ASUS. Current one is TUF GAMING Z890-PLUS WIFI LGA 1851 ATX, and the old one was X99-Deluxe (with the optional Thunderbolt II daughtercard). The new one has a more modern form of Thunderbolt support built-in, but that Thunderbolt is not backward compatible with Thunderbolt 2 on Windows. Thankfully, the MOTU 828x supports both Thunderbolt and USB2 (but I did have a lot of issues with USB initially, on both the newer and older systems, due to the cable supplied for that by MOTU being faulty).

20

Old, or wrong driver for your audio card?