Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

switching device formats in exclusive mode can lead to irrecoverable audio device invalidation #1773

Closed
kevmitch opened this issue Apr 4, 2015 · 3 comments

Comments

@kevmitch
Copy link
Member

kevmitch commented Apr 4, 2015

This is the last remnant of #674. Even with all the device changed event monitoring, we are still unable to gracefully handle the following corner case:

  • Playing an exclusive mode pcm stream.
  • Enable/Disable loudness equalization via windows device control panel
  • ao_reload is requested, audio_reset is called
  • IAudioClient_Reset() returns E_HANDLE
  • IAudioClient_Stop() returns AUDCLNT_E_NOT_STOPPED
  • IAudioClient_Release() refuses to return so that
  • WaitForSingleObject(state->hAudioThread, INFINITE) never returns
@ghost
Copy link

ghost commented Apr 5, 2015

IAudioClient_Release() refuses to return so that

That's the most ridiculous thing I've ever read. Isn't this the IUnknown method? Why would it not return? It just decreases the refcount. Seems like either Microsoft broke their own crap big time, or your drivers are somehow broken, or there's a fatal bug in the ao_wasapi code.

@kevmitch
Copy link
Member Author

kevmitch commented Apr 5, 2015

Doesn't Release have to deconstruct the object when the refcount hits 0? My guess is that this final Release is calling some c++ monstrosity that could have a wait in there somewhere.

@ghost
Copy link

ghost commented Apr 5, 2015

If such a case happens, then the wasapi internals could reasonably just create an additional (internal) reference to it, rather than preventing the user from unreffing it.

kevmitch added a commit to kevmitch/mpv that referenced this issue Feb 26, 2016
The time-out was a terrible hack for marginally better behaviour when
encountering mpv-player#1773, which appears to have been resolved by a previous commit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant