Android Oboe architecture stops when head phone is plugged in

[hvisser]

When a DspFaust instance has been started and a change to the audio properties happen, for example by plugging in headphones, oboe seems to exit and this is undetected by Faust. I can reproduce this on multiple devices, I've tested on Android 10 and 12.

Starting the DspFaust instance again may fix the issue, however since there's no indication from Faust itself that a restart is needed this is not ideal (isRunning still returns true in this case).

The output on the console from oboe is:

D/OboeAudio: oboe_aaudio_error_thread_proc() - exiting <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<`

I can also reproduce it by turning on live captions on Android 12, in that case Faust/oboe do not start with live captions enabled. An issue related to that is here, though it has been closed as a platform bug. This may or may not be related.

So TL;DR there are two issues I think: 1. oboe stops all processing and 2. there's no feedback/callback from the Faust architecture code to act on this.

While I'm a seasoned Android developer, I don't have experience with oboe and my experience with Faust is limited. I'd be happy to further troubleshoot and fix if needed, but not sure where to start, some pointers would be appreciated.

[sletz]

The OBOE code is here https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/audio/oboe-dsp.h (and in included in the generated DspFaust.cpp). Can you possibly add some debug messages to see where the audio stops? Possibly tracing this function: https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/audio/oboe-dsp.h#L99

[sletz]

You can possibly use the setErrorCallback to setup an error callback, and trace ? https://google.github.io/oboe/reference/classoboe_1_1_audio_stream_builder.html#aacb66f530bfc6f545911b5e169774567

[hvisser]

It's likely that the condition in the docs are exactly what is happening (headphones plugged in/audio focus moving to another app). I'll take a look if that's the case and if so if in that case an attempt can be made to reopen the driver again maybe (though that might not be immediately recoverable).

[sletz]

Possible solution:

• re-organize a bit theoboeaudio::init code https://github.com/grame-cncm/faust/blob/ca6ab03ec35f57dcdb1de6fcdbc60dd6ea65bfc3/architecture/faust/audio/oboe-dsp.h#L160 to separate stream initialisation.
• add a oboeaudio::destroy that would do : delete fInputs; delete fOutputs; (and have destructor call oboeaudio::destroy)
• setup an arrow callback that calls oboeaudio::destroy and then oboeaudio::init again ?

[sletz]

Fixed in https://github.com/grame-cncm/faust/commit/e569df94f7d86e882056774ea5549f82dac07b64