Realtime Peaks and Crackles during Monitoring on modern Intel Systems

Cubase
21

I don’t have either of the examples you mention, but I definitely did see some major difference in this area on my older system. In particular, there were some Arturia instruments, like Pigments, where audio would breakup pretty early if playing polyphonically, and IK’s Hammond organ was just deadly, as were their tape emulation plugins.

Monitoring is almost always enabled on my system, at least while I’m working up arrangements, because of the preference that selecting an instrument track arms it for recording. I do have to explicitly turn on monitoring for audio tracks (vocals only in my case).

The key on monitoring is that the track gets placed in the real-time thread, rather than the ASIO Guard thread. Just to give some context, in my current project, running at 192 samples buffer at 96 kHz, and just sitting idle at the moment with a UVI Workstation instrument (Acoustic Samples Sunbird guitar) selected, here is what my performance meter looks like:

image
image409×148 1.99 KB

The three meters are in constant back and forth motion. (If I remember correctly, this behavior started on Cubase 14, though it may have been earlier – the key point being it wasn’t something observed prior to one specific update to Cubase.)

The ASIO Guard thread typically has a higher reading than the Real-Time thread on my system. (At the moment I don’t actually have much live in the project – Superior Drummer 3, the UVI/Sunbird and a UVI/Acoustic Samples GD-6 guitar, plus three audio tracks that were rendered from instrument tracks (two have IK ReSing extensions on them) and another audio track I just use as a count-in. No plugins on any of those. No Control Room inserts active, either.

In case it might be useful to compare settings, here is the Audio System page of my Studio settings:

image
image440×663 10.9 KB

The latency stuff reflects that I turned the sample buffer down to 192 samples today due to again having the issue where I was hearing static-type noise when I started Cubase on this project at 256 samples (and I haven’t had a reason to change it back yet since I’m not having any problems).

I think most of the other settings are defaults, with the possible exception of using the 64-bit floating point engine, having ASI-Guard set to Normal, and using the Steinberg Audio Power Scheme.

While I haven’t tried this specifically (or at least haven’t noticed it when I do start a new project), I know I do see meter activity, including the rapidly changing (within a small range) meter movements pretty much whenever I’m in Cubase. I also see the overload indicator come on a fair bit, even when there is nothing obvious, including no noticeable audio breakup. I do sense that there is some degree of fairly constant overhead (i.e. as suggested by the meter movements and levels with not much going on), but that it doesn’t follow that adding more multiplies it, and the meters can get up pretty high on my system before I start to hear issues in the sound. (And, if I get to that point, I can often just add a HALion Sonic track with nothing on it but with the focus, which forces a real-time thread, to get a bunch more mileage before audio breakup returns.)

I don’t know enough about Cubase innards to have a feel for what is going on when “nothing” is (obviously) going on.

The one other thought that came to mind is if there is any chance you are using Control Room inserts. I tend to turn mine on only when needing them, but they are Cubase-wide, not project-specific, so I have found it can be easy to accidentally leave some on – my key case is when working in headphones at night and using one of the Waves NX studio simulators, then having it still on the next day when I am working on my speakers and wondering why the sound is so weird. :slight_smile:

22

The OP covered quite a bit, but I did not see his audio interface into. Hopefully if NVIDIA, studio divers only.

23

One thing that may also be important in my case:

Years ago, when I mainly worked on mixing during my HOFA studies, I barely noticed any of these problems.

Back then I mostly worked with:

  • audio tracks

  • mixing

  • plugins

  • mastering work

But the problems became much more obvious once I started doing more:

  • realtime VST instrument playing

  • composing

  • live monitoring

  • virtual instruments

  • realtime input workflows

That seems to be where Cubase starts struggling much more heavily on my system.

What makes this even stranger:
Other DAWs on the SAME hardware behave significantly better for me.

For example:

  • Studio One

  • Ableton Live

  • Bitwig

  • Reaper

  • Samplitude

all behave relatively нормально compared to Cubase.

Yes, some very heavy plugins can stress those DAWs too, but the behavior is nowhere near as aggressive.

Cubase already shows noticeable realtime meter activity on empty projects before anything meaningful is even happening.

Meanwhile, right now in Studio One I can:

  • open EZKeys

  • load several plugins

  • enable monitoring on EZKeys

  • and things stay relatively calm.

I even tested Mixcraft recently, and interestingly that one behaved even worse than Cubase in my case. It started crackling very early even at larger buffer sizes.

So there are definitely huge differences in how DAWs behave on the exact same machine.

The frustrating part is:
From a workflow and composing perspective, Cubase is actually still my favorite DAW overall.

Especially for composition and arrangement work, Cubase has many things I really like.

So I would actually prefer to do most of my main work in Cubase — if the realtime performance issues could somehow be solved.

24

Perhaps a Cubase file somewhere along the line is corrupted? Maybe a corrupted session carried on to the rest of your sessions?

I had a bug with creating group tracks. They would be created deactivated. It happened after a crash.

I tried deleting perefrences and anything else I could think of.

The bug carried on to other sessions and even jumped from C14 to C15 when I switched from one to the other to see if the problem would go.

Eventually, after stopping using the corrupted session file, several restarts and RAM emptying, Cubace stopped doing this and went back to normal.

I know this is not ideal, but if you have a spare drive, try installing W11 and Cubase plus your audio card from fresh.

See if Cubase still behaves this way.

25

The difficult part in my case is that this is my productive work machine and rebuilding everything from scratch is not a simple weekend project anymore.

Years ago this was much easier because I used removable drive systems. I could simply swap system drives and test a fresh Windows installation relatively quickly.

Today, with NVMe drives mounted directly onto the motherboard under the desk in a tightly integrated studio setup, things are unfortunately much more complicated.

My whole studio is built around this machine, and reaching the system physically already requires partially dismantling parts of the setup.

On top of that:

  • many DAWs

  • huge plugin collections

  • libraries

  • authorizations

  • symbolic links

  • custom paths

  • audio routing

  • production tools

  • client-related software

all live on this system.

So rebuilding everything completely would realistically take weeks, maybe even months before the workstation would be fully operational again.

That makes “just reinstall Windows and test” much harder in practice than it sounds.

At some point in the future I may build a separate dedicated test machine or use an NVMe swap/removable solution again, but at current hardware prices this is unfortunately not something I can easily justify right now just because Cubase behaves this way.

26

You mentioned you tried LatencyMon, would you mind sharing the results after it running for 30 minutes?
Also, what specific audio interfaces have you used?

27

Regarding the audio interfaces I tested:

Most of the time I use a PreSonus StudioLive 32SC as my main interface/mixer.

I also tested:

  • Mackie Big Knob Studio Plus

  • IK Multimedia AXE I/O

  • PreSonus Studio 192

and several other interfaces occasionally.

The behavior changes slightly between interfaces and drivers, but the fundamental Cubase realtime peak problem remains across all of them.

What makes this especially interesting is the comparison with other DAWs on the exact same system.

For example:
Studio One runs MUCH better here under the same conditions.

I can load HALion with the same A.X. Machina preset and still play comfortably at low buffer sizes. CPU load rises somewhat of course, but it remains controllable and playable.

Cubase behaves completely differently on the same machine.

Also:
LatencyMon itself massively affects Cubase on my system.

With LatencyMon running:

  • Cubase becomes unstable very quickly

  • audio starts stuttering badly

  • realtime spikes explode

  • and I need at least a 1024 sample buffer before Cubase becomes remotely usable again

Even 512 samples still produces audio dropouts here while LatencyMon is active.

Meanwhile Studio One remains far more stable under similar conditions.

That is why I currently suspect this is not simply a “weak CPU” issue, but rather some interaction between Cubase, realtime scheduling, drivers, Windows 11, or how Cubase handles realtime monitoring and threads on this system.

28

I also attached/saved the LatencyMon results now, including the screenshot and the text report.

I still need to upload the text file properly to the forum, but maybe there is something
useful hidden in there that I may have overlooked.

So far, however, I personally could not identify one single obvious driver or process that fully explains the behavior.

CONCLUSION

Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:16:32 (h:mm:ss) on all processors.

SYSTEM INFORMATION

Computer name: DESKTOP-8N6I65K
OS version: Windows 11, 10.0, version 2009, build: 26200 (x64)
Hardware: Z690 UD DDR4, Gigabyte Technology Co., Ltd.
BIOS: F32
CPU: GenuineIntel 12th Gen Intel(R) Core™ i9-12900
Logical processors: 24
Processor groups: 1
Processor group size: 24
RAM: 130897 MB total

CPU SPEED

Reported CPU speed (WMI): 240 MHz
Reported CPU speed (registry): 2419 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

MEASURED INTERRUPT TO USER PROCESS LATENCIES

The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 714,0
Average measured interrupt to process latency (µs): 7,325609

Highest measured interrupt to DPC latency (µs): 709,30
Average measured interrupt to DPC latency (µs): 2,457953

REPORTED ISRs

Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 186,140141
Driver with highest ISR routine execution time: Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation

Highest reported total ISR routine time (%): 0,001503
Driver with highest ISR total time: Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation

Total time spent in ISRs (%) 0,002534

ISR count (execution time <250 µs): 986530
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0

REPORTED DPCs

DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 776,292683
Driver with highest DPC routine execution time: Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation

Highest reported total DPC routine time (%): 0,109981
Driver with highest DPC total execution time: Wdf01000.sys - Kernelmodustreiber-Frameworklaufzeit, Microsoft Corporation

Total time spent in DPCs (%) 0,145970

DPC count (execution time <250 µs): 2225527
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 232
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µs): 0
DPC count (execution time >=4000 µs): 0

