Google I/O 2013 - High Performance Audio

This is a great description of the lowest level problem. But for those wondering why iOS doesn't have the problem or why only 10ms is such a difference, the answer is that this is only the beginning of the problem of Android audio latency. There are still additional problems that add latency that span the entire Android stack from the actual hardware and drivers, to the kernel and scheduler, to the Android implementation of their audio APIs. Anybody who has tried to do any serious audio on Android knows the infamous Bug 3434: [link] Google I/O 2013 did a pretty good talk on the problem and shows how there are problems across the entire stack. Glenn Kasten pretty much carries the brunt of all the audio problems with Android. I find it telling that he had to handcraft his own latency measurement device using an oscilloscope and LED because there were no actual tools built into the OS to help them analyze performance. [this video] Audio has been terrible since Android's inception. It has improved a little over time, but unfortunately, 7 years later is is still pretty much unacceptable for any serious work.

You can watch this I/O session from a few years back: [this video] It probably provides the best insight to the problem Google engineers were and probably is still facing in regards to high performance audio on Android. Even when the latency is brought down, there's still other audio related issues/glitches (like buffer underruns). Even now that Android is measurably better than it was previously, things like buffer underruns can still affect the overall usability. Increasing the buffer (to fix the underruns) render the device less suitable for such things as using it with external MIDI controller. You can see from Superpowered's audio latency measurements: [link] that the buffer for iOS is half that of the best Android (the dual-core Nexus 9)- 64 instead of 128 for Android. I

Sure. Originally Android only had the Java media APIs, with a quite complex state. [link] Android 2.3 introduced OpenSL ES into the NDK and Android 4.0 got OpenMAX. All of them weren't up to the game of realtime audio due to the Android architecture. [link] [link] [link] There are plenty of other articles online when you search for audio issues on Android. There was even a Google IO 2013 talk about it. [this video] Meanwhile Samsung had customized their Android versions to properly support real time audio and offered an SDK for their handsets. [link] At Google IO 2016 the problem was again discussed, with the Samsung team from Professional Audio being called on stage to discuss their collaboration. [link] Finally last year at Google IO 2017, the new real time audio was announced, as C only lib. [link] [link] The announced C++ wrapper ended up being an external project on github, detached from the NDK, that you need to integrate yourself, without any guarantees how long Google will care to maintain it. Oh, to make things even better, it is already clear from Android P draft documentation that new audio APIs are on their way.