AAUDIO_ERROR_TIMEOUT when screen turns off during initialization

[znakeeye]

On Android 13, in an orx game, I'm experiencing a problem when screen is automatically turned off during app initialization. So far, I have quite limited information, but it goes something like this:

1. Android app is debugged via Android Studio.
2. A breakpoint is hit, I think a bit, and then continue debugging. (This step is important!)
3. During this short period, the screen on my Pixel 6 is automatically turned off.
4. I unlock the screen and then see my game, but no sound! But there is a clue in logcat:

[INFO] [AAudio] ERROR CALLBACK: error=-885, AAudioStream_getState()=4

5. Soft-restarting the app will not help. I have to kill it and re-run it to get the audio back.

It's a bit unclear if the audio was successfully initialized before the screen turned off. Not sure how to determine that, but at least there are no other audio errors reported...

Miniaudio bug or incorrect integration?
Error -885 corresponds to AAUDIO_ERROR_TIMEOUT. Not sure where this comes from, but obviously it is not handled properly. Either there is a bug in miniaudio or we have a flawed integration in orx. Please excuse me if this is an obvious error in orx.

Reading the above, is it possible to get some ideas of what is going on? If on Windows, I could probably set up a sample project to be debugged in Android Studio.

[mackron]

Thanks for the report. Strange one. I wonder if maybe I should just stop the device in this case? I'm the error callback where that error is fired, the device is stopped if it detects that the device is in a disconnected state (as recommended by the AAudio documentation). Maybe it should do the same thing in this timeout case? I'm not entirely sure how to handle it to be honest.

[znakeeye]

Where can I put a breakpoint to see where this AAUDIO_ERROR_TIMEOUT should (or shouldn't) be handled? Haven't really worked with miniaudio before. Thanks.

There are a few (very few) clues regarding this timeout error. For instance, some libraries out there - e.g. oboe - seem to have adapted their status checks due to google issue 173928197. Read the oboe changelog regarding this here and check their workaround in AudioStreamAAudio.cpp.

Apparently, that bug only appears on API level 30 (I'm targeting 31). Still, it's an indication that there might be some odd cases where a timeout error is a real thing. Not sure if I'm facing that very error, or if this is another similar edge case.

[mackron]

There's a function called ma_stream_error_callback__aaudio(). You'll see where I'm posting the log there.

From the Oboe link you pointed to, they mention this:

We recommend always stopping and closing the stream regardless of the error code.

So I guess that's consistent with my line of thinking with my previous comment about stopping the stream when we get the timeout?

[znakeeye]

Ah, now I see. You check for MA_AAUDIO_STREAM_STATE_DISCONNECTED. So if I comment out that if statement, it might work?

[mackron]

Yeah I'm wondering if we get an error (i.e. the error callback gets fired) we just stop the device in all cases?

[mackron]

Although, just looking more closely, my code actually reinitializes it rather than just stopping it. That is probably in response to things like headsets getting connected/disconnected so that the audio is rerouted.

[znakeeye]

Looking at the existing AAUDIO_ERROR_* codes, they all sound quite bad to me. Just confirmed that commenting out that if statement allows my app audio to successfully re-initialize when I turn on the screen!

No more guessing then. That if statement should most likely be removed. Some 20 bytes to be stripped from your super slim audio library! 😎

[mackron]

Thanks for checking that. I've pushed a change to the dev branch. Are you able to give that a try just to check that's I've not messed it up?

[znakeeye]

Yep, the dev version of miniaudio.h works 👍

[mackron]

Thanks for verifying that for me. This will be out in the next release.

[znakeeye]

Np! When is the next release planned?

[mackron]

Not really sure. I think I've accumulated a few fixes by this point so I should get it out in the next few days I guess.

[znakeeye]

Still no release. When is it planned? 🙂