REPORTED HARD PAGEFAULTS

Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: cubase15.exe

Total number of hard pagefaults 7527
Hard pagefault count of hardest hit process: 6112
Number of processes hit: 25

PER CPU DATA

CPU 0 Interrupt cycle time (s): 75,675247
CPU 0 ISR highest execution time (µs): 186,140141
CPU 0 ISR total execution time (s): 0,229502
CPU 0 ISR count: 698829
CPU 0 DPC highest execution time (µs): 776,292683
CPU 0 DPC total execution time (s): 19,444905
CPU 0 DPC count: 935340

CPU 1 Interrupt cycle time (s): 33,679815
CPU 1 ISR highest execution time (µs): 102,852005
CPU 1 ISR total execution time (s): 0,027708
CPU 1 ISR count: 1663
CPU 1 DPC highest execution time (µs): 445,705663
CPU 1 DPC total execution time (s): 0,172286
CPU 1 DPC count: 19838

CPU 2 Interrupt cycle time (s): 46,299466
CPU 2 ISR highest execution time (µs): 102,400992
CPU 2 ISR total execution time (s): 0,161641
CPU 2 ISR count: 9888
CPU 2 DPC highest execution time (µs): 764,796197
CPU 2 DPC total execution time (s): 2,646977
CPU 2 DPC count: 374339

