szantog

I'm one of the authors of the article, and the CTO of Superpowered. I apologize if the article was confusing.

Marshmallow improves audio latency here and there on some devices, but even Android N has the fundamental audio stack problems we mention in the articles.

There is no Android version delivering <= 10 ms round-trip audio latency.

Audio can be handled by built-in hardware or external (USB) hardware.

External: Android is not able to deliver glitch-free low latency audio on USB devices. We introduced a solution for this last month, that's one of the links on the top of the article. It opens up a market of 1.1 billion devices (meaning, Android 4.4.4 and up) for USB audio on Android.

Built-in: The current article introduces a demo solution for the built-in audio hardware.

"We updated our findings with the recent improvements in Android M (Marshmallow), and recently released a solution for Android’s USB audio and MIDI challenges, opening a market of 1.1 billion devices for pro audio application creators."

Those are two separate things:

1. Updated analysis on the latency with regards to Marshmallow.

2. Superpowered USB Audio and MIDI SDK opens a market of 1.1 billion devices.

Android's audio stack is "pushing" audio down to the audio driver, with the audio threads sleeping between every push. In other words, the audio driver's interrupts are not scheduling the actions. Having smaller period sizes increases the risk of not "guessing" the sleep scheduling right, resulting in many audio dropouts.

Using a "pull" method is required for low latency audio, where the audio driver's interrupts are scheduling when audio is passed to and pulled from applications.

Another downside of halving the period size is CPU load/battery drain. There are simply too many layers in Android's audio stack, and it has quite a few unoptimised code as well (such as converting between audio sample formats with plain C code).

ALSA is super. The HAL connecting ALSA to AudioFlinger is the major problem, plus the audio stack's "push" philosophy.

All of the measurements and the latency graph shows you a pure NDK implementation.

They did not forgot to write nice professional audio and music tools for Android. They can't, because of audio latency and dropouts.

Audio Flinger is not Java. On the graph you see absolutely no part which runs on Java.

Android's media architecture with it's "push" design is not more compatible than anything else with a "pull". The many layers doesn't add any flexibility, they are "only" the result of many years hacking.