dmitrykos
commented
2 days ago @arkadijs thank you for opening this issue.
Indeed, it looks like a WASAPI specific behavior in relation to Loopback devices, i.e. if there are no Shared opened streams delivering audio data to WASAPI engine then Loopback device will not produce any audio data and therefore will timeout.
Besides your example the PA's test pa_loopback fails too PaQa_RunInputOnly() on attempt to capture data from Loopback WASAPI device.
The questions now are:
- leave this behavior as is and let client's code decide what to do with time out, whether to fill timed out buffer with silence or fail, and document this behavior in PA WASAPI-specific header or
- implement workaround in PA WASAPI to enforce silence if WASAPI Loopback device times out, or
- add additional PA WASAPI flag which would enforce filling buffer with silence in case of timeout.
Experiencing an issue with capture on WASAPI
[Loopback]device not progressing unless any audio playback is running on the corresponding output device. Not progressing: callback not called, synchronous API Read blocks forever,Pa_IsStreamActive()returns1-activeon a started stream. I have two Windows systems - 7 and 10, where all audio output devices exhibit this behavior - with Microsoft HD Audio driver, and one Windows 10 system - with Realtek driver, where capturing Speakers always works but Headphones requires active playback.My expectation is to receive silence steady when there is no playback.
If current behavior is expected behavior (of the underlying API), then I suggest this to be documented. If a workaround could be developed then it would be nice to have an explicit platform flag for
Pa_OpenStream()to enable it. In some use cases, this could be treated as a feature which may save processing, bandwidth, storage. But, given current inconsistent behavior, capturing loopback is confusing. (looked into reference, wiki, PR #672, and general search for clues)Test program here.
Tested current PortAudio
masterHEAD and PR #934. PortAudio built without DirectSound. MSYS2 ucrt64 GCC 14.1.Windows 7, Microsoft HD Audio driver, Core 2 Quad on Asus P5KC:
... HDMI playback:
Windows 10, Microsoft HD Audio driver, Intel Core i5 of Haswell generation (two S/PDIF outputs as intended):
... HDMI playback:
Windows 10, Realtek driver, Ryzen 5600H Lenovo laptop (here test program always call
Pa_ReadStream()to demonstrate blocking behavior):