CPU 3 Interrupt cycle time (s): 33,879741
CPU 3 ISR highest execution time (µs): 101,442332
CPU 3 ISR total execution time (s): 0,011409
CPU 3 ISR count: 27589
CPU 3 DPC highest execution time (µs): 224,327821
CPU 3 DPC total execution time (s): 0,659543
CPU 3 DPC count: 30287

CPU 4 Interrupt cycle time (s): 40,253542
CPU 4 ISR highest execution time (µs): 167,037619
CPU 4 ISR total execution time (s): 0,051935
CPU 4 ISR count: 125507
CPU 4 DPC highest execution time (µs): 316,608103
CPU 4 DPC total execution time (s): 3,587874
CPU 4 DPC count: 164061

CPU 5 Interrupt cycle time (s): 33,144555
CPU 5 ISR highest execution time (µs): 69,957834
CPU 5 ISR total execution time (s): 0,006289
CPU 5 ISR count: 395
CPU 5 DPC highest execution time (µs): 283,737081
CPU 5 DPC total execution time (s): 0,062760
CPU 5 DPC count: 7443

CPU 6 Interrupt cycle time (s): 32,426376
CPU 6 ISR highest execution time (µs): 103,751964
CPU 6 ISR total execution time (s): 0,036622
CPU 6 ISR count: 2310
CPU 6 DPC highest execution time (µs): 483,563043
CPU 6 DPC total execution time (s): 0,317045
CPU 6 DPC count: 40387

CPU 7 Interrupt cycle time (s): 33,741026
CPU 7 ISR highest execution time (µs): 11,002067
CPU 7 ISR total execution time (s): 0,004650
CPU 7 ISR count: 11733
CPU 7 DPC highest execution time (µs): 253,109549
CPU 7 DPC total execution time (s): 0,351895
CPU 7 DPC count: 13178

