Turning off hyper threading (AMD version) made no difference for me. I tried with a i9-9900K before that, and still spikes.
Im using Mac. I have a RME Fireface (using firewire) as my main on a intel mac. I have also a MOTU with thunderbolt with my Macbook Air (arm). It works stable with a 192 sample buffer at 44.1 Khz. And it works better with C12 than C11. And that is more or less the same usable latency that I have had for about 20 years.
1 Like
Actually, tried this morning M1 Mabook Pro 13, 16GB RAM, with 44.1k using the Duet 3 interface and it wasn’t spiking to overload, but the meter was still a bit jumpy. Not as bad though, so at least that’s an improvement! But it feels like being on the edge, anticipating it spiking.
It is not really a big deal that it is jumpy. The only thing that matter if it underrun or not. That is jumpy is due to that the system adjust the CPU frequency. It is a problem when it does not adjust up the frequency fast enough and then you get spikes. (One of the reasons, there are of course other ways to get spikes too)
Ok, I thought that this was obvious: the issue is the popping crackle that comes with the spike overloads. I’m not sitting in front of my screen, complaining about the DAW because of a jumpy meter etc 
Update: I used the Apogee Duet 3 for a while today, for the first time, and no overload spikes as yet! I’m also using the PC case front USB (I never usually use that one). Do you think specific USB ports matter? Just another variable to wonder about maybe.
I just have the overload problem of Disk Cache when cycling.
That is another issue, which others seem to have: Disk cache overload in cycle mode - Cubase - Steinberg Forums
Some machines have different USB controllers on different ports, and than it matters.
1 Like
I just ran into this issue (on Nunedo, not Cubase), latest version 12.0.52 on MacOS. Was impossible to work on an almost empty project.
Got somewhat better once I disabled/deleted various inserts in the control room, but what restored sanity was removing my unused StereoIn track (deleting it in audio connections/input). It exists in most projects by default so we don’t pay much attention to it. But apparently it can still cause CPU spikes.
Your mileage may vary. If you read the various threads on this issue, it’s clear that various folks had success with seemingly random actions which didn’t help others at all (the same could be true for mine here). So there are lots of data points, but no good correlation to cause/effect. What really is missing is some sort of log info or advanced info dialog that shows you what’s causing these CPU spikes. Then we could narrow this down much faster and much more predictably.
2 Likes
Thanks man! This worked for me 