sjoerdvankreel
commented
2 years ago Hey,
the Raise/RevertThreadPriority functions are meant to be used in combination with the Linux PulseAudio and ALSA backends only. On Windows, things work a bit different:
- For ASIO, the ASIO driver is responsible for creating the audio thread, and hence manage it's priorities. The ASIO backend doesn't even pass through Raise/RevertThreadPriority so I'm assuming you're either on WASAPI or DirectSound for this change to have any effect.
- For WASAPI, the preferred way to manage thread priorities is to use the multimedia class scheduler service (mmcss), which will dynamically boost thread and process priorities as needed without hogging up the rest of the system. See https://docs.microsoft.com/en-us/windows/win32/procthread/multimedia-class-scheduler-service. This is implemented in WasapiStream::StartMasterBuffer using AvSetMmThreadCharacteristicsW. See https://github.com/sjoerdvankreel/xt-audio/blob/master/src/core/xt/xt/backend/wasapi/Stream.cpp. I'm pretty sure your changes render the use of MMCSS meaningless as the audio thread is now always at the maximum priority.
- For DirectSound, thread priority is already set to THREAD_PRIORITY_TIME_CRITICAL in DSoundStream::StartMasterBuffer, see https://github.com/sjoerdvankreel/xt-audio/blob/master/src/core/xt/xt/backend/dsound/Stream.cpp. This is done without changing the process priority though.
So, I think the net effects of your proposed change are: 1) For WASAPI, get in the way of MMCSS 2) For DirectSound, raise the entire process prio to realtime 3) For both of them, hog the rest of the system
As it stands this is a less-than-ideal solution. What backend are you actually using? I'm guessing it's DirectSound since that's the only one that relates the audio thread to an application window, see https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ee418049(v=vs.85). If so, please keep in mind that DirectSound is not in any way suitable for high-performance/low latency audio (it has a relatively large overhead compared to asio and wasapi, especially wasapi exclusive mode). So for DSound you should probably just raise the buffer size (might even be as high as a couple 100 ms). If it's WASAPI, then it seems MMCSS isn't doing it's job properly, which is to keep your audio stutter-free while still not interfering with the rest of the system too much. If that's the case we can add an option to the wasapi backend to use EITHER realtime process priority class or MMCSS, but not both. However then we'd have to investigate a little further on why MMCSS isn't doing it's job before bringing out the big guns.
Edit: if you are in fact using WASAPI in shared mode, could you change WasapiStream::StartMasterBuffer() to always use "Pro Audio" and see if this helps? I would much prefer letting the user pick the MMCSS task name instead of messing with the process prio directly, seeing as this affects all threads in the process.
Edit2: when you say cpu benchmark, do you mean pushing the limits of the audio thread or something external to the process hosting xt-audio?
LuzianU
When the java application on Windows is out of focus, the audio starts crackling slightly. This can be pushed to the extreme when running a light CPU benchmark, rendering the audio completely unusable due to constant audio stutters.
I'm not entirely sure if this is the way to change thread priorities on Windows, however this completely removes all audio stutters even on very high CPU usage.