ao_wasapi: address premature buffer fills in exclusive mode

[sunpenghao]

This is also meant to fix #12615 but with more conservative changes to hopefully have an earlier merge into upstream (I know it's bad manner and practice, but the issue has been bugging me for quite some time 🥲, and it is actually very easily triggered). Different from #13434, the buffer space checks using IAudioClient_GetCurrentPadding and logic for resolving cascading buffer underruns are kept in case there are older Windows versions that behave differently.

To test, add for example the following key binding:

v set ao-volume 50

Press v while in playback with --ao=wasapi and --audio-exclusive=yes and notice the glitches and slowly accumulating A/V desync without this patch.

[sunpenghao]

ping @kasper93

[github-actions[bot]]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32

[sunpenghao]

Some more findings: IAudioClient_GetCurrentPadding in event-driven exclusive mode seems to be acting normally only on Bluetooth devices. Its return value never changes on an internal speaker and two other 2 USB DACs (UAC 2), and so running AO control while the renderer thread is in WASAPI_THREAD_FEED state will overwrite unprocessed samples. On Bluetooth headphones this issue is gone; we get 0 if no samples have been written, and 2 * bufferFrameCount if we write both buffers in a roll.