after some time of debugging we managed to find a solution: roll our own version of an Oboe stabilised callback. The one that is provided with Android Oboe doesn’t seem to work well with the app we are working on (a synth app with a sequencer and hence the CPU load can vary quite dramatically over time). We keep the CPU busy until we’ve reached 70% of the time associated with the number of samples in a block and now everything works super smooth on a variety of Android devices.
Perhaps one FR for the JUCE wrapper for Oboe: in the stream builder for Oboe in JUCE/modules/juce_audio_devices/native/juce_android_Oboe.cpp, please add:
builder.setFramesPerDataCallback(oboe::DefaultStreamValues::FramesPerBurst);
Without this, the callback can have any number of samples, including very small ones (like 4 or 8 samples), causing a potentially large amount of overhead without any benefits if the native frame sizes are significantly larger (like 96 or 192 samples on Android). Specifying the number of frames per callback resolves this.