Freezing when calling ma_device_start

[pajlada]

Hi, firstly thanks for providing this library 🙏

I'm the maintainer of Chatterino2 which is a Twitch chat client - we use miniaudio to play sound notifications.
We've had reports of a few users on Windows (latest one being on Windows 10 Version 2009, kernel: 10.0.19045) of miniaudio freezing when the first sound plays, forcing them to restart the application after which it works as expected.
I suspect this is something we do wrong in our application

The thread calling ma_device_start looks like this at the point of the freeze:

[0x0]   ntdll!NtWaitForSingleObject+0x14
[0x1]   KERNELBASE!WaitForSingleObjectEx+0x8e
[0x2]   chatterino!ma_event_wait__win32+0xe
[0x3]   chatterino!ma_event_wait+0x13
[0x4]   chatterino!ma_device_start+0xea

Another thread at the same time looks like this:

[0x0]   ntdll!NtWaitForSingleObject+0x14
[0x1]   KERNELBASE!WaitForSingleObjectEx+0x8e
[0x2]   MMDevApi!AXB::WaitForOperations+0x20e29
[0x3]   MMDevApi!CMediaNotifications::UnregisterMediaCallback+0xf8
[0x4]   MMDevApi!UnregisterMediaCallback+0x30
[0x5]   AUDIOSES!<lambda_d5b3f95b82e2c7512d1b98221445511f>::operator()+0x6b
[0x6]   AUDIOSES!CAudioClient::SetupAudioStreamWithAudioSrv+0x21290
[0x7]   AUDIOSES!CAudioClient::InitializeInternalHelper+0x105
[0x8]   AUDIOSES!CAudioClient::InitializeInternal+0x8a
[0x9]   AUDIOSES!CAudioClient::InitializeSharedAudioStream+0xf8
[0xa]   AUDIOSES!CAudioClient::InitializeSharedAudioStream+0x24
[0xb]   chatterino!ma_IAudioClient3_InitializeSharedAudioStream+0x27
[0xc]   chatterino!ma_device_init_internal__wasapi+0x9e5

The rest of the threads: https://rentry.co/d9mmz

Our initial miniaudio initialization happens once on startup, which doesn't freeze & runs through as expected for the user
https://github.com/Chatterino/chatterino2/blob/5c8c05b/src/controllers/sound/SoundController.cpp#L32-L134

When we try to play a sound, the device reports as stopped so we attempt to start it, which is what freezes, can be found here: https://github.com/Chatterino/chatterino2/blob/5c8c05b/src/controllers/sound/SoundController.cpp#L178-L224

We use an ma_engine for playing a custom sound if the user has selected one, or ma_sound_start for our built-in sound. Both share the same device.

Our repo's bug report as a reference: Chatterino/chatterino2#4832

[mackron]

This is a very strange one. I'm struggling to make sense of those call stacks. The ma_device_init_internal__wasapi() function is only called from ma_device_start(), or internally by a function called ma_device_reinit__wasapi() which is only called when the default output device changes (miniaudio will automatically reroute when the default device changes at the OS level). Is there nothing more to those call stacks? If there's more, can you post it in it's entirety?

The other thing I'm confused at is how these are even running in two separate threads. It doesn't look like you're doing any kind of threaded init/uninit/start/stop on your end, right? The ma_device_init() and ma_device_start() functions are explicitly synchronous so unless you're threading it yourself, there shouldn't be a situation where the device is being initialized and started at the same time.

The only thing I can think of off the top of my head is that maybe a device reroute is getting triggered by WASAPI when the device is started for some reason? But if that was the case I would have expected to see a ma_device_reroute__wasapi() in the call stack. This is all very strange.

Do you have a logging system? miniaudio has the ability to plug in a logging callback. I wonder if maybe that could be useful. You can plug a ma_log object into a ma_context_config object and then pass the config into ma_context_init(). ma_log_init() to initialize, ma_log_register_callback(pLog, ma_log_callback_init(my_log_callback, pUserData)) to register a callback.

On a bit of a side note, with your code, it's slightly unusual to be using ma_device_start/stop() manually instead of ma_engine_start/stop(), but I don't think that's the issue here. I also don't like your use of ma_engine_data_callback_internal, but again that's not causing this issue.

[pajlada]

Thanks for your quick reply & the feedback! I'll start by getting a build with logging and see what we can find out

[pajlada]

The rest of the seemingly relevant call stacks were posted here https://rentry.co/d9mmz but they don't seem to have anything interesting, if we are provided with another crash dump we'll provide a 100% callstack from there.
We don't do any threading for miniaudio at all, just initialize & play sounds in the main thread, with a thread guard making sure the functions are all called from the same thread.
I've built a version with logging that I'm providing to the user now, and will report back with any information I can find. Thanks again!