How much time can we spend on the audio callback without causing the buffer to underrun?

[sinosoidal]

Hi,

We have an application using Oboe that is extremely heavy on all operating systems. But on Android is performing really, really bad. This product is called FRMS - Granular Synthesizer.

Recently we’ve have been able to optimize it for Windows, Mac and iOS but on Android it got even worst. I was able to play a single voice without crackling but now, not even one.

It is taking 3.5 ms to calculate a single voice and it is already breaking. I wasn’t measuring before the refactor, so I don’t have numbers to compare.

How much time can we spend on the audio callback without causing the buffer to underrun?

I’m still using a checkout from Dec 2019. Do you think upgrading Oboe to the latest version will help me achieve better performance? Are there significant upgrades since late 2019?

Thank you for your help!

[philburk]

You can convert the number of frames to a real-time duration that you should not exceed. Multiply the number frames times 1,000 and divide by the sample rate. That will be the duration in milliseconds. You can go over that briefly but you'll have to make up the time in following callback. You cannot sustain audio if you are averaging higher than that number per call back. What device are you having these performance problems on? By any chance do you get less glitching if you tap on the screen.? Also does your performance vary as the number of voices goes up and down or is it fairly steady? You may be glitching if the scheduler switches you between course. Try setting the CPU affinity to a single core to see if that reduces the glitching. Please let us know the results of any experiments. Phil Burk

…

On Wed, Oct 20, 2021, 12:23 PM Nuno Santos ***@***.***> wrote: Hi, We have an application using Oboe that is extremely heavy on all operating systems. But on Android is performing really, really bad. This product is called FRMS - Granular Synthesizer. Recently we’ve have been able to optimize it for Windows, Mac and iOS but on Android it got even worst. I was able to play a single voice without crackling but now, not even one. It is taking 3.5 ms to calculate a single voice and it is already breaking. I wasn’t measuring before the refactor, so I don’t have numbers to compare. How much time can we spend on the audio callback without causing the buffer to underrun? I’m still using a checkout from Dec 2019. Do you think upgrading Oboe to the latest version will help me achieve better performance? Are there significant upgrades since late 2019? Thank you for your help! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1425>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHPU2NJSOIW6MRNZQDLQUDUH3UH5ANCNFSM5GMBYK6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[sinosoidal]

Phil,

Thanks for your reply.

I'm having problems with this synth on any device. The device in questions is a Samsung Tab A. I have the problem with a single voice.

How do I set the CPU affinity to a single core? Is there a Oboe function for that? Also, do you think using the latest version of Oboe will help in any way? I'm still using a checkout from Dec 2019.

Thanks!

Best regards,

Nuno

[philburk]

How do I set the CPU affinity to a single core?

Here is some example code.

oboe/samples/shared/DefaultDataCallback.h

Line 121 in 4fa162b

int result = sched_setaffinity(current_thread_id, sizeof(cpu_set_t), &cpu_set);

[dturner]

Hey Nuno,

The first thing I'd do is run a trace to see what's going on inside your callback.

I wrote an article which covers this a while back, although systrace has been replaced with perfetto.

First, enable Audio ATrace events by going to Android apps & svcs, then select Audio:

Then execute the trace command manually, then adb pull the trace file and upload it to the perfetto UI to see the results.

If you upload your trace file then maybe we can investigate further.

Other things to try:

• Compiler optimisations - are you using -Ofast?
• Set CPU affinity to avoid core migrations (as mentioned by phil). You should be able to see from your trace whether core migrations are causing glitches because when there's a glitch you'll see the callback thread change to a different core.

Also, if you could supply more information about the specific devices which you're testing, Android versions and an idea of the code which is running inside the callback that could be useful.

It's also worth noting that some Exynos CPU devices never increase the clock frequency for real-time audio apps which can severely limit bandwidth.