Check DPC latencies (LatencyMon), disable VBS in Win11 (performance hog).
It could also be a problem of the VST/VSTi.
Disable energy saving, CPU core parking.
Use the proper energy profile in Windows (highest or ultimate performance).
Tame background processes / system activity (O&O Win10 Shutup).
Prioritize background processes (not foreground processes), might help to reduce the amount of context switches by using a fix and a little longer quantum for the process scheduler.
If you have nVidia GPU, check for threads in this and Steinberg Cubase forum about powermizer tool to deactivate energy saving on nVidia cards (only recommended for desktops, not laptops) plus a few nVidia driver settings according to the guy on the Steinberg forum.

Well, that was quick, I'm pleased for you. Have fun with the ‘new’ setup

A further observation for however is interested:

The crackles stopped in my DAW completely, but I still had a little crackle once every 5 minutes when watching youtube. Also LatencyMon had a little hickup every 10 minutes or so, or at least every 10 Minutes the red message appeared (although the sound was alright all the time).

Today I removed the 4090 and connected the onboard GPU instead. Now all crackles are gone completely and the LatencyMon stays green all the time and I have latency in the low teens most of the time.

All the other settings in the BIOS were totally irrelevant: EIST, Turbo boost, Performance mode, Ram profile, Intel Speed shift, Hyperthreading and so on, no matter if I switched it on or off, it didn't change glitches or crackles or Latency as far as I could see.

Had similar issues.
Although LatencyMon didn't report any big peaks of DPC latency I had occasional audio drops.
This came from the nVidia card.
I had to disable power saving functions for my RTX 4070 using a tool from a russian dev called "powermizer"
and using 2 settings in the nvidia driver.
And the two settings were
- energy saving -> prefer max performance
- threaded optimization -> on
I found this information on Steinberg Forum and since then, no issues anymore.

Possibly for two reasons: a) RME interfaces transmit more channels, with all channels always being transmitted regardless of whether they are in use or not, and b) RME drivers achieve lower latency, which means the computer’s configuration needs to be perfectly aligned, and USB transfer modes must operate flawlessly.

As for Apple, their track record with USB has been less than stellar. There have been hardware and driver issues that Apple initially ignored or delayed addressing, attributing them to "USB 3rd party devices." These issues were only resolved in the drivers after approximately three-quarters of a year, following coverage in the trade press. A few years ago, during the introduction of a new communication chip, USB implementation problems arose, which could only be resolved by purchasing Thunderbolt docks with standard USB3 chips. Despite Apple’s relatively narrow hardware lineup, it is by no means a "perfect world" either.

However, this issue is not exclusive to RME. For decades, companies have offered turnkey systems that are rigorously tested for professional audio (and video) applications—not just for RME components.

Take a look at device lists that rank how laptops perform in terms of DPC latency:
https://www.notebookcheck.com/DPC-Laten … 375.0.html
In this area, only a few systems fall significantly below the critical threshold of 1000 microseconds, which is necessary to handle near-realtime demands for audio processing. Staying well below this limit is essential to avoid audio dropouts under high loads or with smaller buffer sizes.

The issue extends to desktop systems, which present even greater hardware diversity and driver variations.

Hardware must be paired with drivers that don’t occupy CPU cores for extended periods. Audio processes waiting for cores to become available shouldn’t face excessive delays, as this can lead to audio dropouts. While larger buffer sizes can partially offset this, they also increase audible latency for audio transport over digital interfaces (USB, FW, TB).

No mainstream operating system is a real-time operating system. To ensure data integrity, drivers must not be interrupted by the OS’s process scheduler; only the driver itself can release the CPU after its programmed interval. Unfortunately, not all driver developers adhere to the necessary programming conventions. Since audio is a niche market, these aspects are rarely tested. Manufacturers are primarily motivated by benchmark results, where everyone aims to excel. This often leads to longer CPU occupation times for better scores. While this is not an issue for benchmarks or standard applications, it becomes critical for real-time audio processing.

Fortunately, many users don’t encounter major issues, but with the wide variety of hardware combinations, it’s not guaranteed that everything will align perfectly for real-time audio demands.

This longstanding issue is why, despite increasing CPU performance, companies still specialize in providing turnkey solutions for audio processing. Professional recording studios don’t have the time or resources to address these challenges themselves.

