Droid audio latency

i’m playing short button click sounds on my device using the midi synth interface. this works well on iOS and Windows, but i’m getting a noticeable latency under Android. Subjectively, it seems like over 1/4s. This is on a real device.

i’m using API 10, so maybe i’m getting the SLES interface, i haven’t verified that yet, although building against API 8 subjectively gets the same result. will SLES make any difference when using the midi synth or do i have to play streaming audio for this.

is there anything else i should be doing here, or might have missed.

Thanks for any help,

– hugh.

Oh yeah, some (most?) Android devices have shockingly bad audio latencies.

My Kindle Fire has a latency of about 1/2 second at best - and it’s not that my code is wrong, even apps like the BBC iPlayer play their video completely out-of-sync.

And even SLES doesn’t provide any way to find out what the latencies are, it’s really bizarre how terrible the sound APIs are!

ok thanks. i’ll have a play about and see if i can improve it in any way. right now, the delay woudnt really be a problem for playing music, but short event sounds are too slow.

if anyone else has anything, please post.


Unfortunately : http://www.androidannoyances.com/post/tag/low-latency-audio


it looks like this is what we have to put up with until new versions come through.

i downloaded several Android apps to examine their audio to discover almost all do not use any click sound for the UI. most instead ping the buzzer briefly. The ones that do have click sound as an option turned off by default, presumably for the few devices that might be ok with this.

looks like i will have to do the same idea, at least, for now…

I’m just testing a few things on a Samsung Galaxy Note (which runs Android 2.3), and apps like “All in One Drum Pad” or “Electric Guitar” clearly have a much lower latency than the Juce Demo (an estimated 100 ms against about 400 ms). So there must be some way to improve it, it seems…

a lot of web articles on audio latency have been with situations of a fairly complicated audio nature. for example audio processing and mixing, effects etc.

i have been wondering, if all i want to do is pump out unmodified audio samples, what is the lowest pipeline level i can use to minimise latency. moreover, does Juce already do it like this. i need to read the code and do some research.

i do feel there’s probably a solution to this, providing the requirements remain simple. even if the latest devices out there have fixed the problem, there’s a lot of them that have not, and getting basic sounds working are quite important to an app.


ok, today, ive been hacking around and wound up doing the following…

i hacked my button click sound into 8KHz mono 16 bit and copied it into the NDK sample “native audio”. the native audio sample is an example of OpenSL and operates a queuing buffer similar to the way Juce works. i also hacked the sample to play each sample just once and got rid of any effects being applied (just in case). i built the sample against API 10 and loaded it onto my phone.

the result,

the exact same delay im seeing in Juce. or at least not to make a worthwhile difference.

so, unfortunately, this doesnt lead me to any answers. its possible there’s some other devious way to do things that’s faster. but this certainly explains why the observed latency is the same in Juce.

to be clear, for many purposes this latency may be ok. but i can move my finger to another button before i hear the click sound of the first button. clearly, this isnt fast enough to have a click sound on a button.


– hugh.

So still no way to improve?

no progress yet, im afraid. :frowning:

Magic Piano seems to have very low latency on my galaxy s3, or is this another situation because it’s just playing static audio vs synthesized audio?

Edit: aha:
"Smule has come up with a work-around for Android’s latency problem that will be deployed in Magic Piano."
source: http://gigaom.com/2012/05/15/music-app-maker-smule-finally-gives-android-some-love/

Then the s3 probably has good audio drivers. But for all the devices which don’t, Magic Piano would have to be literally “magic” to do any better. And there’s no such thing as “synthesised” vs “static”, it’s all just audio.

you possibly missed my post edit, apparently they found a workaround.

Yes, I did miss that, thanks. Interesting.

I wonder what their “secret” is… The only possible workaround that I’ve imagined would be if you could find a hacky way to directly access the underlying ALSA devices on the machine, and cut out the android audio layer entirely. But even then, not all devices use ALSA, and I suspect that there might be security hurdles to jump in getting access to the drivers…

it seems like android 4.1 has audio improvements:

Apparently it is the case : http://code.google.com/p/android/issues/detail?id=3434

there’s no change to the latency of my app on the Nexus 7, running 4.1. Or might this only work if i set min API to 16.

I guess it might only work better with a higher min API level - they might have done that deliberately to keep backwards compatibility… Or maybe the nexus 7 still has crap audio hardware!

when i get a chance, i’ll compile the audio test sample that comes with the NDK against API 16 and see what it does. if this doesn’t do it, then we’re still stuck.

– hugh.