CPU 8 Interrupt cycle time (s): 36,791656
CPU 8 ISR highest execution time (µs): 109,238942
CPU 8 ISR total execution time (s): 0,020346
CPU 8 ISR count: 37130
CPU 8 DPC highest execution time (µs): 758,352212
CPU 8 DPC total execution time (s): 1,756776
CPU 8 DPC count: 114252

CPU 9 Interrupt cycle time (s): 33,829335
CPU 9 ISR highest execution time (µs): 65,898305
CPU 9 ISR total execution time (s): 0,003730
CPU 9 ISR count: 214
CPU 9 DPC highest execution time (µs): 365,157090
CPU 9 DPC total execution time (s): 0,346780
CPU 9 DPC count: 36103

CPU 10 Interrupt cycle time (s): 33,545319
CPU 10 ISR highest execution time (µs): 42,108309
CPU 10 ISR total execution time (s): 0,005207
CPU 10 ISR count: 298
CPU 10 DPC highest execution time (µs): 259,935924
CPU 10 DPC total execution time (s): 0,238524
CPU 10 DPC count: 25025

CPU 11 Interrupt cycle time (s): 32,665173
CPU 11 ISR highest execution time (µs): 8,270360
CPU 11 ISR total execution time (s): 0,001410
CPU 11 ISR count: 3919
CPU 11 DPC highest execution time (µs): 175,451013
CPU 11 DPC total execution time (s): 0,135453
CPU 11 DPC count: 7055

CPU 12 Interrupt cycle time (s): 41,773119
CPU 12 ISR highest execution time (µs): 145,548987
CPU 12 ISR total execution time (s): 0,038577
CPU 12 ISR count: 66773
CPU 12 DPC highest execution time (µs): 754,454733
CPU 12 DPC total execution time (s): 3,992472
CPU 12 DPC count: 338314

CPU 13 Interrupt cycle time (s): 34,614682
CPU 13 ISR highest execution time (µs): 32,881769
CPU 13 ISR total execution time (s): 0,003225
CPU 13 ISR count: 204
CPU 13 DPC highest execution time (µs): 752,526664
CPU 13 DPC total execution time (s): 0,675102
CPU 13 DPC count: 82247

CPU 14 Interrupt cycle time (s): 34,582969
CPU 14 ISR highest execution time (µs): 26,147995
CPU 14 ISR total execution time (s): 0,001265
CPU 14 ISR count: 78
CPU 14 DPC highest execution time (µs): 252,638280
CPU 14 DPC total execution time (s): 0,107734
CPU 14 DPC count: 11837

CPU 15 Interrupt cycle time (s): 32,401438
CPU 15 ISR highest execution time (µs): 0,0
CPU 15 ISR total execution time (s): 0,0
CPU 15 ISR count: 0
CPU 15 DPC highest execution time (µs): 165,545267
CPU 15 DPC total execution time (s): 0,019880
CPU 15 DPC count: 1807

CPU 16 Interrupt cycle time (s): 14,723118
CPU 16 ISR highest execution time (µs): 0,0
CPU 16 ISR total execution time (s): 0,0
CPU 16 ISR count: 0
CPU 16 DPC highest execution time (µs): 183,634973
CPU 16 DPC total execution time (s): 0,043233
CPU 16 DPC count: 5240

CPU 17 Interrupt cycle time (s): 11,375118
CPU 17 ISR highest execution time (µs): 0,0
CPU 17 ISR total execution time (s): 0,0
CPU 17 ISR count: 0
CPU 17 DPC highest execution time (µs): 254,071104
CPU 17 DPC total execution time (s): 0,038180
CPU 17 DPC count: 4132

CPU 18 Interrupt cycle time (s): 10,223785
CPU 18 ISR highest execution time (µs): 0,0
CPU 18 ISR total execution time (s): 0,0
CPU 18 ISR count: 0
CPU 18 DPC highest execution time (µs): 190,722199
CPU 18 DPC total execution time (s): 0,018634
CPU 18 DPC count: 1607

CPU 19 Interrupt cycle time (s): 9,100345
CPU 19 ISR highest execution time (µs): 0,0
CPU 19 ISR total execution time (s): 0,0
CPU 19 ISR count: 0
CPU 19 DPC highest execution time (µs): 145,372468
CPU 19 DPC total execution time (s): 0,023689
CPU 19 DPC count: 2084

CPU 20 Interrupt cycle time (s): 13,383050
CPU 20 ISR highest execution time (µs): 0,0
CPU 20 ISR total execution time (s): 0,0
CPU 20 ISR count: 0
CPU 20 DPC highest execution time (µs): 659,017776
CPU 20 DPC total execution time (s): 0,047053
CPU 20 DPC count: 4796

CPU 21 Interrupt cycle time (s): 9,957623
CPU 21 ISR highest execution time (µs): 0,0
CPU 21 ISR total execution time (s): 0,0
CPU 21 ISR count: 0
CPU 21 DPC highest execution time (µs): 166,002480
CPU 21 DPC total execution time (s): 0,028796
CPU 21 DPC count: 2527

CPU 22 Interrupt cycle time (s): 10,084668
CPU 22 ISR highest execution time (µs): 0,0
CPU 22 ISR total execution time (s): 0,0
CPU 22 ISR count: 0
CPU 22 DPC highest execution time (µs): 143,990492
CPU 22 DPC total execution time (s): 0,026384
CPU 22 DPC count: 2414

CPU 23 Interrupt cycle time (s): 9,606423
CPU 23 ISR highest execution time (µs): 0,0
CPU 23 ISR total execution time (s): 0,0
CPU 23 ISR count: 0
CPU 23 DPC highest execution time (µs): 219,961141
CPU 23 DPC total execution time (s): 0,021510
CPU 23 DPC count: 1446

image
image1297×993 54.9 KB

29

Did you already try…Turning of all power saving (cc3 c6 etc except c1) and all efficient cores in the bios? And disable core parking and cpu throttling? So run your performance cores on a fixed frequency anywhere from 4.0 to 4.9 ghz? Exactly how high you can set it is up to your cooling. you can use proces lasso to set all this too, from windows. And throttlestop to set a fixed freq.

30

Yes, we already tested disabling E-Cores and several BIOS-related optimizations.

The only thing I have NOT really tested yet is forcing a fixed CPU frequency permanently.

However, honestly, that also feels like the wrong direction to me.

Because if Cubase only works properly when I:

  • disable modern CPU features,

  • force constant high clock speeds,

  • and effectively turn my workstation into a “Cubase-only optimized machine”,

then something is fundamentally wrong somewhere.

Especially because the other DAWs I tested do not require this behavior on the exact same hardware.

Studio One, for example, remains very playable here under the same conditions.

And this is also why the situation is so frustrating for me:
I actually LIKE Cubase very much.

For mixing, editing, arranging, composing tools, visual workflow, organization, colors, and many production features, Cubase is excellent in my opinion.

When I mainly worked on mixing in the past, I barely noticed these problems.

The issues became severe once I moved more into:

  • realtime composing

  • virtual instruments

  • monitoring

  • live playing

  • arranging while recording

At that point Cubase started becoming extremely sensitive on my system.

Right now it feels like I could still use Cubase as a mixing DAW, but not reliably anymore as a realtime composing/tracking environment.

And if the only solution is to permanently cripple or heavily reconfigure the entire system specifically for Cubase, then unfortunately I would eventually have to reconsider continuing to invest in it long term.

31

Ah, sorry to hear that, yeah, that sounds extremely complicated.

I hope you get to work this out.

32

I agree and I am not defending Steinberg, just trying to help you to get a working system. I have always run my daw computers on a fixed freq.
Switching cpu freq can work faster or slower depending on motherboard but also bios versions. Maybe even the running program can influence it.
But there is really no downside to running fixed, the difference in power used is maybe 10W. That might be good for a laptop on battery, but not for a desktop. If this fixes it, you finally know the issue/cause.

33

Make sure you connect the USB2 audio hardware to USB2 ports only.

34

Oh yeah, my MOTU freaks out if it’s plugged in to USB 3.

35

Just to add:
I already connect my audio interfaces almost exclusively to USB2 ports.

I generally avoid USB3 for audio hardware because in my experience USB3 often introduces additional instability or interference with some audio devices.

For example, with my PreSonus StudioLive 32SC mixer, I noticed that on USB3 ports the device sometimes was not reliably reachable anymore in Universal Control until I unplugged and reconnected it.

On USB2, however, it behaves much more reliably and consistently on my system.

36

This difference in work profiles is really just the “nature of the beast” in the sense that, all things being equal, live virtual instruments are way more demanding on the CPU than audio tracks. And, of course, while you’re in the arranging and tracking stages of your project, you’ll at least need the virtual instruments you are working with to be live. If there are parts you’re finished with on that front, you can always render them to audio or freeze the virtual instrument tracks to at least take those specific instruments’ CPU demands out of the overall mix of demands. While I mostly don’t need to do that on my current system, it was absolutely mandatory on my previous system, and, while I do a degree of “mixing as I go” (mostly to make work mixes for checking in my car from time to time), I still do tend to render all virtual instrument tracks to audio before starting my real mixing process. (I also adjust bus structures at that point since my arranging/tracking bus structure is generally pretty flat, and my projects are often sufficiently different that I don’t use project templates.)

Yes, this would seem to be the aspect that is curious. Of course, some DAWs will be more efficient than others in different areas, and these newer DAWs won’t have as much legacy code as Cubase (and other older DAWs that haven’t been significantly rewritten, as opposed to just enhanced, over the decades). My main experience had been with Cakewalk SONAR prior to switching to Cubase back around V10.5. When I was using both DAWs in parallel, I found they both had quite similar performance limitations on my system of that time (the one I replaced last year). However, I did actually find Cubase to give me at least slightly more mileage on the virtual instruments front, though my main reasons for switching to Cubase related to workflow efficiency in some areas where I spent a large proportion of my overall time on a project.

One thing worth doing is making sure your tests are truly apples-to-apples. For example, if you’re using the 64-bit floating point audio engine in Cubase, make sure you also are in each of the other DAWs (assuming they support that). If others support only 32-bit floating point (no clue if others have that limitation), then you might try switching to that in Cubase for a more accurate comparison. (That’s not saying you should switch to it for real use, just to make sure the comparison is fair.)

Also, with respect to the tests themselves, it is important to make sure that they are doing the identical thing in each DAW, including using the same virtual instruments and plugins, same audio interface, sample rate, and buffer settings, etc.

Did you check the audio settings I posted above? ASIO Guard settings are, in my experience anyway, especially important in Cubase. That least components that don’t need to be on the real-time thread go elsewhere, potentially getting more mileage out of the system before reaching CPU-bound limitations. Any tracks being in live monitor mode will, of course, need to be on the real-time thread. But unless your recording multiple musicians/singers/virtual instruments at the exact same time, that is probably only going to need to be one or two tracks – mostly one, but, for example, if recording two parts at the same time via a keyboard split or multiple keyboards, then it could be more.

This seems odd. One other thing to check in the audio settings I posted is if you’re using the Steinberg power scheme. If not, I’d suggest at least trying it to see if it makes a difference. (It does require restarting Cubase after changing the setting.)

I don’t have EZkeys, so I don’t have any feel for how heavy duty, or not, it might be. However, I wouldn’t think it would be super heavy if it is anything like EZdrummer or Superior Drummer. But, unless there is something super heavy in the “several plugins”, I wouldn’t expect any DAW to have issues with this on a semi-modern system. (I did look up your CPU, and it is an older generation compared to my i9-285k, with fewer physical cores, and apparently not as optimal overall for DAW-type uses. But it’s still WAY more modern than my older i7-5280k, and I wouldn’t even expect this type of scenario to have been a problem on that.) Of course, for the “apples-to-apples” consideration I mentioned above, it is important to make sure that the “several plugins” you’re using here are the exact same ones as on Cubase.

I’m a bit curious about the “RELATIVELY calm” (emphasis added). I’d think that scenario should be super minimal impact. (Then again, I have no experience with EZkeys, nor have you defined what the “several plugins” were.)

One thing that isn’t clear to me on this thread, and part of why, in my initial response here, I qualified that the crackles thing I experience is something that only occurs at times, and right at the start of working on a project, and is cleared up by changing my ASIO sample buffer, really to any different value most of the time, is the difference between “realtime peaks” and “crackles” in your scenario. Cubase’s performance meters aside (they seem to be all over the place – they’re always in motion on my system – but that doesn’t mean I’m experiencing any audio crackles), are you experiencing audio crackling in Cubase in the simple scenario you outlined above for Studio One? If so after just starting a session, if you tweak your ASIO buffer size, do you still experience it? (And, if not, what about if you then set it back to where it originally was.)

