If you’ve had a chance to follow what I’ve done so far, you’ll see that I’ve been successful in getting Cubase 11, 12, and 13 all working currently by starting with a fresh install of Windows 10 & Windows 11 in a dual-boot combination.
I am currently using no BIOS related changes or “tweaks” to get things working.
Stay tuned!
Latest Update:
Recent changes are to move my Cubase machine to my wide-screen monitor and the general purpose one to a single monitor.
I also switched to using MX Keys Mini and MX Mouse with the internal Bluetooth. The sticky point here is that this setup cannot operate before the OS is up, leaving an issue with selecting the dual-boot selection at Startup. This is the same issue as using this setup being unable to trap the BIOS at startup.
As long as I don’t need to do either of those things, I can switch between the 3 Bluetooth pairing capabilities and the keyboard/mouse function as expected.
I was previously using a Logitech diNovo combination that IS able to trap the BIOS and to select the dual-boot configuration. I will investigate this later.
After installing the drivers for both OS, I tested the Cubase 11 project again to confirm that the performance numbers mentioned earlier still apply. This indicates that the MX Keys/Mouse are not causing any real-time issues affecting the previous results.
Now for some initial results with the new PC build. For these short-term tests, looped over the material for a minimum of 3 passes with no audio glitches or performance meter overloads.
MAG Z790 Tomahawk WIFI (MS-7D91)
Intel i9-14900K 24 cores (32 logical processors)
64 GB G.Skill Ripjaws
AMI BIOS H.90 11/6/2023
Windows Home 11 10.0.2.22631
Windows 10 installed on Samsung 840 SATA SSD
Windows 11 installed on Samsung 990 Pro M.2 SSD
BIOS & Windows running on pretty much stock settings, no special tweaks.
Note that on my original Prime Z490-A, I am having a lot of glitching issues with a very small number of Retrologue instances. I will do a little more debugging but haven’t decided to what extent I want to keep investing in that solution, since I have a new workhorse that avoids the issues.
I’m of the opinion that something is very wrong, however I do not notice any particular weirdness when running non-Cubase applications.
After some substantial reading, I did rearrange my PCIE devices to avoid unanticipated conflicts with the CPU/Chipset architecture. The i9-10900K has 16 lanes from the CPU, so a 16-bit GPU has to share bandwidth if anything else is on those lanes. I moved all other PCIE devices to sockets connected to the chipset.
It may have helped a little, but I’m still having substantial issues.
I discovered Process Lasso and installed the free version for some testing. I started first with my Prime Z490-A i9-10900K machine that was causing be difficulties running Cubase (especially 13).
I configured a profile as follows:
I also configure to switch Power Plan to High Performance when Cubase is running.
My Cubase (all versions) have gone from effectively unusable to working reasonably well. Benchmark for Cubase 11 using Dom’s test project yielded an increase of 2-3 instances to 19 instances. I don’t know if this is the max I should expect but it hasw moved into the realm of usable.
I did an audio-only mixdown of a project after these changes and did not see issues with audio glitches or ASIO overloads.
Process Lasso is 30% off for the paid version (lifetime on 5 CPUs) this week, and for that price, it has solved enough headaches for my satisfaction to purchase a lifetime license (I HATE subscription-based fees).
I have installed Project Lasso on 3 machines (2 Windows 11/1 Windows 10) with identical configurations that may be further tweaked if needed. I suspect I will find that SpectraLayer and Wavelab will also benefit but have not yet tested.
I’m at a bit of a loss where I should post information I’m discovering about the DPC issues causing problems with Cubase!
I want to be clear that my intention is not solely to bash ANYONE. That said, I feel I have gone well beyond the call of duty attempting to analyze what is going on here with Windows/NVidia/Steinberg/whomever and I, frankly, am uncertain about where or how to address it, and to get some help from people who should be focused on a solution.
I have been collecting information about what’s going on here and I am at a loss how I make all the “players” in this scenario aware, and perhaps get a little help in figuring out the details, or even if all said players are already aware and researching solutions.
I have definitive evidence that SOMETHING is occuring every 15 minutes in both Windows 10 and Windows 11 that is causing DPC execution time spikes. There are TWO spikes every 15 minutes and the only thing RANDOM about them is their duration varies a bit. The other thing is that these spikes are consistently longer in Windows 11.
So, my question is: where and how should I present the data such that the “experts” can offer guidance?
These spikes are ALMOST like clockwork (NOT random), and I believe that the apparent randomness depends entirely on what happens to be going on when these spikes occur. Also, these spikes affect ALL CPU cores!
I have collected data to support my findings and have some theories why some of the things on peoples’ “try this” list might mitigate the symptoms, but do not address the underlying problem(s).
My question is this: Where is the appropriate forum to post my findings in order to get some technical help further analyzing the ROOT CAUSE, rather than a list of “try this” to mitigate the symptoms?
Some expert help would be greatly appreciated. I can post DATA illustrating the issue(s). Help me help you!
I have not tried this yet, but will take a look. It certainly makes sense that interrupts would be reduced but a change from 15ms polling to 5s polling seems a bit extreme without much more research into what this is doing.
I don’t know how this relates to the 15 minute DPC spikes I’ve observed, and I would like to know more about what this is affecting.
The key question is what are the potential side-effects of this and is this yet another workaround, rather than addressing the root cause.
Ok, I took a quick look at changing the interval as suggested. I did NOT change it to 5 seconds! I made a change to 200ms. It did indeed reduce interrupts and latency, as well as number of page faults (not a big surprise, less interrupts, less page faults).
However, this did NOT affect the DPC latency execution time spikes every 15 minutes (also as I expected). Thanks for the suggestion, but it does not address the issue I’m seeing.
Here’s an update that for now I would take with some grains of salt:
Based on what analysis and limited knowledge I have; it appears that some of the factors affecting DPC latency and DPC execution time are at least tangentially related to Windows power management. I don’t yet have enough information on how all this works to start mucking around with all the power tuning properties.
I have made two changes that have shown some improvement in BOTH DPC latency and execution time:
Decrease the processor performance time check interval (polling interval). The significantly reduces overall DPC latency by reducing the sample period of the performance management algorithms. This makes some sense, since the default for high-performance mode is 15ms. I found reports of some user(s) changing this to 5000ms. Without more information, I would not suggest such a radical change. I don’t have enough information to suggest how this might impact an overclocked CPU, other than to say whatever algorithms in power management are contributing will take action slower, so transitions between power states, clock frequencies, core parking, etc would be slower, but also consume less CPU resources calculating changes. I have changed this from 15ms to 200ms which matches the default polling rate of the Balanced power plan. This produced a significant reduction in over DPC and ISR latency, while still monitoring power properties 5 times per second.
Disable C-States in the BIOS. This is a common suggestion as you search the web concerning latency. As I was analyzing the WPA data, it did appear that power management services and processors in C-State C2, may have been contributing to the DPC latency duration events. This also kind of makes sense, though I’m not sure how the duration is being measured. Clearly if a DPC is assigned to a core in the C2 state, it makes some sense that there would be a delay processing that could contribute to the duration.
I am not yet comfortable enough to recommend these changes, as I don’t have enough information on how it might otherwise affect the system, especially in overclocked systems where slowing the power management may potentially impact thermal performance.
The spikes I mentioned previously are still occurring, but their duration is now low enough that LatencyMon is not triggering the unsuitable for real-time audio warning. I do not know if a longer analysis will show that the duration is still sometimes exceeded, but so far 90 minutes has not caused the warning from LatencyMon on my Z790 i9-14900K system. Given these durations are already shorter on the Z490 i9-10900K, I’m speculating that there would be similar improvement there.
I still need to experiment and attempt to confirm, but this looks like potential progress and may offer further clues.
I think ultimately if power management can maintain enough cores in a C0 state AND determine what processes should be isolated to these “protected” cores, this may be a viable solution. I’m not certain what metrics would verify this, but it seems a decent comprise to get some advantage of both performance and DPC latency while also managing lower power consumption.
Ultimately, controlling C-states per processor along with affinity seems a viable solution in the OS rather than disabling C-States entirely in the BIOS. Much too early to state definitively.
Update:
I ran LatencyMon with the above changes for 11 hours with no “not suitable for audio” warning.
I still am not comfortable with the duration of the 15-minute DPC execution duration spike but it is now reduced to the 850us range (peak), as opposed to as much as 2-3ms.
This was accomplished without disabling startup programs that might reduce it a bit more.
The change to the 200ms power polling made a significant difference in DPC latency, and combined with disabling C-States has also reduced the maximum DPC execution duration.
At this point, I am suspecting that power management is a contributor, if not cause, of DPC issues.
I am not ready to recommend these changes, but you may want to experiment to see if it helps your situation.
I am curious if imposing some constraints on power monitoring might further improve the results. My preference would be to only affect things like C-States and power monitoring when running affected apps and NOT by BIOS changes.
When I’m more confident of a solution, I want to repeat the Cubase stress test, and also determine if some of the priority tweaks in Process Lasso are needed AFTER these changes.
If the Steinberg/Microsoft team(s) discover a recommended solution, I hope they will give a reasonable summary of what was changed and why.
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.
This was a surprise to me as I’d been working all year on it
Not bad advice, but with all due respect, I wouldn’t have taken on this project if I was not seeing significant issues AND was totally unsatisfied with much of the discussion about it. Your response kinda’ makes me wonder if you read all the info that I’ve posted.
By all means, if your computer runs fine with no dropouts with the number of tracks you require OVER LONG SESSIONS, it’s probably best not to go looking for trouble.
That said, I’ll double check my version. I can post traces from WPR/WPA illustrating the issue. I’m not willing to ruin a good take due to a “random” spike caused by a provable (and measurable) 15-minute event.
I too was fine with my Z490 i9-10900K until both Windows 11 and Cubase 13 arrived. When I decided to build a new machine and subsequently STILL had issues, it became a bit of a mission to figure out what is going on.
I hadn’t even heard of LatencyMon until I started this research. Process Lasso and a couple of priority tweaks largely mitigated the issue. My job required me to often SOLVE these issues. I was not satisfied with the solutions I was seeing. Would you be fine with your wireless microphones working “most of the time”?
Dave,
It was more a reply to the general DPC latency question people seem to get obssesed with rather than specific to your situation.
I run a professional studio so need everything to work 100% . When I’m playing live I also expect the same. I don’t use wireless for that reason
Appologies if you’ve taken my post the wrong way.
M
I get it! I’ve been trying to be constructive and have tried to include SOME data supporting my research.
You made a good point! It just seems odd the time and place you chose to do it.
My example of wireless microphones may have not been the best, but with 10 years in embedded work on wireless, we were challenged with solving a lot of complex and “show-stopping” issues.
I can show DATA illustrating the issue. I’m still trying to determine the root cause with the tools I have available.
Dave,
I wish i could help you. I’ve never really had an issue with this in all my years running DAW’s.
The odd DPC click usually results a dropped sample which is easy to spot and draw out on the sample editor (if it does ever happen). I wouldn’t lose a great take beacause of that if it’shappening all the time for you then it really is a PIA.
Hope you get to the bottom of your issue. I know how frustrating it can be .
M
This is a very informative video. I made some of the recommended changes and Cubase became much more responsive . Not sure regarding stability as I still get the occasional crash (without any report) A restart normally solves the problem though.
Thanks again
Product Name: MAG Z790 TOMAHAWK WIFI
OS: Microsoft Windows 11 Home 64-bit Ver.2009 (OS build 22631.2792)
BIOS Version: H.90
BIOS Release Date: 11/06/2023
CPU: 13th Gen Intel(R) Core™ i7-13700K
Memory: 64 GB @
- 32 GB DDR5-6400, G Skill Intl F5-6400J3239G32G
- 32 GB DDR5-6400, G Skill Intl F5-6400J3239G32G
Graphics: RX 7600 MECH 2X 8G Series, 8176 MB
Graphics: Intel(R) UHD Graphics 770
Drive: SSD, Seagate FireCuda 530 ZP2000GM30013, 1863.02 GB
Drive: SSD, Seagate FireCuda 530 ZP2000GM30013, 1863.02 GB
Network: Intel(R) Wi-Fi 6E AX211 160MHz.
Hi to Dave_B
As you can see I have the same Motherboard as you and I have the same 15 minute peak as you, LatencyMon tells me it is Ntoskrnl.exe.
I have managed to lower it from the 1000’s (40000) at it’s highest to under 600.
All my other readings are now below 140.
The Things I have done successfully to lower latency.
Disable Core Parking in the registry
HOW TO DISABLE CPU CORE PARKING IN WINDOWS 11.
Open the registry editor.
Navigate to:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings
Right click the PowerSettings folder and search for dec35c318583.
Double click ValueMax and change the value to 0.
Restart the computer.
I use a very old firewire interface and Set it’s IRQ priority to 1.
You could probably do the same with a USB interface.
Open msinfo32.exe and go to “System Summary\Hardware Resources\IRQs”
Find the IRQ for your audio interface.
Next, open the Registry Editor, (regedit.exe) and navigate to HKEY_LOCAL_MACHINE\SYSTEM CurrentControlSet\Control\PriorityControl.
Create a new DWORD value in this key, and call it IRQ#Priority, where # is the IRQ of the device you wish to prioritize
In my case it was IRQ 17Priority
Double-click the new value, and enter a number for its priority. Enter 1 for top priority, 2 for second, and so on.
Close everything reboot and it’s done.
Make sure 1) USB suspend is disabled 2) wifi suspend is disabled (max performance) 3) GPU set to maximum performance.
Then under Processor Power Management you will find two new settings, Processor idle Promote and Demote Threshhold. Set both to 100.
Then Restart.
The biggest difference came from disabling Core Parking.
Please back up registry before starting.
I also did what was in the video you posted and found that if I set it at 3000 I got best results, any higher than this and other readings got worse.
But as with you none of these stop the 15minute peak caused by Ntoskrnl.exe, there must be a way surely – it is just so annoying.
At least with it being below 600 I can make music.
Thanks for the info! I’ll check this out, but will want to evaluate your solution a bit further before following.
I have already gotten improved performance by changing the power management polling rate and disabling C-states.
Yes, WPR/WPA also implicate ntoskrnl.exe, and the other processes during the event(s) appear nondeterministic.
I’m using Process Lasso and changes there may duplicate some of your findings. I know that I’m disabling core parking while Cubase is running.
I’m currently probably in a usable state but not comfortable with the event duration. If you have the duration under 600, that’s likely workable.
Thanks!
I’m only using latencymon and on my PC and it won’t run with cubase 12, so my figures are without software running.
I also use process lasso.
The spikes that first drew my attention to the problem were happening in Amplitube 5 standalone without any high cpu usage.
I can now run Amplitube without issues and latencymon shows a very small increase when using it.
Ntoskrnl.exe is being used by a process that happens every 15minutes, We need to track down that process.
Don’t think it’s Wifi as I tried without it having removed drivers and disabling.
Strangely the hack in the video dropped the interrupt latency but made no difference to the DPC level of the spike, well spikes as I notice mainly 2 but sometimes up to 4 happening at once.
When or if I find out what the problem is I will do a clean install.
I am slightly worried it’s something to do with the motherboard drivers, but experimenting on them will have to wait till after Christmas.
It did not happen when I first built the PC in July, but started this November.
