Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
Offline.
Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
USB / ASIO
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 docs.microsoft.com. “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.
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.
Thanks,
Daniel.
[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