Wow! It’s abysmal! Never thought one would have to wade through such murky waters just to have a professional tool behaving like it should out of the box. I know all the tweakings one has to do windows wise, but this is getting too much.
5 Likes
Does anyone know what ‘processor affinity’ one should use if they are on Apple silicon?
I believe it is possible to change this in ‘activity monitor’, but it really shouldn’t be necessary for the end user to have to jump through hoops like this to get a premium product to run stably…
Hi all,
I’m using this pc only for DAW.
Windows 11 pro with the latest updates, setting to best performance.
Disabled bluetooth and wifi.
No other third party drivers, just that what windows does.
Cubase 13 pro, run as administrator and it works fine.
May I ask: Who here is using a laptop that is having this issue? Or is everybody using a desktop? If you do use a laptop, right-click the battery icon on your taskbar, go to power options, and set it to high performance, then see if the CPU spike goes away without having to disable any cores.
If you’re on a desktop, then I suppose it’s moot. But I’m throwing it out there because it just fixed a different issue on my end that could possibly help in this situation. Maybe not but just in case.
I’m using a desktop with Steinberg Power scheme. It’s definitely not that. It’s something my storage controller is doing, sometimes what the NVIDIA driver is doing, I’ve narrowed it down to those mostly. Just don’t understand why it’s so hard to make errant drivers behave themselves and wait their turn in line, even breaking their tasks down into smaller chunks so they have no opportunity to interrupt real time audio. Just seems like the basics, but the industry is remarkably good at ignoring the basics and writing crappy drivers that can’t get along, anyway. Just never seems to end.
And Bluetooth or wifi should, again, have zero authority to interfere with the audio subsystem under any circumstances. This stuff just shouldn’t be happening this far into the 21st century. I don’t understand why these basics seem so low on tech companies’ lists of priorities. Keep “innovating” at all costs–including disrupting productivity and all but ruining the fun of creativity. I remember when “disrupt” had more negative connotations than positive ones, but appeasing the ego of the almighty tech bro seems to take precedence over everything these days.
1 Like
Its only important that games are running 300fps, we also have 8K resolution videos but our music must be compressed to AAC. So much about how important is music quality to industry.
3 Likes
This is a good starting point but shouldn’t be relied on . Windows has so many notifications running in the background , i counted turning of 143 yesterday on a new install , that’s a lot of time your system spends checking for no reason and causing interrupts .
That said , people always compare LIte Daw’s with a heavy 25 year old PC code , it’s not possible , audio will always need finite tuning of the OS if you want to run anything over 15/20 tracks , you think how many processes are running with Cubase compared to other Daw’s , you’d be shocked
Oh, believe me, I know: I’ve done copious tuning over the years. Copious. I’ve been using Cubase since VST 3.7, briefly switched to Logic, then we all know what happened, then Cubase SX and on and on. Has not been a cakewalk, no pun intended.
(I even had a separate Mac to run Logic Pro for a while… performance was kinda crap there, too, if it’s any consolation to anybody. Doubt it is. The only DAW I’ve used that is consistently an awesome performer but just isn’t powerful enough from an editing standpoint for me is Ableton: continually surprised what I’m able to get away with in terms of real time audio with that one. I truly feel confident using it live on a “just decent” laptop.)
1 Like
Just want to reiterate how completely unacceptable this Windows DPC latency situation is in general, and I don’t care whose fault it is: something must be done. If it’s “poorly written drivers”, then the DAW developers, the plugin developers, the ENTIRE PROFESSIONAL AUDIO INDUSTRY needs to isolate, identify, and put pressure on those companies who are allowing these “poorly written drivers” out the door.
I am so tired of spending my entire weekend staring at LatencyMon and trying various tweaks from randos on the Internet to try and get on top of this travesty of a situation we still find ourselves in 2023. Posts like what I found here should not be a thing:
4 Likes
It is mainly the hardware and the poorly written drivers in combination with the interface(s drivers).
Theres really nothing which can be done on the DAW and 3rd plugin dev level.
As explained in another thread, the audio industry is a complete niche for the hardware computer market in general, so good luck putting pressure on them.
But its not really that complicated. Most issues can be solved by changing out by not using those typical gaming GPUs, which are not needed in an audio PC anyway, using wired network connections and using different USB ports.
1 Like
I strongly disagree: real time audio handling should be considered basic and critical to a modern computer, period. If these devices cannot play nicely together, Microsoft or someone needs to implement a standards framework which drivers must meet in order to be installable. Something’s got to give. This is ridiculous.
I finally, after tinkering all weekend, have gotten 13 hours plus in the green in LatencyMon. It seems processor affinity to six of the performance cores excluding the first two for the svchost process responsible for real time audio (forget the name but it’s in a tenforums link I posted) may have done the trick. I guess now I have to figure out how to get this to be persistent. I’ve been all RME for years and their drivers are generally beyond reproach, so I don’t think that has much if anything to do with this.
I think this is an industry-centric problem that the industry needs to address; as a consumer, it shouldn’t be my job to figure these things out, and that is my central point. I have wasted more hours, days, weeks, months than I care to think about on such issues. I’m tired. And I’m especially tired of the defeatism: pressure comes from us, and I’m tired of being told, “You’re wasting your time, it’s a niche, blah blah.”
I’ve already gotten Steinberg’s attention, or helped in that process, so that alone is something. I’m going to keep stressing my central point therefore, as I believe it is valid.
1 Like
I agree with you but for one tiny issue. If drivers are blacklisted in some way, users need a quick and easy OPTION to somehow install it and try to use it anyway.
Every time they fiddle with driver store and signatures, 10k worth of perfectly working equipment that meets or exceeds every performance requirement gets marked for the land fill.
Typically it’s better for security and stability but bypassing it IS sometimes necessary, safe, and flat out works. It drives me a little nuts when perfectly good, properly signed drivers stop working one day just because of a version number in the INF file and there’s no efficient way to get them installed 
Sad truth, but sometimes the 15 year old stuff who’s designers have moved on and will never do anymore drivers simply works better than things that came out yesterday. IF you can still get the last release of drivers for it to ‘install’.
Having the driver signing protocol in place by default, with ‘use at your own risk’ warnings to get around it is definitely nice. Still, there needs to be a way for users to get around it. I’ve long wondered why MS won’t provide a kit where users can easily, yet securely resign older drivers so they’ll at least ‘install’ on ‘one specific system’. Currently it can take a real Windows Guru professional all day to do something similar, it’s quite complicated and only works for the INF level of the ‘installers’. As far as I know it cannot sign at the kernel level. Going there can cause one to needlessly disable an ENTIRE security feature system wide (not just for a single driver) and sometimes it still won’t install after hours of trying…mass deployment over several systems grows to nightmare proportions.
It’s really frustrating when simple drivers are broken for something like a classic hardware synth. Drivers that can and should work fine but for a simple version number or something in the ‘installer’. Those can cost a lot of money, and are often meant as investments to serve the user over a LIFETIME. Some even turn out to be heirloom worthy (like a Stradi violon to us today).
Right, I’m thinking more of a testing framework that can catch if a driver can cause a problem, one that actually makes sense in the context of professional audio: if a driver passes and can be proven not to pose any problem or even be capable of such, it is not blacklisted, no matter how old.
I agree: regulation should never come at the expense of common sense.
But the problem here is very simple: it’s almost 2024 and real time audio dropouts are still a problem on very high end computers. Mine certainly qualifies: I wait several years and then go all in, and I certainly did on this one. It’s a beast and is extremely fast at various benchmarks & tasks, but it just can’t seem to handle something as basic as real time audio without deep tinkering that I don’t have time for–and that’s a travesty.
At the very least, we should have AI-based tools capable of doing these technical deep dives for us and finding exactly what the cause is and offering to make the necessary adjustments and make them persist across reboots if necessary. This should not fall on those of us who are simply trying to get music done. It’s a constant battle. And I’m tired of battling complexity theory and even entropy itself when it comes to computers and software. It just costs far too much time and causes way too much stress.
If Microsoft or Asus or Steinberg or NVIDIA or Intel or RME or whoever are unwilling to take responsibility individually, I believe it’s past time for the industry to form a consortium that recognizes, “Hey, it seems we have a really embarrassing problem in regards to real time audio and it’s not the 1990s anymore, this shouldn’t even be a thing–let’s get to the bottom of it and ensure it never happens again.”
That’s my point: we should be well, well past this if we can fold 220 million proteins last year and then 600 million more on top of that this year. There are plenty of people in digital audio and content creation now who need real time audio to work properly on Windows–for it to “just work” and not have to go forum-spelunking for a fix.
Something’s got to give is all I’m saying. Cubase just froze, completely froze, so I’m typing this while I collect myself.
2 Likes
I get your point, but again… if at all, Steinberg is the very last on the list. Cubase has no access to hardware/driver level stuff, its simply a program that needs a system with low DPC latency to run properly.
Instead it would make more sense to open threads on Nvidia/AMD/Intel/Microsoft forums.
Agree…or even make ‘affordable’ dedicated hardware for the recording side of things. It probably still exists for the big studios. I’m thinking along the lines of the days when we used the PC to ‘sync’ dedicated recording gear. I still have the old BOSS stand alone digital recorder (never needed to record live on the scale of multiple ADATS or anything). It’s ancient, slow, but never missed a sample when it came to pulling in 16 or so inputs in one go. It’s only 44.1khz and all, couldn’t do a zillion tracks (I forget the upper limit now), but it never failed to deliver what it was designed and advertised to deliver.
1 Like
Again, I want the audio industry to band together and put pressure on whatever parties they determine most able to do something about this. I’m tired of it being my job to shout into the void of volunteer-moderated Microsoft or Intel forums or whatever. It’s pointless.
Money talks, and Yamaha has money. Lots of money. So does Avid/STG and many others. You get the point. They could get on top of this if it were truly a priority. That it’s almost 2024 and the industry is still in the sorry state its in in terms of real time audio performance speaks volumes about where their priorities really are. And that is my point: this should not be my fight to engage in, but currently I’m faced with little choice. I want that to change and that’s why I’m making so much noise: squeaky wheel and all that. I want nothing more than to never have to be in this position again.
2 Likes
I was getting these spikes in C13 with a message “CPU Overload / Dropout detected” even after trashing C13 preferences.
I still have C12 installed as well, I trashed the preferences of both C12 and C13
which seems to have fixed the spikes.
I suspect there is some sort of interaction between the two versions, when I trashed C13 preferences, and let it create new ones, there were some elements from C12 in the new C13 preferences, such as in the colour scheme.
By trashing the preferences of both versions, C13 couldn’t ‘borrow’ bits of the old C12 preferences and so had to create totally new preferences unaffected by the old.
I’m not 100% sure of any of this but there have been no spikes since. Also there was an update for C13 which likely had some effect on this issue.
Mauri.
with Regard to DPC latency.
I had/have an intel 12900 laptop. It ran fantastically as a DAW . It sometimes ran projects from my studio 5950x machine much better !!!
After a year of perfect use I was reading a thread about a similar laptop and DPC issues . So I decided to check my machine.
It failed the DPC test, huge spikes into the red etc etc with the warning my machine wasn’t suitable for real time audio.
This was a surprise to me as I’d been working all year on it 
So i always say to people to ONLY use the DPC latency checker IF YOU’RE GETTING ISSUES.
otherwise don’t bother. It’s a useful tool sometimes in trying to narrow down issues but it’s NOT allways a good metric of a computers audio performance.
With the currrrent crop of intel and AMD cpu’s with huge cores/thread counts having a background process causing an interupt doesn’t make for an audio dropout as you have so much headroom with other threads.
I did a bit of experimenting with the DPC and if i istalled one of the core parking utilities and basically STOPPED core parking all together then my DPC went down into the green and stayed there. With the new CPU architecture cores parking and un parking is what casuses the main DPC checker to spike.
When windowsd 10 came out there were lots of isseus with people complaining about DPC latency and windowds 10 being awful. In fact it was the DPC check app that was wrongly showing spikes. Once they’d updated the program everything was again back to normal. I’ve a feeling that we’re in a similar situation with DPC latency checker and cpu’s with E and P cores and core parking.
Just my 2 cents on this matter.
M
2 Likes
Ah, but you see, it’s Steinberg that sold me purpose-built software that, assuming you recognized the amount of chatter, does not adequately perform its purpose. AND it’s much too easy for said companies to point back and forth, and they often DO!
1 Like
DPC latencies are mostly an issues when having lower buffer sizes and especially during recording. If you have your buffer size medium to high, it doesn’t come into play that much.
Also depending on the processor and the heaviness of the projects, you probably get away with it, especially if there are only some single DPC overshoots in an hour or so.
But still I’d recommend to get rid of them anyway. No need for DPC latencies on a DAW at all. 
Yes that is true, and I am with you on that.
E.g. look at the thread I made about 3rd party plugins crashing Cubase: Solution to crashes by plugins - Sandboxing (Crash protection) - Cubase - Steinberg Forums
Of course the root problem is the faulty code of 3rd party plugins, and its perfectly fine if Steinberg tells you to contact the plugin dev, to fix it.
But Steinberg should also recognize, that they are selling a platform for said 3rd party plugins and that its also their job to provide a stable application in general.
They absolutely could deliver a completely stable DAW, even if plugins crash, which would improve usability and user experience by 10000 miles, as 90%+ of crashes happen because of plugins. This has only upsides, for Steinberg and us users as well. Of course you would still have to contact the 3rd party dev to fix it in the long term, as you’d always have to reload those crashed plugins. But at least your troubleshooting is much faster and you don’t lose any data/files and much less time.
But thats not comparable to DPC latencies caused by a systems hardware or drivers, where Steinberg have absolutely no access to.
The only thing, which could come to mind, would be a latency check tool, which tells you, where your issues come from. But we kinda have that tool already and its working perfectly fine.
Yes, Yamaha as a whole company would be probably the only one, which had enough to say to talk to hardware and OS companies to provide compatible stuff.
As all the other companies in the DAW market together aren’t even 0,5% what the entire Yamaha Corporation is (still music only plays a 2% part @Yamaha).
I get you point, but the DAW market is already a little niche. Then add to that, that only a very tiny percentage of people really have issues with DPC latency on their system anyway. Outside of our world DPC latency is a non issue, so 99,9% of people don’t even recognize it and/or don’t care.
Sadly, thats the reality.
If there comes a solution someday, it will be another prebuilt and checked “low latency professional audio DAW PC” which you can expect to be very costly. At that point most users will skip that anyway, so there will be no big interest in it and therefore also not a lot of sales and slowly companies will lose interest to offer such systems. This already happened in the past and some sellers are still active, but as you see, there is just no big interest in that, or didn’t you know about that and it would have been something for you?
As an IT guy I can assure you, that its nearly impossible to predict how a system works as a whole, until you have built it and tried it.
Too many things just come into play, when it comes to DPC latency.
And by the time you buy a costly prebuilt PC, which was checked and approved beforehand, you’re better off building your own.
The best we could do, is share our system specs and hardware, so when buying new stuff, we know what we should avoid.
In my case:
I use i7 intel processors since 10 years+, together with Asrock motherboards and cheap non-gaming GPUs by nvidia (currently a GT1030) and basically never had latency issues at all. Even with all kinda crap wifi/ethernet/usb cards enabled.
AMD GPUs on the other hand all caused drop outs on my systems (tried 3 different GPUs from them until I gave up).
1 Like