Thanks @MattiasNYC I hope I get past it too, it’s driving me crazy.
Yes, latest firmware on SSDs.
I’m in touch with Gigabyte but nothing they’ve suggested has worked so far, including on which TB port to use (there are 2). But I haven’t ruled out the Quantum interface being the problem. This is because I also got problems with playback dropouts with the same project files with using my MacBook Pro with the interface.
I will try with my USB 2.0 interface tomorrow and see what happens.
Could my project files just be corrupt? Is that even a thing?
In the last month, I’ve worked on 2 projects, but used an iMac, MacBook Pro and now PC. Three different drives and folder setups etc. Perhaps Cubase doesn’t like the fact it has been moved about and on different SSDs.
With one of the projects, I get terrible disk cache spikes when cycling a part of one of the projects. The audio seems like it can’t keep up. It misses a beat and doesn’t quite restart at the right place when the playback gets to the beginning of the cycle. However, when I widen the cycle to encompass more music, the disk spikes go.
Disabling BT and network card did nothing either.
So tomorrow, I will try using a different audio interface and having a look at HWinfo64. Thanks for that suggestion.
Oh, yes, I get the Apple thing and agree. Which is why I really wanted to begin going down the PC route and have the possibility to upgrade parts and just have a really powerful system for all kinds of projects, including my tv/film music orchestral tracks, which is heavy on resources. I guess that is why, as you say, it is up to us to sort things out. I’m really enjoying the freedom and power of the system. Just need to sort this out
@Brian_Roland thanks for your suggestion about the netword cards. I’ve disabled them but that didn’t resolve the overloads on idle nor dropouts on playback. However, I seemed to have missed the link you sent, with Steinberg’s recommendations!
I disabled AMD Cool ‘n’ Quiet and a Booster setting in BIOS, and it seems to have resolved it…for now. Fingers crossed.
This same reasoning “check the NIC/disconnect the NIC” has been rolled out for many years. I Can find comments that say this in 100s of threads, but this isnt the cause of the particular issue here.
There have been some odd attempts by steinberg over the years to manage the issue to where it is blamed on other vendors, poor systems administration, etc, but in the end this ASIO/overload issue is related to a fundamental problem that I think will either 1) force steinberg to loosen up their DSP standard or 2) force steinberg to be honest that their DSP standard can no longer be met on a majority of modern parallel compute platforms.
Well just to update in my particular case: removing Norton, disabling network cards, using AMD instead of nVidia GPU all seemed to help. I’m no longer getting the spikes.
However, I’d like for the network card to be used as I am thinking of streaming some of my studio work live and would need internet for that.
Hello everybody, I’m the OP.
I’m sorry I did not keep up with the thread and the many considered and thoughtful contributions. I’m maxed out on my day job, always knackered and struggle to find the time and energy to do the music-making stuff. I barely go into my personal email more than once or twice a month.
Anyway, many thanks for all of the contributions.
I am coming back to this issue now as I have a 4-day weekend so … let’s make some music (or at least try!)
Of course the issue was never solved. And at nearly 2am I’m p*ssed off at Cubase cos frankly it feels like it’s just a complete crock of ****.
Clearly (well, it seems clear to me, but I’m a bit drunk and maybe I’m wrong) there are 24 “thingies” available (“things” here are maybe cores; I’m a Java dev not a computer geek but the gist of it seems clear enough). Cubase chooses it seems to use (up to 100% of ) 2 of the 24 that are available (to be fair, it does seem to use maybe 5-20% of the rest), and it seems it pukes when either of those 2 get maxed out. Is my read correct? I could be wrong but it looks pretty clear.
If this is the case, is it a Cubase issue? Do other DAWs do this better?
This seems on the face of it (caveat: maybe I’m wrong) to be mental, almost a mentally retarded use of CPU resources. If there is no way to fix it (settings/config etc), and another DAW does it better, I’m off.
Well, after my previous post I went into the bios and disabled SMT (apparently aka Hyper-threading) and just now launched Cubase and of course … it crashed.
I have been looping the same 28-bar section now for about 10 minutes, and it has not crapped out on me once. This is auspicous. Previously, I think about every 30 seconds I would get the dreaded “CPU overload / Dropout detected” dialog box, but I have not had it once. I am scared to be hopeful. But maybe … just maybe …
Bit of a bummer as I need hyperthreading to use docker on windows (I think). But I suppose I can just re-enable it in the bios when I’m going to use that.
I was about to submit the post when I got the dialog box. Uck. But… still maybe it’s better than it was.
Hi, thanks for the advice but I’m not keen on doing that, at least not now. I could end up in an even worse situation.
My major concern right now is the possibility fundamentally Cubase is flawed - it looks like it is unable to distribute the processing load across the cores that are installed on the computer.
I could be wrong. Maybe it’s something peculiar to my setup. But I need to investigate other DAWs as it’s just too much of a PITA to be constantly getting these dialox boxes popping up. You have to cancel the f*cking thing before you can do anything. Such a PITA. I’m not even using that many channels.
It could be that there is a particular plugin at fault; if so Steinberg should be making it easy for us as users to see what it causing it, or what is likely to be causing it. Because if they don’t - if they take the position that “it’s not our problem - it’s not us, it’s the 3rd party making the plugin” the risk for Steinberg is we really don’t care and will not hang around to find out; we’ll ultimately probably just give up and switch to a different DAW. TBH I think Cubase is probably the only reason I’m even on Windows. I’d like to ditch Windows entirely and move to Linux, and I see Dash Glitch switched from Cubase to Reaper.
Yeah, I am yet to get my head around that issue, I have a very powerful computer and sometimes I am getting headaches for no reason. I usually do a fresh clone from a saved Windows/Cubase etc. and all is back to normal. Why? No idea…All I know is that the more I work with Cubase, little problems start amounting to the point where pops and clicks make the program unusable.
Yeah, I know people switching to Reaper.
For better or for worst, I can’t ditch Cubase. It has so many incredible features that I can’t give up.
I tried to work with Studio One once, and it was so very alien to me…
I do post production and generally my load is relatively evenly spread within the mixer. By this I mean that the longest and most processing heavy load is likely going to be for example a dialog track with for example denoising on it, followed by dynamics and some sort of speaker emulation, after which it goes through the rest of the path which contains a bit more processing, and in parallel with that maybe a reverb off of a send going into the same target path (groups and outputs). But that’s not really that heavy relatively speaking, and most of my work is really about more tracks rather than heavier plugins or longer chains.
So basically what I’m saying is that if you have for example one really heavy VSTi with a bunch of processing after it and with processing on your master then that creates a long and heavy signal chain just off of that one source (VSTi). The question is if that processing can be distributed across more than one thread, and I think the answer is that a lot of the time it’s not possible if you’re looking for close to realtime performance. The reason is that before you calculate the reverb after that VSTi you need to calculate the sound output of the VSTi, so things have to happen in order.
(As a side note: The ‘boxes’ you see in Task Manager’s performance view are threads. Each core gets two threads with the Ryzen 5900X.)
Now, in addition to the above what complicates things is if you record enable tracks. I think that changes some things in some situations. And then on top of that you have different options for using ASIO Guard or not, different buffer settings, multicore processing on/off etc.
All of those things make a difference in how Cubase and Windows will work all of that out. So really what you’ll need to do is look at what your project is like in terms of signal chains, and then try out different settings to see if the load on CPU cores changes. For example, I’ve tested it on my setup (same CPU) and it clearly is a very big difference between a parallel load and a serial one. If I have 5 heavy plugins on one audio track and then have that track go to a group, and on that group I add the same 5 plugins, then the load on one core goes up significantly. But if I instead take the one track with 5 heavy plugins and duplicate the track so that the load is now in parallel that won’t happen.
There’s something not quite right with your setup , Cubase distributes pretty evenly with no peaks here . Have you run latency Mon to check what causing the spikes ?
Latency mon shows a very stable background . if i was you i would run Latency mon in the backgorund while you are launching Cubase so you can see whats cuasing the Cpu usage
Mattias, yes I see what you’re saying.
It could well be that channels are distributed amongst threads, and an uneven load on one channel’s signal path necessarily results in a an uneven load amongst the threads.
I think this is what you are saying. It sounds plausible; if so the implication would be that all DAWs suffer from the same issue.
FF, I had not heard of LatencyMon. I will check it out. It’s disappointing that Steinberg have not made some kind of attempt to do what is being done in LM. But anyway it is what it is.
I have not done it yet - I tried to open my project and of course Cubase crashed - no indication as to why. I thought I had solved the latest crash cause - I ended up uninstalling the dspfx that came with my UR24C. Now I will have to analyze the .dmp crash file again. Wonderful.
I analyzed the crash dump. Well I don’t really know what I’m looking at tbh so analyzed is not really the right word. I saw something about synsoacc.dll, and then something about this bloody GA Classics thing that I already had uninstalled.
Well nothing left to do but reinstall it, which I’ve just done.
And now Cubase has crashed again, but as only Cubase can do, in an even more frustrating way - it doesn’t crash exactly - it just remains open without loading the project and it doesn’t respond - all I can see is the taskbar.
And there is a new dmp file in teh crash directory. What a crock of ****.
Have the Steinberg software engineers never heard of failing gracefully with helpful exception messages?
Do other DAW owners have to go through this hell? I would never, ever recommend Cubase to anybody because of this. I hate Cubase. Wish I had just stuck with Logic. I never had these issues with Logic and that was running on a bloody Hackintosh. I thought I hated Apple but really that’s nothing to how I feel about Steinberg’s software engineers.
I did everything I read here and on the steinberg website. Tried it on, tried it off. Tried every possible combination. It has cost me over two days already. Not to talk about the money invested in Cubase over the years. This is so disapointing… And mad making as well.
Since my last post when I tried again to use Cubase it was crashing again on startup.
I looked at the crash dmp file, and it led me to a post on this forum (I can’t find it now) where some kind, clever and assiduous soul tracked down the problematic file as defaults.xml in C:\Users<USER>\AppData\Roaming\Steinberg\Cubase 12_64 (on Windows) and posted about it.
I renamed that file just an hour or so ago, and now my project loads.
Safe to say, although I am staying with Cubase for now, I am not giving Steinberg another penny of my money except for necessary updates - anything elese that I spend money on must be useable on another DAW so that I am not any more locked-in to Cubase than I currently am.
