Windows 7: changing sound device properties mid-playback causes mpv to hang

[kevmitch]

• On Windows 7 start mpv playing something.
• Right click the speaker/volume control in the taskbar->playback devices.
• Right click the current playback device->properties
• Click "Enhancements" tab
• Check (or uncheck if it's already checked) "disable all enhancements"
• Click apply
• mpv hangs with no message output even if started with "-v"

pause/unpause results in the command line output

  [ao/wasapi] thread_feed fails with 88890004!

"q" closes mpv as expected, so the hang isn't that bad.

The same thing happens changing settings in the "Advanced" tab.

[ghost]

<Kovensky> seems http://msdn.microsoft.com/en-us/library/windows/desktop/dd316605%28v=vs.85%29.aspx isn't implemented

[ghost]

Needs someone to fix this, ping @Kovensky

[ghost]

Apparently nobody cares, I don't either.

[kevmitch]

This is still a legitimate reproducible bug. Just because nobody knows how to fix it doesn't change that.

[ghost]

This is still a legitimate reproducible bug. Just because nobody knows how to fix it doesn't change that.

True, but it clogs the bug list for no reason.

[ghost]

PS: as a half-measure, I already moved ao_dsound above ao_wasapi in the list of preferred audio drivers. dsound doesn't appear to have this problem, and works just as well.

[kevmitch]

Indeed dsound doesn't have the problem. It would be nice to get the wasapi ao up the the same level though. I'm trying to figure out where exactly this is going wrong.

To summarize the progression of the behaviour is

1. playing normally
2. click "apply" in speaker properties after making changes
3. hangs with no error output. --msg-level=all=trace right before the hang. While it's hanging, audio and video freeze and the following lines just keep repeating:

statusline: AV: 00:00:12 / 02:04:34 (0%) A-V: -0.060 Late: 7 Cache: 86.98%
cplayer: update_video: 2
cplayer: frametime=0.050
cplayer: audio delay=0.200000
statusline: AV: 00:00:12 / 02:04:34 (0%) A-V: -0.060 Late: 7 Cache: 86.98%

breaking gdb always says I'm at input/input.c:1020. I guess it's picking up my break key-press (which still seems to happen with --no-input-terminal.)

There doesn't appear to be any abnormal condition in the last call to ao_wasapi.c:thread_feed (marked by "ao/wasapi: device delay: 2860 samples (29.7917 ms)"). There are no futher calls to anything inside ao_wasapi.c after that.

4. It's only after pausing/unpausing that the error message "thread_feed fails with 88890004!" appears. This is likely the error condition AUDCLNT_E_DEVICE_INVALIDATED described in the msdn article above.

So even if AUDCLNT_E_DEVICE_INVALIDATED triggered an ao reset, it would still require a pause/unpause to escape the hang to actually get to a place where the error could be detected.

This is as far as I've been able to get. I'm not sure how to catch and detect this error if there's no sign of it in the mpv wasapi code until after the pause/unpause.

[ghost]

breaking gdb always says I'm at input/input.c:1020. I guess it's picking up my break key-press (which still seems to happen with --no-input-terminal.)

At that line is the select() call, which is where the playback thread waits if there's nothing else to do.

Maybe the player thinks it still has some audio to play, and ao_wasapi always returns the same status.

[kevmitch]

Oh, here we go. It looks like the last place the wasapi code is seen is ao_wasapi.c:125

waitstatus = MsgWaitForMultipleObjects(3, playcontrol, FALSE, INFINITE,
                                           QS_POSTMESSAGE | QS_SENDMESSAGE);

It's waiting forever for playcontrol (namely state->hFeed) that never signals because the audio device has be deinitialized.

[kevmitch]

it should probably be signalling state->hUninit, but for some reason doesn't

[kevmitch]

What a pain in the ass: the exclusive mode example isn't self contained. It expects you to create your own data source. I linked the exclusive mode example above, because it also uses
event-driven buffering mode.

That code seems to only wait for the handle set by IAudioClient_SetEventHandle. The hUninit is only triggered manually by the ao_wasapi code in mpv.

At this stage, it seems that the best thing to do would be have a non-infinite timeout on the MsgWaitForMultipleObjects and have a separate swtich clause for it.

[kevmitch]

I also give up.