ASIO processing thread needs to be registered in Multimedia Class Scheduler Service

Core Machine (Operating system/System info/Roon build number)

Windows 10.0.18362 Build 18362

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)


Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)


Description Of Issue

The music chops when playing through ASIO. When tracing the operating system using the Windows Performance Analyzer (ETW events), I can see that the thread that process ASIO is not set as a high-priority thread, so pretty much any activity in the operation system (e.g., the Desktop Windows Manager) preempts the thread and as result, the music gets interrupted during some milliseconds.

You can fix this by increasing the priority for that thread or a better solution in Windows, is to register the thread in the “Multimedia Class Scheduler Service”, you can find code examples in “Pro Audio” level is the recommend one for software like Roon. If you do that, Windows will do a better work prioritizing the thread.

The audio processing thread for ASIO is created and owned by the ASIO driver, not Roon. Yes, it runs in a Roon-owned process, but that is because ASIO drivers load as COM in-process servers, not because it is actually our thread to muck with.

It is the ASIO driver’s decision how to configure scheduling for its thread. If we start mucking with this, we would be potentially changing the conditions under which the driver was developed and debugged. Keeping a menagerie of variable-quality ASIO drivers out there happy is no small task, and we do not generally like to put our fingers into them and risk breaking the experience.

In the case of WASAPI, we own the audio processing thread, and so we already use MMCSS as recommended.

I think that this feedback should be going to whoever authored the driver you are using, and not to us.

Give me one or two days to reply. Audirvana managed to fix the audio glitch, I thought it would be the same problem.

I’ll take a trace following



I’ll find a way to give the feedback to the ASIO driver developer.

Audirvana seems to be changing the thread characteristics in one of the ASIOCallbacks[1], that happens only once, the first time I play a song. It is a pragmatic approach.

I understand you are trying to minimize risk.

From what I can read, the AvSetMmThreadCharacteristics just tries to connect to the MMCSS service and the service will track that ‘client’ thread request with the “Pro Audio” task name. This will effectively override a previous call, but at the same time it would ideponent as ASIO driver should register as “Pro Audio”, do nothing (as the ASIO driver) or bump the thread priority. Thread prioirty + MMCSS shouldn’t be a problem but it is hard to be sure with the amount of ASIO drivers around.

Of course, I’m unable to use Roon, I can play a PCM file if I don’t touch the PC, but if I try to play DSD64, 128, 256, 512 it is just simply impossible.



[1] 0:043> kp
# Child-SP          RetAddr           Call Site
00 0000000e`0f23fa18 00007fff`840719a8 AVRT!AvSetMmThreadCharacteristicsA(char * TaskName = 0x00007fff`84a46fc0 "Pro Audio", unsigned long * TaskIndex = 0x0000000e`0f23fac8) [avcore\rt\avrt\api.c @ 51] 
01 0000000e`0f23fa20 00007fff`99061cc9 AudirvanaPlusApp+0x1719a8 <- no pdb
02 0000000e`0f23fab0 00007fff`99062054 c3asio64!DllUnregisterServer+0xb49 <- no pdb
03 0000000e`0f23fae0 00007fff`99066f71 c3asio64!DllUnregisterServer+0xed4 <- no pdb
04 0000000e`0f23fb10 00007fff`d0d67bd4 c3asio64!DllGetClassObject+0x33c1 <- no pdb
05 0000000e`0f23fbe0 00007fff`d1dace71 KERNEL32!BaseThreadInitThunk

What is the driver and device? Googling c3asio64 doesn’t get me to an obvious answer.

Unbranded DAC with ES9028PRO.


Amanero got back to me so I’m working with them. Thanks Brian for following up.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.