search

dechamps / FlexASIO

A flexible universal ASIO driver that uses the PortAudio sound I/O library. Supports WASAPI (shared and exclusive), KS, DirectSound and MME.
Other
1.35k stars 72 forks source link

FlexASIO does not work well with Qobuz or my EF500 DAC/amp #220

Open darkenwarlock opened 7 months ago

darkenwarlock commented 7 months ago

WASAPI exclusive mode is full of stutters no matter what the suggested latency and buffer size is. When switching to WDM-KS mode, the first few times I would get bluescreens whenever I started to play audio giving me "WDF Violation." This has happened both with my old Realtek internal sound card, and with the brand new Hifiman EF500 DAC/amp which I just got. I switched to FlexASIO because ASIO4ALL was stuck at 16 bit output even though my DAC supports up to 32 bits, 24 natively. I even confirmed this upon checking the ASIO4ALL log file as the pins reported back support for up to 32 bits on the device.

So, switching to FlexASIO, it does not seem to really work at all with this DAC except in WASAPI Exclusive mode with no suggested latency or buffer size set. However, in WDM-KS mode, I either bluescreen upon playing audio with Qobuz, or I get the "This is not a recognized device" error in Qobuz. I am not sure if this is a problem with Qobuz itself or FlexASIO.

Screenshot 2024-03-06 002117 Screenshot 2024-03-06 002312

dechamps commented 6 months ago

WASAPI exclusive mode is full of stutters no matter what the suggested latency and buffer size is.

Yeah, sadly, the WASAPI backend code could probably use some work. And the WDM-KS backend is in an even worse state I'm afraid, suffering from severe issues like PortAudio/portaudio#763.

When switching to WDM-KS mode, the first few times I would get bluescreens whenever I started to play audio giving me "WDF Violation."

This points to a bug in the Windows audio device driver. Userland code (which includes applications, and FlexASIO) cannot be held responsible for BSODs, although they can indirectly trigger them by surfacing pre-existing bugs in device drivers that do not correctly check userland inputs.

WDM-KS triggering bugs in drivers is not too surprising given WDM-KS allows apps to talk directly to device drivers, leaving them exposed to code paths that would not normally be taken when the audio device is being used in the "normal" way (i.e. through the standard Windows audio stack).

darkenwarlock commented 6 months ago

WASAPI exclusive mode is full of stutters no matter what the suggested latency and buffer size is.

Yeah, sadly, the WASAPI backend code could probably use some work. And the WDM-KS backend is in an even worse state I'm afraid, suffering from severe issues like PortAudio/portaudio#763.

When switching to WDM-KS mode, the first few times I would get bluescreens whenever I started to play audio giving me "WDF Violation."

This points to a bug in the Windows audio device driver. Userland code (which includes applications, and FlexASIO) cannot be held responsible for BSODs, although they can indirectly trigger them by surfacing pre-existing bugs in device drivers that do not correctly check userland inputs.

WDM-KS triggering bugs in drivers is not too surprising given WDM-KS allows apps to talk directly to device drivers, leaving them exposed to code paths that would not normally be taken when the audio device is being used in the "normal" way (i.e. through the standard Windows audio stack).

Thank you for the reply! Also, yes, I'm not blaming the issue on you, and I understand the BSOD is caused by an issue with the driver. I just thought I would report this as I did not know if it has already been reported or not. I will e-mail the DAC developer and see if they plan on a proprietary driver as it currently uses a default Windows audio driver.

Thank you for the reply though. I appreciate it!