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

Cannot change sample rate when using WDM-KS Backend #178

Closed
GoldenSound opened this issue Jan 19, 2023 · 6 comments
Closed

Cannot change sample rate when using WDM-KS Backend #178

GoldenSound opened this issue Jan 19, 2023 · 6 comments

Comments

@GoldenSound
Copy link

Title pretty much says it all.
I have devices supporting upto 384khz, and via the WDM-KS backend I'm able to play to them, but cannot get FlexASIO to change sample rate.

Any attempt to set it to for example 48hz instead of 44.1khz fails.

FlexASIO SampleRate.log

@dechamps
Copy link
Owner

Does the same problem occur with FlexASIOTest? FlexASIOTest will probe a list of common sample rates and report back.

@GoldenSound
Copy link
Author

Does the same problem occur with FlexASIOTest? FlexASIOTest will probe a list of common sample rates and report back.

Running FlexASIOTest with the same config

[input]
[output]
device = "Speakers (HIFIMAN-EF400)"

Produces this resulting log:

FlexASIO Test WDM-KS.log

@dechamps
Copy link
Owner

In that log WDM-KS doesn't work at all, and I suspect the reason is because Speakers (HIFIMAN-EF400) happens to also be your default Windows audio output device. WDM-KS typically doesn't work on the default audio device because the Windows Audio Engine keeps a KS handle open on that device, preventing any other KS client from using it. You will want to change the Windows default audio device selection to release the device and then run the test again.

@GoldenSound
Copy link
Author

In that log WDM-KS doesn't work at all, and I suspect the reason is because Speakers (HIFIMAN-EF400) happens to also be your default Windows audio output device. WDM-KS typically doesn't work on the default audio device because the Windows Audio Engine keeps a KS handle open on that device, preventing any other KS client from using it. You will want to change the Windows default audio device selection to release the device and then run the test again.

Ah whoops!

Ok so just in case it's useful context, I've just done a completely clean install of Windows 10. Wiped the HDD entirely including all recovery/manufacturer partitions and installed fresh with NOTHING installed other than FlexASIO and the AP software. I did also try installing my music player 'roon' but only after verifying the issues were still present. Issues seem to affect my music player in exactly the same manner, with FlexASIO set to use WASAPI causing the rapid cutting in/out, and WDM-KS unable to change sample rate.

Redid the test (making sure that the device was not the windows default device) and the log is below:
FlexASIO.log

@dechamps
Copy link
Owner

Okay that last log is a bit more interesting:

--- ENTERING CONTEXT: getLatencies()
GetLatencies() called before CreateBuffers() - attempting to probe streams
[...]
CFlexASIO::OpenStream(inputEnabled = 0, outputEnabled = 1, sampleRate = 44100, framesPerBuffer = 882, callback = 00007FFCA7944CF0, callbackUserData = 0000000000000000)
Opening PortAudio stream with...
...input parameters: none
...output parameters: PortAudio stream parameters for device index 23, 2 channels, sample format 2147483649 [Float32, NonInterleaved], suggested latency 0.06s
...sample rate: 44100 Hz
...frames per buffer: 882
...stream flags: 8 [PrimeOutputBuffersUsingStreamCallback]
...stream callback: 00007FFCA7944CF0 (user data 0000000000000000)
[PortAudio] OpenStream:sampleRate = 44100.000000
[PortAudio] OpenStream:framesPerBuffer = 882
[PortAudio] Pin create result = 0x00000000
[PortAudio] Render pin frames: 0
[PortAudio] Output frames chosen:2646
[PortAudio] PinGetBuffer: SubType_kNotification
[PortAudio] Output buffer start = 0000025A90E90000, size = 42336, membarrier = 0
[PortAudio] BytesPerInputFrame = 0
[PortAudio] BytesPerOutputFrame = 8
[PortAudio] Failed to register position register
[PortAudio] Failed to register rendering position register, using PinGetAudioPositionViaIOCTLRead
PortAudio stream opened: 0000025A8F004910
Stream info: PortAudio stream info version 2, input latency 0s, output latency 0.06s, sample rate 44100 Hz
882 samples added to output latency due to the ASIO Host Application not supporting OutputReady
Closing PortAudio stream 0000025A8F004910

[...]

--- ENTERING CONTEXT: canSampleRate()
Checking for sample rate: 44100
Checking if output supports this sample rate
CFlexASIO::OpenStream(inputEnabled = 0, outputEnabled = 1, sampleRate = 44100, framesPerBuffer = 0, callback = 00007FFCA7944CF0, callbackUserData = 0000000000000000)
Opening PortAudio stream with...
...input parameters: none
...output parameters: PortAudio stream parameters for device index 23, 2 channels, sample format 2147483649 [Float32, NonInterleaved], suggested latency 0s
...sample rate: 44100 Hz
...frames per buffer: 0
...stream flags: 8 [PrimeOutputBuffersUsingStreamCallback]
...stream callback: 00007FFCA7944CF0 (user data 0000000000000000)
[PortAudio] OpenStream:sampleRate = 44100.000000
[PortAudio] OpenStream:framesPerBuffer = 0
[PortAudio] Pin create result = 0x00000000
[PortAudio] Render pin frames: 0
[PortAudio] Output frames chosen:0
[PortAudio] Failed to get buffer with notification
[PortAudio] Failed to get buffer without notification
[PortAudio] Buffer size on 128 byte boundary, still fails :(
[PortAudio] Failed to get output buffer (with notification)
Output does not support this sample rate: unable to open PortAudio stream: Unanticipated host error
Sample rate 44100 is unavailable

It looks like sample rate probes are indeed broken in your scenario. More specifically I get the impression that the PortAudio WDM-KS backend does not handle Pa_OpenStream(paFramesPerBufferUnspecified) properly. The reason why FlexASIO works with the default sample rate is because paFramesPerBufferUnspecified is only used for sample rate probes, not for the actual streaming.

The good news is, I was actually able to reproduce this just now. The twist is that this only seems to happen with devices that use WinRT-based drivers. I'd expect most modern devices to use WinRT though, so yeah… that's a pretty big problem.

This is most likely a bug somewhere in the PortAudio WDM-KS backend code. I'll try to see if I can dig it out. Worst case scenario it should be possible to work around this by using some dummy framesPerBuffer parameter instead of paFramesPerBufferUnspecified.

@dechamps dechamps added bug portaudio Requires changes in PortAudio upstream. labels Jan 20, 2023
@dechamps dechamps pinned this issue Jan 20, 2023
@dechamps
Copy link
Owner

Actually I just realized that #159 is the exact same problem, so closing this one as duplicate.

@dechamps dechamps added duplicate and removed bug portaudio Requires changes in PortAudio upstream. labels Jan 20, 2023
@dechamps dechamps closed this as not planned Won't fix, can't repro, duplicate, stale Jan 20, 2023
@dechamps dechamps unpinned this issue Jan 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants