Google I/O 2013 - High Performance Audio
Google for Developers4 HN recommenders · recommended in 3 months, 2013–2018
talk · intermediate · 2013–2018 on HN
A Google I/O 2013 talk by Android audio engineers on why reliable, low-latency audio is hard on the platform. It covers problem areas across the stack, platform work underway and techniques apps can use.
Treated as the definitive explanation of Android's audio latency problem, showing it spans the entire stack.
Up next
7 mo on HNDebConf 14: QA with Linus Torvalds
Adnan Hodzic
7 HN recommender · 2014–2021
3 mo on HNOSCON 2010: Rob Pike, "Public Static Void"
O'Reilly
3 HN recommender · 2012–2023
4 mo on HNComplete Apple WWDC | Steve Jobs talk and answer developers questions | 1997
TheAppleFanBoy - Apple & Computer Archives
4 HN recommender · 2018–2025
13 mo on HND/A and A/D | Digital Show and Tell (Monty Montgomery @ xiph.org)
FL Studio
15 HN recommender · 2017–2026
7 mo on HNThe world's worst video card?
Ben Eater
8 HN recommender · 2019–2024
6 mo on HNFloyd Toole - Sound reproduction – art and science/opinions and facts
CIRMMT
4 HN recommender · 2019–2026
5 mo on HNMiniDisc - An Appreciation
Techmoan
5 HN recommender · 2019–2023
5 mo on HNCassettes - better than you don't remember
Techmoan
5 HN recommender · 2016–2025
4 mo on HNWhy is TV 29.97 frames per second?
Stand-up Maths
4 HN recommender · 2016–2025
4 mo on HNE-paper hacking: fastest possible refresh rate
Applied Science
4 HN recommender · 2018–2021
4 mo on HNAtari's Quadrascan Explained
Retro Game Mechanics Explained
3 HN recommender · 2021–2026
3 mo on HNCD / Color
Captain Disillusion
3 HN recommender · 2020–2021
8 comments from Hacker News
If you want an in-depth explanation (AP mostly skims the surface) : ▶ this 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
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
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.
They gave a good talk at I/O on just audio latency: ▶ this video The touch latency alone is generally in the >80ms ballpark as well though, and varies a lot between devices.
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.
> 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] ▶ this video
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: ▶ this 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. ▶ this 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.