-
-
Notifications
You must be signed in to change notification settings - Fork 337
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
Crashes in MMDevAPI.dll #758
Comments
Some extra info: Even when I wait 10s between plugging the device in and switching the device in software the crash still happens sometimes. So around when the device is being stopped or restarted. |
It seems that changing the Also, is there a way to change the EDIT2: It doesn't actually help that much, guess I was just lucky the first couple of times. If you have any idea how to proceed please let me know. |
This is annoying. I'm at a bit of a loss with this one. Some clarification on a few things. How are you detecting that the preferred device has changed? Are you calling Does the crash happen in direct response to My initial thought was that maybe WASAPI is calling |
I have a thread on a loop that detects the currently used device vs the preferred device. It then looks in the list of available devices to see if the preferred device is available. In that thread I do call
Yes indeed
There is no miniaudio functions in the call stack that is causing the crash. I can find a couple of other threads which all seem to be waiting for a lock or semaphore. Sometimes there is a thread which is in
Testing some more, I see that the thread where my code runs is on the |
Do you have any ideas? |
No I don't have any ideas yet and I haven't had a chance to properly look at this.
How are you actually doing this though? What specific functions are you calling? Are you using miniaudio to do this? |
I am using miniaudio for that indeed, using the following functions: if (ma_context_get_devices(&audioDeviceContext, &maPlaybackDevices, &playbackCount, &maCaptureDevices, &captureCount) == MA_SUCCESS)
{
for (uint32_t i = 0; i < playbackCount; i++)
{
<here the playback device data is read and stored in our own struct>
}
<same as above put for capture devices>
} |
I see you mention threading issues with wasapi in #777. Might that also be causing the problems here? |
I'm not sure. It feels a bit different but hard to know. My experience with WASAPI has been that it's been very thread-hostile. I've had it where it'll crash when it does something on a different thread even though I've very clearly got valid mutual exclusion going on. I think WASAPI wants you to do absolutely every single WASAPI related operation on a single thread, even if you're using your own syncing. I have a known memory leak in the WASAPI backend when doing automatic rerouting because as soon as I uninitialize the previous device handle it'll deadlock, even though I've got it mutually excluded. What I think I need to do is have a single worker thread and then just defer to that thread via an event queue or something and invoke all WASAPI functions from there. That'll require a very significant refactor to the WASAPI backend though, and I'm not even sure it'll fix either of these issues. |
Thanks for the info. I'm considering trying to disable WASAPI and using a different driver on Windows, maybe I'll have more luck with that. |
I know this ticket is quite old now, but this might be related to this one: #764. I released a fix for that a while ago but forgot to mention it here. If this ticket is still an issue for you, it might be worth trying the dev branch. |
Hi,
I am trying to switch Audio devices when an audio device gets plugged in on Windows. I do this by checking if the current device is different from a set preferred device, and if so stopping the audio and restarting it with a different
pDeviceID
. This results in crashes of the program inMMDevAPI.dll
because of access violations. In the callstack I see the last function isMMDevAPI.dll!CDeviceEnumerator::OnPropertyValueChanged()
.Globally speaking, my code does this:
See some logs below:
If I add a sleep between detecting the new device and switching to it, it will take more add/remove cycles before the crash happens, but it will still happen. It can also happen both when adding or removing the device.
I haven't tried to make a minimal reproduction to share yet as I wanted to first see if you have any ideas. If not, I can try to reproduce this issue in some files I can share.
The text was updated successfully, but these errors were encountered: