WASAPI backend dropouts

[GoldenSound]

I've been unable to get the WASAPI backend to work on any of my machines. Audio will play, but will cut in and out at a rate of about 6x per second. I'm unable to get useable audio out regardless of the PC being used or the audio device I'm trying to feed.

Feeding the same device via WASAPI exclusive from any other program works fine

My config is:

backend = "Windows WASAPI"
[input]
[output]
device = "Speakers (HIFIMAN-EF400)"
wasapiExclusiveMode = false
wasapiAutoConvert = true

[GoldenSound]

Here is a log of a quick playback which encounters this issue
FlexASIO.log

[dechamps]

Note that the config you posted in your report is wrong. According to the log, your actual config was:

backend = "Windows WASAPI"

[input]

[output]
device = "Speakers (HIFIMAN-EF400)"
wasapiAutoConvert = false
wasapiExclusiveMode = true

Your log indeed shows highly abnormal stream callback timing. Instead of the expected regular 20ms cadence, the callback follows an abnormal periodic pattern where it fires 4 times in quick succession, followed by a ~80ms gap. Aside from that, the log looks fine so it's not clear to me why that's happening.

I see that you're using Audio Precision as the ASIO host application. In #136 a similar issue with AP was reported. I strongly suspect this problem is host-application-related but the strange thing is that the symptoms do not suggest the application is at fault (the gaps occur on the FlexASIO side - it's not the app that's blocking the streaming thread, or at least not directly).

It would be interesting to see the following:

• A FlexASIO log captured while FlexASIOTest is running, with the same FlexASIO config, to confirm this is related to this specific host application (AP).
• Do you see the same problem with WASAPI Shared? What about the default DirectSound backend? It would be interesting to see FlexASIO logs with AP running with these configs.

[GoldenSound]

Note that the config you posted in your report is wrong. According to the log, your actual config was:

backend = "Windows WASAPI"

[input]

[output]
device = "Speakers (HIFIMAN-EF400)"
wasapiAutoConvert = false
wasapiExclusiveMode = true

Your log indeed shows highly abnormal stream callback timing. Instead of the expected regular 20ms cadence, the callback follows an abnormal periodic pattern where it fires 4 times in quick succession, followed by a ~80ms gap. Aside from that, the log looks fine so it's not clear to me why that's happening.

I see that you're using Audio Precision as the ASIO host application. In #136 a similar issue with AP was reported. I strongly suspect this problem is host-application-related but the strange thing is that the symptoms do not suggest the application is at fault (the gaps occur on the FlexASIO side - it's not the app that's blocking the streaming thread, or at least not directly).

It would be interesting to see the following:

• A FlexASIO log captured while FlexASIOTest is running, with the same FlexASIO config, to confirm this is related to this specific host application (AP).
• Do you see the same problem with WASAPI Shared? What about the default DirectSound backend? It would be interesting to see FlexASIO logs with AP running with these configs.

Yep sorry the config you posted is correct (and the one I was intending to use). Accidentally copied a different config which was after I'd changed settings whilst troubleshooting.

Ok so current config is:

[input]
[output]
device = "Speakers (HIFIMAN-EF400)"
wasapiExclusiveMode = true
wasapiAutoConvert = false

Here is a log with FlexASIOTest
FlexASIO Test WASAPI Exclusive.log

Changing config to WASAPI shared:

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

The result with FlexASIOTest is:
FlexASIO Test WASAPI Shared.log

The DirectSound backend works, as does WDM-KS, it's only WASAPI exclusive that has the dropout issue and ONLY from FlexASIO. Other software plays to the same device via WASAPI exclusive without issue.

The Directsound backend is unfortunately not an option for me due to not being bitperfect. I explicitly need a bitperfect pipeline for my use case.
WDM-KS works, but with the problem experienced in issue 178 where I cannot change sample rate

[dechamps]

The two logs you posted look normal. Since FlexASIOTest is unaffected, that means the problem occurs only when the AP host application and the FlexASIO WASAPI backend are used in combination. That's… really weird. My best guess at this point is that the AP app interferes with WASAPI thread scheduling, but I have no clue how that could possibly happen.

I think it will be hard to troubleshoot this without me being able to reproduce the issue myself - the cause could be pretty much anything at this point. And I'm afraid I don't have the luxury of having an AP to test with.

I guess one thing you can do yourself is gather a detailed WPA trace which would show what the streaming thread is stuck on, and then get me that trace, but I must warn you this is likely going to get quite tedious. If you're willing to do that, here's the procedure:

1. Open the Windows Performance Recorder (which is normally pre-installed on all Windows systems)
2. Set it like this:
   
   • Also check "Audio glitches" under "Scenario Analysis"
3. Open AP and be ready to reproduce the problem.
4. In WPR, click Start, then reproduce the problem in AP, play ~5 seconds of glitchy audio, then click Save in WPR. Make sure to keep WPR captures short as they get very big very quickly.
5. Use the file sharing service of your choice to send the capture to [email protected]. Do not share it publicly as WPR captures everything going on in the system, including potentially private information.