- Use High performance power plan
Impact: possible dropouts, device disconnects, unresponsive system. Severity: depends from the hardware
There are many options in the power plan to save energy, most important for real-time audio production:
- CPU frequency. Min/Max should be set to 100%. Changes in frequency can glitch real-time processing, the load from DAW can be considered too "low" by the system, modern CPUs tend to be slower then 10 years old CPUs when in power saving mode to consume less power. You can see (close to) current frequency in the Windows Task Manager
- USB power saving. Bad when you have USB audio interface.
- Disk power saving. It takes time to continue working with disk after it was suspended.
There are several utilities to fast switch the power plan if your computer is not DAW dedicates. F.e. for Win10: https://www.microsoft.com/de-de/store/p/powerplanswitcher/9nblggh556l3?rtc=1#
Interesting that by default many fine tune parameters are not visible in the power plan UI. You can un-hide them with https://gist.github.com/Nt-gm79sp/1f8ea2c2869b988e88b4fbc183731693 (that is .bat file). Be prepared to deal with HUGE number of new parameters. Note, this file just let you see settings power plan use. It is not changing anything, you will have to do this manually. From other perspective: these parameters are used, even if you do not see them. In case you was wondering why changing some existing power plan to exact values you know was not producing the same result as setting these values in another power plan, you know the answer now ;)
- Your DAW is not a game
Impact: win10 has introduced "gaming mode". Severity: when Sonar is running in gaming mode, many strange things was observed.
When it was introduced (2017), Windows was in the gaming mode itself by default. But there was a switch to turn that off.
In the October (2017) update, the switch was removed with the claim it is now "automatic". What is real status for new systems with the latest update/systems which had the option on before update is unclear.
- Use Latency Monitor to check system latency and problems with devices/driver
Impact: drivers/hardware can block the system for long time, preventing normal real-time processing.
Severity: if there is at least one such driver, the system can be unusable for audio.
Software: http://www.resplendence.com/latencymon, BIOS and optionally:
https://www.techpowerup.com/download/techpowerup-throttlestop/ (it can switch SpeedStep, Turbo mode and some other parameters on the fly, it also monitors CPU use and temperature)
Windows Performance Toolkit from Microsoft (a part of ADK).
Latency influence.
The buffer size defines the block lengh in time. F.e. 44.1kHz 64 samples buffer represent 1.45ms audio. In case the system can not process the buffer
within its maximum time, normaly playback is not possible. Independent from "real time" or any safety buffers.
Real Time audio adds another limit. Audio processing for a buffer should start as soon as possible after input buffers are ready and ends befor the time when the drivers should start transfering output to the interface. Interface/driver normally have some "safety" extra time. It directly influence complete system latency, but increate the time window allowed for processing.
Any delays before the processing can begin (relevant DAW thread start runnin on CPU) or interruptions in this processing (preemption of processing thread, CPU lockouts) plus the processing itself should be within that allowed window.
Begin with In Depth Latency test on completely idle system and HIGH_LEVEL_IRQL test. That will give you the base of your system latency. Good result should be under 100uSec. With under 1000uSec you still can work, but that means up to 1ms unexpected extra latency. F.e. 32 samples buffer is definitively "no go" and 64 samples also going to be problematic.
Repeate the test with some load. If the result never jump you are fine, otherwise you need to avoid the activity which trigger these jumps when you work in your DAW.
Also do DISPATCH_LEVEL test, in idle and under load. In case delays start there, pay more attention to the next Latency Monitor test, may be you can avoid these problem.
Start Latency Montioring (different program) and then continue normal system use, f.e. with DAW. That test does not hammer the system as much as In Depth, but that still get some glitches with audio when it is running (especially on slow hardware). That is not a problem by itself.
The monitor will tell you "no go" with numbers over 1000. Numbers are in microseconds (us, 1/1000000 sec), audio processing "real time" level is in milliseconds (1/1000 sec). As explained before, how much your audio interface/DAW can tolerate depends from the audio hardware, driver and ASIO buffer settings.
For the reference: 96kHz/32 samples buffer is 0.3ms long, so any numbers over 200 in the monitor can be show stoppers. But 44.1hHz/128 samples buffer is 2.9ms, so under 1000 is normally ok. Note that on one side hardware/drivers/Sonar have "extra" intermediate buffers but on the other side the hardware/drivers have different jitter tolerance level. So with the same buffer settings on the same computer but with different audio interfaces you not only can see different round-trip-time latency, but also different tolerance to delays.
When something is "bad", the file name will be shown. Google to find which driver course troubles, but note that general windows drivers are shown in some cases and they are rarely the real problem, find underlaying manufacturer driver in that case (f.e. for disk latency MS driver is shown, while the disk firmware/driver is problematic).
See MSI section later, can help in some cases. If identified driver is common (f.e. ACPI.sys), it works with many system devices. You can try to disable some, but you have no hint which final device is problematic. In case the driver is frameword (f.e. Wdf01000.sys), you can use Windows Performant Toolkit. Run basic profile in Recorded and look at Computation/ DPC/ISR duration by module graph in the Analyser. It can show concrete driver which induct reported delay.
Highest measured interrupt to process latency can be much higher then ISR/DPC. That means user process (DAW) could not scheduled early, the system could have more "important" (from the system perspective) activity. Note that in general all that adds. So ISR can be delayed by other ISR, then some DPC can prevent user land to run, then system activity can prevent your DAW to run. The last can be improved by changing process/thread priority, but ISR/DPC are woking in the kernel and follow different scheduling rules.
- Use REAPER build-in Performance Monitor to check audio/plug-ins timing
I know, I know... REAPER is not "welcome" in the Cakewalk world. But it is able to show way more technical information about used plug-ins, real-time performance, ets.
30 days demo can be installed "portable", and so restless removed later.
Open View/Performace monitor, right click and select RT and XRun parameters. May be load some plug-ins/audio/MIDI. The monitor will show per track CPU consumption,
PDC, overal CPU use and most important for the topic the time spend in RT (Real Time) thread (and its limit to avoid troubles). Note that outside factors can greatly influence RT timing,
f.e. moving window can increase it in case graphics somehow interfere with audio processing. Also note that unlike REAPER, the whole processing in Cakewalk happens in RT.
- Disable unused devices in the device manager
Impact: some drivers can interfere with real-time processing, introducing audio drops. Severity: depends from the hardware and drivers.
Even in case Latency Monitor does not indicate alarm, some drivers can influence how low you can get with ASIO latency. Known cases: NVidia HDMI Audio, several WiFi adapters.
- Check/change Processor Scheduling
Impact: some ASIO drivers work as "background" processes, when foreground processes (Sonar) have priority, that can block the driver. Severity: audio glitches when set wrong, hardware/driver dependent.
Google for your system, f.e. http://www.thewindowsclub.com/processor-scheduling-in-windows-7-8
Try both settings under usual work conditions with reduced ASIO buffer setting to find what is right for your system.
- Exclude audio specific folders and processed from antivirus/antimalware real-time scanning
Impact: when new files are written, real-time scanners immediately check them. Severity: can slow down file processing (in some cases drastically), introduce dropouts.
All such programs have "exceptions" list. Find where these settings can be changed and add at least sonar process (by file name as in Task Manager for your Sonar version) and all folders where you record ("Cakewalk Projects" and such).
Note that some plug-ins use own temporarily files locations. F.e. Melodyne has internal setting for that and not excluding it from scanning slow down audio parsing up to 10 times for HDD.
- Exclude at least audio specific folders from Windows indexing
Impact: Windows will index all new files by default. Severity: depending from your system, that can interfere with audio recording.
Note that while you can stop the indexing service or exclude all disks from indexing, that can have small negative side effects.
- Disconnect from the Internet during critical work
Impact: when you are connected to the Internet, Windows periodically starts many "tasks". Severity: can slow down the system, introduce audio glitches, crash, reboot.
While there are tools and manual operations to prevent that, in reality the user will always "loose the fight". Windows re-enable some services/tasks on updates and/or introduce new.
There are several tasks which will start even with the Internet disconnected, but at least they are not "killing" the system.
- Switch graphic card (may be other devices) to MSI mode
Originated from: https://forums.guru3d.com/threads/windows-line-based-vs-message-signaled-based-interrupts.378044/
In short, try MSI utility v2 to switch devices which introduce high latency in drivers.
- Try to rise DAW process priority
If there is no sufficient cores for all processed which want CPU, OS schedule execution according to priority. The priority can be set in the Windows Task Manager. More then "above normal" are not recommended since that can delay system processes required by the DAW. There are tools to set it permanently for given executable.