Buffer starvation with FMOD 2 on Huawei Android Phones when screen is locked

FMOD Engine
1

Hello,

I have found a bug that seems only reproducible on certain Huawei Android phones where a Buffer starvation occurs when the screen is locked.

Here is an example of the bug happening in the play_sound sample app taken from FMOD Engine 2.01.06, with the loop enabled on drumloop.wav: https://www.youtube.com/watch?v=hmHOc09Buig

When the sound stops, I see these warnings in the logs:

2020-12-03 11:31:56.914 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Buffer starvation detected, requested 1920 bytes, 896 / 32768 bytes available.
2020-12-03 11:31:56.914 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Increasing block count to 5.
2020-12-03 11:31:56.915 7424-7545/org.fmod.example W/fmod: OutputAAudio::mixerThread : Increasing buffer size to 2160 due to detected xruns.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Buffer starvation detected, requested 1920 bytes, 896 / 32768 bytes available.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Increasing block count to 6.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Buffer starvation detected, requested 1920 bytes, 0 / 32768 bytes available.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Increasing block count to 7.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Buffer starvation detected, requested 1920 bytes, 0 / 32768 bytes available.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Increasing block count to 8.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Buffer starvation detected, requested 1920 bytes, 0 / 32768 bytes available.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example I/chatty: uid=10137(org.fmod.example) identical 17 lines
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Buffer starvation detected, requested 1920 bytes, 0 / 32768 bytes available.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Buffer starvation detected, requested 1920 bytes, 0 / 32768 bytes available.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Buffer starvation detected, requested 1920 bytes, 0 / 32768 bytes available.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Buffer starvation detected, requested 1920 bytes, 0 / 32768 bytes available.
2020-12-03 11:31:56.916 7424-7552/org.fmod.example W/fmod: OutputRingBuffer::read : Buffer starvation detected, requested 1920 bytes, 256 / 32768 bytes available.

I have also tested the exact same scenario with FMOD 1.10.20, and the bug does not happen.

I was able to reproduce this on the Huawei Mate 30, P30 Pro & P30 Lite, all running Android 10.

Thanks!

2

Hi alexandre,

The example apps do not suspend or resume the mixer when the application loses focus. At this point, as FMOD works as a low latency audio solution and the OS can throttle the app, stuttering can occur.

You can hook up mixerSuspend and mixerResume to the application callbacks to better interact with the OS.

3

Hi Tristanjl,

Thanks for responding to me!

For my particular use case, I want the sound to keep playing, even when that app is in background. And it isn’t just stuttering, it’s as if there is a something that just blocks the sound files from getting streamed to FMOD 2. One thing I should mention is that this only happens when the phone is not charging.

When running the same test on other devices, I can keep the sound playing for hours without interruption. Also, when testing with FMOD 1 on these Huawei devices, I can also play sounds for hours without interruption.

It’s the combination of these Huawei devices and FMOD 2 that causes this problem, which makes me feel like there is a bug in FMOD 2 that should be fixed.

Thanks!

Alex

4

The old behaviour might still be possible using OpenSL (as our thread usage has change for AAudio - the OS now controls the thread priority of our audio thread). If you call https://fmod.com/resources/documentation-api?version=2.0&page=core-api-system.html#system_setoutput choosing FMOD_OUTPUTTYPE_OPENSL, you might get the old behaviour.

5

Hi tristanjl,

Thank you for your suggestion, this works perfectly!

Alex