Just to make sure the experience I was relating is clear, other than in cases where my system truly is overloaded (generally when I’m mixing and mastering, which I do in the same project file, with plenty of submix buses and a lot of demanding plugins) I only experience audio crackling right away in starting up Cubase and either just letting it sit or playing a project. When that happens, I change my ASIO sample buffer size, and the crackling goes away for the remainder of my session, which may be many hours. So it would seem to be something that happens either in Cubase’s initialization stage or in any project-specific initialization (e.g. if my interface is set to another sample rate when Cubase loads my project, then it would have to change the driver’s sample rate to match the project). I may see the red peak light up somewhere during the course of the session, but I’m not hearing any audio artifacts (except in the “truly overloaded” scenarios).

This also seems a little suspicious to me, also making me wonder about trying the Steinberg Power Option if you haven’t tried it.

This one struck me as suspicious. Is this with a simple project, or are there a bunch of huge virtual instruments loaded in the Cubase project you’re running? You said you had 128 GB of RAM, which would seem plenty for even some pretty big projects (I only started exceeding comfortable levels on my old 16 GB system when I started using PianoVerse as my main virtual piano). If Cubase is really having to load a lot off disk, unless maybe this just means one time on startup (maybe try starting LatencyMon after you’ve already gotten Cubase full loaded and whatever you’re using in the project in question?), then something seems seriously wrong. I think you mentioned having loads of plugins (I do as well), but that should really only be a factor on any initial scanning, with subsequent loads only being for what is needed in the project.

Yeah, I’d agree with this thought. FWIW, I did NO special tuning at the BIOS level on my current system. (On my older one, the only one I had to do was to enable the Thunderbolt II daughterboard.) You do have an older generation i9 than mine, and a different brand motherboard.

37

@dimugi
Do you have anything inserted in the control room? That would be always active if you switched CR on.

38

My current motherboard is ASUS ROG STRIX Z890-F GAMING WIFI, CPU is Ultra 9 285K.

My audio interface is an UAD Apollo with TB 2 interface. The motherboard has onboard TB and it works well.

In the BIOS is an option to activate / deactivate TB 5 support and it’s deactivated in my setting. Did you check that option on your motherboard ?

39

Hi @dimugi,
There’s a lot in this thread and I’m not going into that because I can assure you others and yourself are definitely better on troubleshooting that than me.

But some stuff (excuse if I missed it) that you haven’t talked about or confirmed trying concerning some settings:

——> Multiprocessing always ON in Cubase and OFF in HALion?
Lowered the number of voices used by the heavy instruments like AX?
Stream it totally/mostly from RAM.

ASIO Guard set to High.
Audio Priority to Boost.

Also:
Constrain Delay Compensation when you’re playing/tracking?
Suspend VST3’s processing?

/Matsie

40

To be honest, I’ve never even attempted to use my MOTU 828x with Thunderbolt on my new system. The specs for my motherboard say it has a Thunderbolt 4 port, and when I was researching components for my current computer, the information I found was that Thunderbolt 4 was not backward compatible with Thunderbolt 2 on Windows. Just checking again now, to see if there is any update on that front, the information I found suggests that is still true. I note on the UAD site, too, that they specifically say, “Windows systems with Thunderbolt 4 are not compatible with Thunderbolt 1 or Thunderbolt 2 devices.” Are you sure your Apollo is TB2? Their newer devices do have more modern Thunderbolt interfaces. (FWIW, when I got the 828x for my older system, I was expecting there to be a benefit of Thunderbolt 2 over USB2 for performance, but I later found out that the MOTU 828x performance should be the same over TB2 or USB2. The reason I tried using on USB2 at one point was because, after a power outage, my Thunderbolt stopped working – motherboard battery had died, though I didn’t realize that at the time – so I was trying USB2 as a backup, but it was very unreliable, which I finally figured out was a bad cable when trying to use it on the new system – but I later found I just had to reenable the TB2 in the BIOS after any power outages.)