We’re developing a Windows Thunderbolt driver at Antelope Audio, and we’ve encountered issues with the Multimedia Class Scheduler Service.
With low buffer sizes (e.g. < 64 samples @ 192kHz), we’ve observed that the DAWs’ audio processing thread priority is lowered to 1-7, because it has exceeded it’s CPU quota (the behavior described at the end of this document: https://docs.microsoft.com/en-us/windows/desktop/procthread/multimedia-class-scheduler-service). Since on Windows there usually are other threads ready to run, Windows schedules them instead. This causes missing the deadline, resulting in pops and clicks. We’ve experimented with disabling the MMCSS service altogether, and this actually improves audio streaming (i.e. no pops/clicks with the same settings).
In our driver, we’ve made the MMCSS registration optional and user-configurable. Different DAWs behave differently. For example, Cubase registers its audio processing thread with MMCSS, Pro Tools doesn’t register with MMCSS and uses SetPriorityClass() and SetThreadPriority() API instead, and Reaper has a user-configurable option to choose whether the audio processing thread will be registered with MMCSS or not.
We believe that registering with MMCSS shall be optional (and user-configurable) both for the ASIO drivers and ASIO DAWs, and would love to see the ASIO specification changed. Right now, ASIO 2.3 specification states in V. D. 1: "On Windows Vista or any newer Windows version, ASIO driver threads must be in the “Pro Audio” class of MMCSS and their priority set to “CRITICAL”. In our experience, this is not optimal, especially when using low buffer sizes for lowest possible latency.