mpv-player/mpv — pull request #1259 by kevmitch (2014-11-09 09:32:03+00:00)
Title: [WIP] Implement device notifications for wasapi (revised)

Currently wasapi ao hangs the player when audio properties such as sample rate or effects are changed during playback. This PR implements the necessary machinery to properly handle such changes and allow playback to keep going. When the ao_wasapi feed thread is notified of a device change, it sends an ao_request_reload which shortly terminates it and starts a new one.

With a single mpv instance this has been tested to work quite well changing the "shared mode" sample rate/bit depth. I don't currently have a second sound-card set up, so I have not been able to test if it will properly reroute to a the remaining device when the one playing is disabled or disconnected, though this is supposed to work.

Unfortunately (and oddly), if I have two mpv instances running simultaneously and change the shared mode sample rate several times. One of the instances will hang by around the 10th change. Interestingly, it's feed thread continues to receive change notification.

replaces #1257

## new information

It turns out that the above described hang is happening in the polling loop in audio/out/pull.c:reset which never completes.

Another problem that I hadn't noticed previously is that if you turn effects on and off several times even with only one mpv instance, sometimes one of the wasapi calls during the reinit, or even shortly after the threadloop has started will return AUDCLNT_E_DEVICE_INVALIDATED and the whole program will either crash or hang.

Likely the latter problem is that we're actually reiniting too quickly and the device properties are still changing during and shortly after the reinit.