mackron
commented
2 years ago This is a strange one. Not entirely sure what's going on here. When an overrun happens it means the captured data hasn't been processed fast enough by the application which results in the internal buffer used by WASAPI not having enough room for the newly captured data. When this happens, miniaudio tries to completely drain the buffer in order to avoid straddling the end of the buffer and never-ending glitching. It's essentially a full reset. I've added some additional debugging logs to this recovery process to the dev branch which might shed some light into what is happening during this recovery process. Are you able to get the user to try the version in the dev branch?
To test this on my side, I modified the simple_capture example to just sleep for a bit to simulate a slow data callback and the recovery process seems to work quite well. It's hard for me to tell what might be happening from here.
(If you're curious about the logic that's being used for recovery, you can do a search for if ((flags & MA_AUDCLNT_BUFFERFLAGS_DATA_DISCONTINUITY) != 0) { in miniaudio.h)
justinshannon
Hello,
Firstly, thank you for this great library. I converted from PortAudio, and it has been an absolute pleasure to use.
I use MiniAudio in a VOIP application. Each audio frame is 20ms (and the size is 960).
I have a user that is experiencing issues with their capture device ceasing to capture audio after 10-15 minutes (this is when the data discontinuity warnings start spamming the log file). There log file indicates the following:
The log is filled with over 150k lines of Data discontinuity warnings (the user let the application run for about 45 minutes). I provided the user with a build that forces the use of WinMM and they had no issues. When testing on my end, I get occasional data discontinuity warnings, but nothing to the extent that this user is getting.
In my application, I initialize the output and capture devices separately, instead of using duplex. I ran into a lot of issues with using the duplex mode, so I opted for separate devices. I didn't see anything in the documentation that would suggest this is a bad idea, so hopefully this is OK.
Here's a snippet of the playback and capture device initialization.
You can find the full implementation here: https://github.com/xpilot-project/afv-native/blob/master/src/audio/MiniAudioAudioDevice.cpp
I've tried increasing the period size, but it garbles the audio, since the program expects it a specific size.
I'm posting this in hopes that you might have an idea of what I can do to fix this? I guess worse case I can add a configuration option to let the user choose their preferred audio backend, in case the default doesn't work.
Thank you for your time!