Help with CPU Scaling problem on Note 8 Handset

We are having an issue where audio is playing slow and distorted on Samsung Galaxy Note 8

This is from the Forum …and our question is at the bottom …

Now that the VST is released for my app (spacecraft granular synth) I have returned my attention to the Android version. The only thing that’s stopping me from releasing this right now is the dreaded CPU scaling that only happens on a subset of devices. I’m finding that a low-cost basic device such as Xiaomi Mi is able to run my app flawlessly, but a powerful flagship such as the Note 8 has audio glitches which are corelated to downward spikes in the CPU frequency (I’ve ruled out GUI/resolution as the culprit).

After lots of optimisation of the DSP, one of the last remaining possible fixes for this that I’m aware of is the Oboe ‘StabilizedCallback’, thanks to @donturner for pointing me in the right direction. After many failed attempts, I’ve finally managed to get this to work (I think) in JUCE.

Here’s my implementation (modifications to juce_android_Oboe.cpp). Note that this is just a prototype implementation with a standard pointer, I still need to figure out what happens with object destruction and whether or not smart pointers are needed (any suggestions welcome).

Declaration of a pointer to an AudioStreamCallback object in the OboeStream class:

oboe::AudioStreamCallback * asc;

Replace this line of code in the same class…

builder.setCallback (callback); 


if ( callback != NULL ) 
    asc = new oboe::StabilizedCallback(callback); 
    builder.setCallback (asc); 
    builder.setCallback (callback); 

Jucer config:

  • Release build
  • Link-time optimisation enabled
  • Optimisation: Ofast
  • Oboe release v1.2.0

By adding the check for NULL I can finally run my app without crashing on start-up. The stabilized callback appears to be working; however, although as the cpu frequency profile and audio glitches appear to be improved, there are still sporadic drops in cpu freq and corresponding audio dropouts. Saying that, there is a huge number of settings (such as optimisation settings in jucer etc.) that I need to try before it can be conclusive.

So, I have a couple of questions going forward for @donturner.

Firstly, I notice that in StabilizedCallback.cpp there are some hardcoded parameters:

constexpr int32_t kLoadGenerationStepSizeNanos = 20000;
constexpr float kPercentageOfCallbackToUse = 0.8;

Can these parameters be thought of as tuning parameters for the stabilized callback? If I increase those numbers, does the stabilized callback become more ‘stabilisy’? If so, do you have any guidelines for tuning (max limits etc.)?

Secondly, in the scenario that the StabilizedCallback alone does not fix the issue, an additional modification could be for Oboe to use a larger buffer (latency is not so important in my app as it’s predominantly generative). Perhaps this, in combination with the StabilizedCallback, would help me find a sweet spot which would eliminate dropouts on my Galaxy Note 8. Questions relating to this:

  1. What is the proper way to increase the buffer size in Oboe? I’ve tried changing oboe::PerformanceMode::LowLatency to oboe::PerformanceMode::None or oboe::PerformanceMode::PowerSaving however, this results in very large audio dropouts (even with a barebones hello world JUCE app generating a sine wave)
  2. If buffer size modifications are possible, how could I control this within my app? (this might be more a question for the JUCE devs)


Hi there. I’m having exactly same issue with Android app - I’m getting glitched playback on Note 8, but everything goes smoothly on cheaper devices. I’m aware that the problem is related to CPU scaling. I’ve tried to modify juce_android_Oboe.cpp as @MarkWatt recommended but still the same. Is there anything else i’m missing? Are there any plans about integrating this implementation to official Juce release, or at least develop branch?

, in this article you are pointing bug related to optimization flags. Is it solved in latest Android Studio / NDK? Can I be sure that if i’m setting Ofast in Projucer it is taken into account by CMake? Any other advices from you?


Unfortunately due to the sheer number and diversity of Android devices, getting optimal audio performance across them is mostly a matter of trial and error and testing with the actual devices that your app is going to run on. There are a few workarounds and improvements in the JUCE Oboe and OpenSL code that have been added thanks to the ROLI software team’s experiments with Android devices, but you will need to do your own testing with your app to figure out what works best for you. If you’ve got a working implementation of the oboe::StabilizedCallback and it’s helping with your app then feel free to submit a PR and we can get it added to JUCE.


Thank you so very much for your response. Do you think that if we resolved the glitchy audio on the Note 8 , it may then work for all devices with this exact issue. Its going to be quite difficult to have it tested on all devices !

It’s hard to say. I remember that the ROLI team were having some issues with the latest Samsung devices, so it could be a Samsung specific issue.

1 Like

Hopefully if we fix it for the Note 8 then at least the rest of the Samsung devices should be OK. The audio just appears to be working slowly, all other apps I tested work fine. Thanks again for your help

Hey, did you manage to fix this? I’m having a similiar problem with the note 10.

Hi. Yes, we have good performance after switching to oboe and implementing StabilizedCallback.
Follow these amazing instructions to modify juce_android_Oboe.cpp.

Dont forget to activate Oboe: in Projucer->Modules->juce_audio_devices there is macro JUCE_USE_ANDROID_OBOE. And in your Android exporter you could set the path to Oboe library

1 Like

Thanks. I’ve already done all that though. Still having issues. Have you tried the note 10?

Nope. Does the audio output differs with oboe and without it? Have you tried other devices?
You can report issue in oboe repository if its related to particular phone

Oboe uses yield to keep the CPU frequency high:

There was a presentation from ADC 2019 from Ableton where they found that wfe was more reliable on iOS ARM architectures. I would love it if someone could test this with a real world app to see whether it has an effect.

Ableton’s performance testing app is here: