See title. This is made plain when running even the Demo Runner, where these messages appear when switching even just basic sample rate and buffer size:
I/Choreographer: Skipped 44 frames! The application may be doing too much work on its main thread.
I/Choreographer: Skipped 53 frames! The application may be doing too much work on its main thread.
Android Studio’s profiler shows this for “Janky frames” (note that this is a Release build with profileable flags enabled):
It’s hard to know exactly what could be going wrong without prior knowledge of JUCE’s Android rendering scheme. Still, here is what each janky frame shows for details (which is fairly vague IMO):
Based on a quick search, it seems like a handful of frames being missed is generally acceptable. But it seems to me that JUCE is doing much more work which inadvertently stalls the UI thread, giving nearly 3x longer frame durations when doing these buffer and sample rate changes.
Anyway, I’m not sure there’s anything that can be done easily but it seems worth mentioning because our app doubles or triples these skipped frame values, sometimes just doing basic scrolling with a juce::ListBox. I’ll keep digging for a bit longer. My best guess here is that changes to underlying systems like the audio driver in the Demo Runner’s case should be done async with coroutines or something to that effect.