Need help with using process lasso for driver isolation

[wilfredmorris]

Hello,
I'm involved in audio production and have been experiencing unusual latency spikes, primarily due to graphics drivers causing interruptions in audio processing. I've spent a long time troubleshooting this issue, including reinstalling drivers, and I need assistance with the Lasso aspect.

I'm using a 13600K, and Windows is allocating about 95% of the workload to core 0, which is one of the root causes. The most utilized cores are 0, 2, and 1, while 3, 5, 9, 10, and 12 are largely free. Cores 4, 6, 8, and 13 are somewhat underused.

The specific drivers exhibiting high latency include acpi.sys, dxgkrnl.sys, wdf01000.sys, ntoskrnl.exe, storport.sys, stormvme.sys, and universalaudiosbaudio.sys. If I had to pinpoint one program that I want off the core that's handling audio processing, it would be either the NVIDIA Control Panel or Chrome. However, it would be beneficial to manage all of the above.

What steps should I take? What's the strategy? Should I remove all the high-latency drivers from core 0 and reserve it solely for audio processing, or should I isolate my audio software and drivers and assign them to the less utilized cores?

[Jeremy Collake]

Your hypothesis that the root cause is the saturation of core 0 is reasonable, but you should remain open to other possibilities, especially given the scheduling complexity on heterogenous CPUs like the 13600K that have different classes of CPU cores (E-Cores and P-Cores).

Should I remove all the high-latency drivers from core 0 and reserve it solely for audio processing, or should I isolate my audio software and drivers and assign them to the less utilized cores?

Either approach could work, but you'll need to experiment. It's possible that you aren't able to completely eliminate system and driver usage of core 0.

Have you tried our System Reserved CPU Sets feature? You could exclude certain CPU cores entirely from system activities and put your real-time workloads on those. I can't guarantee it'll be effective, but it's worth a try too.

[wilfredmorris]

Your hypothesis that the root cause is the saturation of core 0 is reasonable, but you should remain open to other possibilities, especially given the scheduling complexity on heterogenous CPUs like the 13600K that have different classes of CPU cores (E-Cores and P-Cores).

Either approach could work, but you'll need to experiment. It's possible that you aren't able to completely eliminate system and driver usage of core 0.

Have you tried our System Reserved CPU Sets   feature? You could exclude certain CPU cores entirely from system activities and put your real-time workloads on those. I can't guarantee it'll be effective, but it's worth a try too.

Thanks for your suggestion. I got it/