Google I/O 2013 - High Performance Audio

If you want an in-depth explanation (AP mostly skims the surface) : [VIDEO] is a must-watch. Obviously, it does not cover the work accomplished these past two years, but it gives a good idea of the challenges of audio latency on Android

They gave a good talk at I/O on just audio latency: [VIDEO] The touch latency alone is generally in the >80ms ballpark as well though, and varies a lot between devices.

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. [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: [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

This is something which is being worked on, but it's a complex problem and takes time to improve. Android 4.3 has halved the audio latency on the Nexus 7 (2012) and Nexus 4. See here: [VIDEO]

> So 4.3 fixes neither the ad-hoc WiFi issue #82 nor the audio latency issue #3434. Low latency audio is "fixed" on the Android side, it needs better device support though. Apps need to actually support the fast path as well, which I don't think many do. [VIDEO] I don't know if the new Nexus 7 supports the low latency audio path, though. But Android itself does have low latency audio, it's a device-specific thing though.

> Besides, have you tried Android recently? You might be suprised to discover that Android is better. .. not yet for music apps. Even Google folks admit that [1]. This really can't wait any longer. Where is Garage Band for Android please? ... and to those saying "you can't complain only about music, look at the games, todo lists, blah blah", sorry music IS my domain and that's the only thing I care about. [1] [VIDEO]

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. [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.