Many thanks for this link. Its quite nice. But just a few remarks.
Most tips are good, but the author fails to give some information here and there.
What really makes me wonder, that he forgets to talk about a very important basic step to do.
To check the BIOS settings and to disable everything related to power saving in the BIOS.
Especially this can cause much latency inside of the system as it takes time, until a core becomes available again
after a core entered a sleep state. The deeper the sleep state up to C6, the more time it takes until he is available.
This can take over 250 microseconds for C6 which is a lot.
So its best to disable all C-States (keep C0/C1), P-States and T-States (depends on the BIOS whats configurable)
C1E should also be disabled. EIST and Turbo can stay, as you can control in Windows with the tool parkcontrol
to disable CPU core parking and whether a Core shall change its clock.
If both is enabled you can control it as user with tools and in a good case of luck you will get by Turbo
a clock frquency which is a little higher than the base clock of the CPU for all cores permanently.
Which is definitively much better than having to put a few cores to sleep to be able to reach highest turbo clock frequency, but then for a minority of cores.
And if he goes that much into details up to process scheduler and driver, then he should not forget to mention, that those ISR and DPC driver routines are not under the control of the process scheduler, they run as long as the developer coded, this is fully based on programming conventions. This is one of the reasons to disable not required hardware and not to use those hardware which is known to create many interrupts. This reduces the likeliness that an audio related thread needs to wait for a CPU to become available.
I also missed a bit to give the user a helping hand how to use LatencyMon. It makes no sense to execute it when you have load on your system or already started your application. Then you do not see anymore how much BASE load the system already has, although it should be IDLE. Another use case is to use LatencyMon after having tuned the system to see, whether under an audio load the systems kernel timer latency etc has no spikes, which can cause audio drops, which requires to choose higher ASIO buffer sizes to mitigate this issue, if the CPU can't react that agile anymore under load and immediately process audio ... then you need to raise ASIO buffers shall you get Audio drops ... etc.
BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14