Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
darkenwarlock opened this issue Mar 6, 2024 · 2 comments
Open

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

darkenwarlock opened this issue Mar 6, 2024 · 2 comments
Labels
bug portaudio Requires changes in PortAudio upstream.

Comments

@darkenwarlock
Copy link

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
Copy link
Owner

dechamps commented Mar 6, 2024

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).

@dechamps dechamps added bug portaudio Requires changes in PortAudio upstream. labels Mar 6, 2024
@darkenwarlock
Copy link
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug portaudio Requires changes in PortAudio upstream.
Projects
None yet
Development

No branches or pull requests

2 participants