Audio Workgroups equivalent on Windows?

I’ve read, with keen interest, all the discussions about macOS audio workgroups and I have workgroups now working on macOS. Is there anything similar on MS Windows? Or anything else to alert the OS scheduler of relationships between multiple audio processing threads?

Hi there,

Windows Vista introduced the “Multimedia Class Scheduler Service”. You can use AvSetMmThreadCharacteristics() with the string "Pro Audio" to signal to the OS that the thread is involved in real time processing for audio. My impression (from comments on the DAWBench podcast) is that people have had very mixed success with the API. That’s about where my knowledge ends, maybe someone else around here knows more?

After a brief search in the JUCE code, it seems like MMCSS is only used in the WASAPI backend.

Also, I stumbled on this that may point you towards more information:

One big issue is that we’re using MMCSS registration directly. Nowadays the much-preferred approach is to use a Media Foundation work queue; yes, you can use a Media Foundation work queue even if you’re doing WASAPI directly. The official WASAPI sample demonstrates how to use this approach.

Hope this helps. :slight_smile:

1 Like

Thanks very, very much.

I’ve added AvSetMmThreadCharacteristicsA() to my windows code and testing now. (I’m not sure how to get access to the ASIO soundcard driver thread before starting so for now I call AvSetMmThreadCharacteristicsA() inside the driver callback function; just in the first call.)


Glad I could help! :slight_smile:

The ASIO specification actually demands that the driver sets up MMCSS, so in principle what you’re doing shouldn’t make any difference. On the other hand, it seems that the RME drivers have a checkbox that allows the user to choose whether to enable it or not.

Here’s the relevant quote from the ASIO spec:

ASIO bufferSwitch() is usually implemented in its own thread, created by the driver. Thread execution is either invoked by event notification from the kernel driver or by issuing an APC in the thread context. The driver should set an appropriate high priority for the thread.

Starting with Windows Vista, Microsoft introduced the Multimedia Class Scheduler Service (MMCSS). 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”. This guarantees the highest execution priority for the bufferSwitch().

It lies within the sole responsibility of the ASIO driver to set the priorities of the threads it owns. An ASIO host shall by no means alter these priorities.

(You can find the document in the “ASIO SDK” ZIP file here: 3rd-Party Developers Support & SDKs | Steinberg)

Thanks again. Good point re the driver driver responsibilities. I’ve since turned my code (in the driver) off for now.