LibretroDroid
LibretroDroid copied to clipboard
AudioTrack crashes on earphones connect
Upon connecting Bluetooth earphones while the game is open, the AudioTrack crashes and fails to restart automatically:
2020-10-18 16:09:18.035 22078-22100/com.draco.libretrowrapper.megaman3 D/AudioStreamLegacy: onAudioDeviceUpdate() devId 3 => 2456
2020-10-18 16:09:18.035 22078-22100/com.draco.libretrowrapper.megaman3 D/AudioStreamLegacy: onAudioDeviceUpdate() request DISCONNECT in data callback due to device change
2020-10-18 16:09:18.046 22078-22215/com.draco.libretrowrapper.megaman3 D/AudioStreamLegacy: checkForDisconnectRequest() mRequestDisconnect acknowledged
2020-10-18 16:09:18.046 22078-22215/com.draco.libretrowrapper.megaman3 W/AudioStreamLegacy: processCallbackCommon() data, stream disconnected
2020-10-18 16:09:18.046 22078-22215/com.draco.libretrowrapper.megaman3 E/AudioTrack: processAudioBuffer(2445): EVENT_MORE_DATA requested 3496 bytes but callback returned -1 bytes
2020-10-18 16:09:18.049 22078-22268/com.draco.libretrowrapper.megaman3 D/AAudio: AAudioStream_requestStop(s#1) called
2020-10-18 16:09:18.049 22078-22268/com.draco.libretrowrapper.megaman3 E/AAudioStream: setState(1) tried to set to 9 but already DISCONNECTED
2020-10-18 16:09:18.049 22078-22268/com.draco.libretrowrapper.megaman3 D/AudioTrack: ClientUid 10453 AudioTrack::stop
2020-10-18 16:09:18.049 22078-22268/com.draco.libretrowrapper.megaman3 D/AudioTrack: stop(2445): called with 410774 frames delivered
2020-10-18 16:09:18.049 22078-22268/com.draco.libretrowrapper.megaman3 D/AAudio: AAudioStream_close(s#1) called ---------------
2020-10-18 16:09:18.052 22078-22268/com.draco.libretrowrapper.megaman3 D/AudioTrack: ClientUid 10453 AudioTrack::stop
2020-10-18 16:09:18.065 22078-22268/com.draco.libretrowrapper.megaman3 D/AAudio: AAudioStream_close(s#1) returned 0 ---------
Perhaps we need to handle an AudioTrack disconnect event by creating a new one on-the-fly? Let me know your thoughts on this, seems like it shouldn't be too difficult to fix.
Good catch, I didn't notice the issue. Apparently we should reinitialize the stream in onErrorAfterClose