I’m currently working on a client’s project, a part of which processes microphone input while blaring audio out of the speaker — and tries to make sense of the relationship between the two signals. Unfortunately, it’s an Android project, and Android suffers from a lavishly documented1,2,3 excess of audio latency.
Long story short: For many applications, audio latency on Android is unworkably high, and variations in latency between devices (and across Android versions) are extreme.
Below is an attempt to figure out how high, and how varied, using available data.
Unlike either input or output latency in isolation, roundtrip latency can be measured tolerably well with software1. Software measurements trade precision for convenience, and, as with all numbers, they’re to be treated with skepticism.
Superpowered is an Android/IOS library for audio processing. Its developers have released a roundtrip audio latency measurement application1 which submits its results for aggregation. The resulting data is available, though not in a visually digestible format. I’ve attempted to re-visualize it below.
The measuring application doesn’t use Superpowered itself2 — it’s a simple OpenSL client which requests the native sample rate & buffer size in order to ingratiate itself onto the fast path (if supported). It then burps out some sine waves and tries to detect them with the microphone.
2 Superpowered is a well-designed library, and its stewards are doing a great job agitating for improvement of the audio latency situation on Android. As opposed to the hard I/O limits visualized below, audio processing is amenable to a variety of software-based approaches to performance improvement — it’s on this category of optimization that Superpowered’s latency-reduction efforts are focused.
Keep in mind that the same signal processing code used for these measurements clocks in at <= 10ms across Apple mobile devices.
Also, prepare to collide with the fact that I am not a statistician.
Here, we’re looking at latency averaged across manufacturer, device and OS version, excluding devices with small numbers of samples (< 20).
A sample corresponds to the value output by the data-gathering application after each execution — the average of 10 consecutive beep/listen cycles.
- The vertical axis is ordered by the number of samples per grouping (indicated in the labels)
- The error bars represent the standard deviation
- Click the bars to descend, the background to ascend
A small number of Samsung devices are compatible with (and ship with) the Samsung Professional Audio SDK, which basically exposes
JACK to Android applications —
dramatically reducing audio latency (e.g. ~10-15ms in some configurations).
The Superpowered latency
measurer uses the Samsung SDK if available, however I’ve chosen
to exclude the SDK-enhanced values from these results.
Unless an application is targeted at the subset of Samsung devices which support the SDK — or engages an alternate code path for audio I/O when it’s available — the numbers aren’t going to be relevant.
The twenty devices on which measurements have most often been taken:
Let’s take a look at the top twenty devices by average latency, across all OS versions. Mostly, this group is comprised of devices for which we don’t have pre-5.0 data (the higher latencies on old builds would throw off the mean).
Devices by Build Version
Per-build information for two of the more popular devices in the data:
LG Nexus 5
We’ve got plenty of Nexus 5 samples — let’s put them to work:
Man, where’s that Professional Audio SDK when you need it?
Congratulations on making it this far.
As I’ve been discovering in practice, comedically wide tolerances are required for any degree of portable, interdependent audio I/O on Android.
For those working on similar problems — and so presumably wallowing in similarly-dimensioned pits of despair — I hope this process of naming and quantifying our agonies in some way diminishes them.