As we know, AAudio is a newer lightweight audio API for Android.
It was introduced with Android 8 but had serious bugs on the version.
Those were all fixed on Android 8.1.
So we thought AAudio was a safe choice for the devices running Android 11 and up, and set it as a default audio API for them.
But after receiving several complaints from our users, we found AAudio has higher latency than OpenSL on some devices.
Our app provides a setting for audio API, and they could solve the latency issue just by setting it to OpenSL.
Did the FMOD team know about this?
(As far as I know, FMOD_OUTPUTTYPE_AUTODETECT uses AAudio on Android 8.1 and up.)
Is this an FMOD issue or an issue with some Android devices?
Any advice or tips to work around latency issues with AAudio?
Audio Latency is a known issue with Android in general, but there may be an unknown issue with different FMOD output types on specific devices. Do you have any more details on which devices they were using?
As for general latency tips:
- Set a smaller buffer size using
System::setDSPBufferSize. The lowest I have gone before noticing issues was 32.
- Pre-load sounds with
System::createSound rather than creating them as needed and playing them all at once.
- Export your audio files in the Vorbis format and create them with the
FMOD_CREATECOMPRESSEDSAMPLE flag. This will increase CPU usage but should reduce load times and memory usage.
- Only use
FMOD_CREATESTREAM for very large audio files.
1 Like
Thanks for the info but I already read them all and studied enough about the Android audio system.
After writing this question, I asked a few other audio app developers for Android who implemented the audio engine themselves, and they said they had the same issue.
They had a high expectation of AAudio so used it as a default setting but soon switched back to OpenSL due to high latency on some devices.
So, I think FMOD should use OpenSL as a default one on all Android versions and explain the reason in the FMOD API user manual.
I had no idea why some users with recent devices complain about the latency, but now I get it.
Of course, AAudio is a better choice if the device supports it properly.
I noticed the difference between AAudio and OpenSL on our test devices.
PS. We don’t know the models that had the issue, because most of them just complained via mail not giving any information.
But after we told them to try OpenSL instead of AAudio, most of them answered it was solved.
The only model we know that had the issue is Samsung Galaxy A52 5G (Android 11).
I agree it would be good to include some benchmark information on the various output types in our Platform Performance Reference doc to help make an informed decision on output type. OpenSL has been deprecated so I don’t think making it the default would be a good long-term solution.
In any case, I have created a task to do some perofrmance benchmarking and add it to the performance reference, and if we find any major latency issues with AAudio we will investigate them.
Out of curiosity, I also asked Superpowered. For your information, the company has supported Android since the early days of Android and they were always proud of their low latency audio API.
Anyway, as for AAudio, they said they made it to the same conclusion as me, and OpenSL is their default.
They couldn’t find any way to detect the best API for a device.
A long time ago, some of our users who had multiple devices told us their newer devices experienced high latency, while older models worked without any problem.
And a few of them said the issue was gone after tinkering with the settings in our app.
In retrospect, it might have been the AAudio issue.
For a long time, we used AAudio as a default setting for Android 10 and up, and we had a lot of complaints.
Last month, we changed it to Android 11 and up, and fewer people complained.
And recently we changed again to use AAudio on Android 12 and up with a “FEATURE_AUDIO_PRO” flag.
We will update you later.
By the way, can you provide the link about the deprecation?
I also heard the news somewhere last year, but can’t remember, and the official page doesn’t say anything about it.
Thank you for the additional information, I can see why you would want want OpenSL to be the default and I am interested to see what results you get from AAudio with devices reporting the FEATURE_AUDIO_PRO flag.
The only place I can find any official reference to OpenSL being depracted is in the Android Latency Blog, so it might not be official. In any case I have passed your suggestion of making OpenSL the default onto the Dev team.
1 Like
This is interesting.
As far as I know, the setDSPBufferSize() of older FMOD 4 relied on the hardware, and I personally experienced crashes when the wrong value was set.
But FMOD 5’s setDSPBufferSize() only sets the buffer size settings for the FMOD software mixing engine.
Does this mean I can use any lower value if the CPU is powerful enough?
We can check an Android device’s buffer size with the code below in Java:
String framesPerBuffer = am.getProperty(AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER);
int framesPerBufferInt = Integer.parseInt(framesPerBuffer);
A value can be 96, 128, 160, 192, 240, 256, 512.
Some devices can be something like 144, 320, 464, 576, 960, 1024, or 2032.
My question is if my Android device’s audio buffer size is only 512 but it has a powerful AP, then can FMOD software mixing engine’s buffer size still be 128 or lower?
Or does the device’s audio buffer size still have something to do with the FMOD software mixing engine’s buffer size?
Audio hardware is pretty nebulous and any given manufacturer may not necessarily be reporting accurate information to the AudioManager, but generally speaking yes a more powerful CPU would correlate to smaller possible buffer sizes.
We still need to feed the output device blocks that are the size reported by AduioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER, reducing the DSP buffer size will just decrease latency introduced by mixing.
1 Like