I do run the Process Explorer utility (free download) to see what takes what as CPU resources.

That's simple to do and "non-destructive"..It is a reliable bona-fide utility made by a high-level emplyee of M.S., but put out independently.

I will also mention that I do run Sonar on high-level priority via a batch file, all the time. This does make a difference.

The other thing is set all options on "hybernate", "sleep/resume", "stop drives", and such "power saving options" to "NEVER", or at least to effect an hour or so after inactivity....AND, if they do activate, do realize that "resume" does not necessarily put everything exactly as it was before the pc/laptop goes to sleep, or such things.

I did in the past eliminate by hand picking processes that I investigated and concluded that they were not essential or had no real reason to be there.

But with the Process Explorer, it is so simple to see how many processes are enabled, and how many are actually using or not CPU resources.

The Idle process is the one that checks continuously for the status of facilities being on or off, including the Internet and other connections...When they are OFF, it does nothing..So if the WIFI is OFF, the OPSystem does not try to connect. The Idle process is super essential, so that is not one to try to kill. Another similar one is the Internet Explorer process, which does not really reflect its many essential duties that have nothing to do with the internet...So that one is an essential one...But ones like "Instant Messager" and other such ones can be unloaded from the startup if not needed.

Wouter Schijns
wondering if results of all these steps actually show in Sonar Preferences (Audio/Driver settings)..
or, if latency number is ok there I'm good I guess..not sure if that is your actual latency or just a calculation..

Sonar reports what the ASIO driver tells it the latency is. This may or may not be the actual latency. Many interfaces have a built-in "safety buffer' that the driver does not report, some drivers have a "safety buffer" written into their code which might not be reported. The only sure way to measure audio latency is by looping a signal out through the interface and back in again and seeing how long it takes.

The latency that things like wireless network adaptors often cause has nothing directly to do with audio latency. It's a measure of "delayed procedure call" latency, which is how long hardware drivers are hogging the attention of Windows and the PC's PCI bus while they do their thing. Delayed procedure calls are what makes multi-tasking possible in a Windows/Intel system. For most of the things people use computers for - internet, office stuff, photograph editing, gaming - dpc isn't an issue because if an application has to wait 20 or 30 or so milliseconds the user will probably never even notice. DAWs and video editing software do notice because they need as close to a "real time" access to the hardware as possible.

Dpc latency can affect the minimum possible audio latency because if the audio driver's buffer runs out before the driver gets Window's attention back or can't be filled quickly enough then you get audio crackles and dropouts unless you increase rhe size of the buffer.