Even for Apple, audio processing remains a niche segment. Otherwise, past issues would not have occurred. Unfortunately, manufacturers don’t conduct thorough testing in this area. For Apple, all recording interfaces are considered "3rd party interfaces" by default, instead of recognizing the reality that USB is a multi-purpose interface. Apple also has a responsibility to ensure that its drivers and USB controllers adhere strictly to USB standards and to resolve issues promptly.

Regarding DPC spikes, I haven’t tested it myself, but I frequently read that nVidia GPUs can cause issues for audio processing. AMD cards may not exhibit these problems to the same extent.

In summary, audio processing with near-realtime requirements can be a challenging field. Even powerful CPUs and good benchmark results are no guarantee of excellent audio processing performance.

For maximum reliability, consider investing in a turnkey system for audio processing from a specialized company.
This all is not RME specific...

There are already companies which are using profiles in the BIOS for different purposes.

A few days ago, I stumbled over this:

https://www.xmg.gg/en/xmg-studio-x/

I've been meaning to dig deep into this topic with either support or the forum.

I'm surprised to hear that you have totally overcome your issues in a system running an Nvidia card & an RME interface. Could you link to the powermizer app you're referring to? I can't seem to find it. I can corroborate that the two official settings you mention in Nvidia control panel do help, but they don't solve the problem entirely.

Just as a preface, on all of my systems I disable every power saving feature (ie C-States), and wireless connectivity (ie Bluetooth, Wifi). Additionally I run Windows Pro for Workstations, utilizing the Ultimate Performance power plan. I tweak said power plan as well, pegging the CPU minimum/maximum processor state to 100%, and disable USB/PCIe device sleeping.

I've personally owned 7 different RME USB interfaces (FF UC, FF UCX, FF UCX II, FF UFX+, MF XT, DF USB, DF Dante), and have tested said interfaces across 10+ AMD/Intel chipsets. I have found that there is a 100% guarantee that you will get USB diagnosis errors if there's an Nvidia card in your system. I've tried every possible BIOS setting, OS modification, cable, and USB PCIe add-in card. Eventually, these USB diagnosis errors result in a BSOD, or full audio-system failure. It's worst for the USB 3.0 interfaces, but still occurs with the USB 2.0 interfaces at a slower rate.

The only "solution" I've found regarding systems with Nvidia GPUs is using RME's PCIe cards, with one exception being the UFX+ over Thunderbolt, which is essentially PCIe. Of course, with the PCIe drivers USB diagnosis errors don't exist... but I put solution in quotes because I still get crackles as mentioned by dgstr. To this day, there's a 5% chance when I open any app that hooks a WDM device it comes through as garbled crackly audio. Restarting the app resets this chance, and fixes the issue 95% of the time. In-regards to ASIO performance - with a buffer below 128 I get frequent crackles at random intervals, at 128 & above I still get crackles, but infrequently. These behaviors are identical in both my TRX40 AMD system, and my Z790 Intel system. Both equipped with HDSPe MADI FX cards & RTX 40-series Nvidia GPUs.

The common denominator for these issues is definitely Nvidia GPUs. I personally haven't tested AMDs dedicated GPUs, but that's because for me and many others, they simply aren't a real option. In my case I have a main rig & a capture rig. In my capture rig I heavily utilize Nvidia's video encoders, which are best in-class, and widely supported. My main rig quadruples in workflow for gaming, music production, video/photo editing, and software development. In both systems, using integrated graphics is a laughable suggestion. Thus, the best solution that I've found for my main rig is multi-booting Windows, with one boot dedicated to music production where the Nvidia GPU is entirely disabled.

The situation is more complex than "other brands don't have this issue", but there is some truth to it. With both Apollo & Focusrite USB interfaces I don't get BSOD or full audio-system crashes. I still get crackles with ASIO, and have to increase the buffer size. But that's a massive improvement compared to full-system failure. I have to imagine that RME could introduce a mode or option that would increase leniency at the expense of delay. But I get that these interfaces were specifically created for real-time audio production, so the easy answer is "use integrated graphics".

It's a shame, for those who have tried multiple brands, you know as I do that RME is head and shoulders above the rest. And these interfaces are extremely useful for many workflows, not just real-time audio production. Nvidia is by far the most popular GPU manufacturer, so it seems crazy to bar such a large user-base from effectively utilizing a majority of RMEs interfaces.