AAudio streams not restarted on timeout

[liamwhite]

There is code here to restart the stream on device disconnection. It should also restart on AAUDIO_ERROR_TIMEOUT, because this otherwise makes stepping programs which use audio in Android Studio impractical. https://github.com/mozilla/cubeb/blob/30efcd1cdf8a794e918fe2c6e9b74c8ea8bbcdd6/src/cubeb_aaudio.cpp#L916-L931

When the stream times out, audio callbacks stop getting called. If a program depends on audio samples continuing to get consumed by the callback, it will freeze at this point as the thread sinking audio has exited and won't get restarted.

[padenot]

Thanks for the report. Interestingly, I haven't had the issue, and I've attached lots of debuggers to the real-time AAudio thread lately (on a real device, Pixel 4 / Android 13), maybe I got lucky.

I see that this can happen in two locations in current Android sources (I'm not sure what version you're using):

https://cs.android.com/android/platform/superproject/main/+/main:frameworks/av/media/libaaudio/src/client/AudioStreamInternalPlay.cpp;l=307;drc=8f3f4897ea6dd3f19bb378daed2146a5bebb95ec https://cs.android.com/android/platform/superproject/main/+/main:frameworks/av/media/libaaudio/src/core/AudioStream.cpp;l=461;drc=8f3f4897ea6dd3f19bb378daed2146a5bebb95ec

So if waitForStreamChange "really" times out (depending on the value of the timeout parameter), or if the AAudio implementation fails to write all the than the expected audio frames that the user callback gave it, to the system.

[padenot]

Also, only the first occurrence can result in this code being reached: the second one is returned synchronously to the API caller.

We don't even check the return value of the second occurrence (we log a message, but fail to do anything meaningful afterward).

I'll do something a bit better while I'm in the area.