Did you already perform LatencyMon measurements on an IDLE system to find out, whether one or more drivers are causing high DPC and by this are blocking CPU cores for audio too much ?
Your CPU offers (only) 4 CPU cores (without hyperthreading) at relatively low clock speds of 3.3 GHz. With only 4 cores the likeliness for an audio process to become scheduled to a core which might be blocked by potentially too long lassting DPC might be higher.
You say with Windows 7 you didn't have these issues .. well with Windows 10 you have other drivers and surely some things have changed in the Windows kernel .. That could be a direction which is worth to do further investigations.
In regards to system tuning, did you also optimize BIOS settings ? Before performing any changes make photos of the current settings.
Its important to deactivate anything in the field of energy saving, because this creates lag inside of the system and makes it work less efficient, so that the likelyness for audio drops is increased.
Typically you should disable C-States by either "disabling" them or setting it to "C0/C1" which means that the CPU may not enter any sleep states for the sake of energy saving. Because it takes simply too much time, to wake it up.
Some BIOSes also have T- and P-States which should simply be "disabled".
Also deactivate enhanced halt state (C1E) which is also for power saving and creates unwanted lag.
It can also help to priotize background services in Windows. This changes the way the process scheduler works and gives all processes a longer and equal time slice compareable to service systems, so that the processes get some more CPU time to get the job done. I put together some information about this in this blog article: https://www.tonstudio-forum.de/blog/ind … es-or-not/
It can also help to disable CPU core parking, which is per default enabled on a Windows 10 system.
Bitsum offers a tool to tweak energy profiles and to disable the parking of CPU cores which causes lag:
https://bitsum.com/parkcontrol/
Windows 10 introduces also some Apps, which still run in the bachkground and cause CPU and interrupt load, also network load if they update some online information. This is one of several things that you can silence with the O&O Tool Win10 Shutup. It also helps to turn off some of the Microsoft data collection "features".
You need to run it for the "Administrator" user separately, if you have re-activated this user to ensure, that your own user has no administrator rights.
https://www.oo-software.com/de/shutup10
Further information regarding Resplendence's tool "LatencyMon":
Resplendence also tells that some users reported latency issues on their system caused by CPU power management features that introduce a variable CPU clock. Disabling features like: Intel Speedstep, Intel TurboBoost can help to solve this.
So watch your CPU clock .. a permanent stable clock is more beneficial ...
In case you never worked with LatencyMon. Take your time to read the documentation, that this site offers to you, and try to understand for what purpose this tool is.
This tool simulates a real audio load, so you may not start a DAW or any other application, this tool does its own load test. Therefore I said, measure on an IDLE system, doing nothing. Just logged in and no mouse movements, as also this generates additional Interrupts on your system.
This tool meanwhile supports 3 different measuring methods. "kernel latency timer" only works reliably on Windows 7, this one you can't use with Windows 8 or 10 anymore and leads to wrong results.
Here an example: 5 minutes of meausring
With these tool settings: Tools -> Options -> "Interrupt to DPC latency"
System has to be IDLE and energy profile needs to be "high performance" like when working with audio ...
The "report text" which also contains some useful information:
https://www.dropbox.com/s/jubqygbyjwq4i … t.txt?dl=1
How to use LatencyMon: https://www.resplendence.com/latencymon_using
Some quotes:
"The report view displays a conclusion of the suitability of your system for playing real-time audio at the top. If the execution times of all DPC and ISR routines stay below 2000 µs (microseconds), your system is considered suitable for handling real-time audio without dropouts. If some routines have execution times between 2000 µs and 4000 µs, your system is considered doubtful. If ISR or DPC routines are detected to execute for longer than 4000 µs, a system is considered unsuitable for handling real-time audio. Note that these numbers are just chosen arbitrarily. For optimal midi to audio latencies, buffer sizes of a sound card and driver should be set to very low values then only very low execution times of DPCs and ISRs become acceptable."
"To reduce midi to audio latencies (that is the time between a key press on a MIDI keyboard and the occurrence of the actual sound), the audio buffer size of the audio driver should be as low as possible. But it must be supportable by the system. The acceptable limit of 2000µs for DPC and ISR execution times has been arbitrarily chosen. The lower your audio buffer size, the lower the tolerance for long execution times of DPC and ISR routines and page fault resolution. In order to retain a system that does not drop out you may need to increase your audio buffer size. So it might be that your system is not suitable for low midi to audio latency but you might still be able to find an acceptable balance that works."
BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14