Android Mono Hack: AndroidAudioGate

Gabor Szanto

Follow @szantog

Two days ago, we posted an article that claims Android 8.0 demonstrates worse latency than Android 7.0. That is to say, from the mobile audio developer POV, Android 8.0 is an indisputable step-back from Android 7.0.

To allow independent verification of our claims, we provided our data, our testing methods and an open-source app for 3rd party testing.

In response, a Developer Advocate at Android Audio, has made some, well, *interesting* statements about the capability of Android 8.0 with regards to latency.

He publicly states that our claims are false, and that latency on Android 8.0 has not deteriorated...as long as...here's the punchline: developers switch to mono input, instead of stereo (because of a Google-internal bug with Android's Fast Flag).

But that suggestion, excuse the phrase, is lipstick on a pig.

Lipstick on a Pig

This shifting of the goalposts is a severe qualification to what an accurate latency measurement might mean to any reasonable musician or audio developer. And in our minds at Superpowered HQ, completely robs 'latency' of any real meaning.

Imagine going into a store to buy the latest and greatest in TVs, and being told that this year's model is only available with mono audio, and not stereo. And best of all, that's an actual benefit to you as the consumer!

To be honest, we don't know whether to laugh or cry at the audacity of the suggestion that developers use Android with mono input only and that latency is improved...in mono only!

Let us note, he's technically correct -- switching to mono audio input on Android will provide lower latency numbers.

It bears re-stating with emphasis, to be perfectly clear, developers will get lower latency results on Android 8.0 if they use mono, instead of stereo....because there is a known bug in Android.

We have verified this and have updated our article. Data below:

Technical sidebar: BTW if you're a developer and can/plan to switch to mono by asking for the channel count with the AudioDeviceInfo Java API, we checked and it doesn't work. It returned 1, 2 and 3 as channel count for the TYPE_BUILTIN_MIC audio input of the Nexus 6P. This means that mono is not the default as there is no default.

Android Audio Gate

Yet, let it not be lost on us, suggesting a switch-to-mono-instead-of-stereo hack is hilariously similar to Steve Job's Antenna Gate, where Jobs received an email from an iPhone 4 user, complaining about his loss of reception when his hand made contact with the steel band encircling the perimeter of the iPhone. Jobs replied with a terse:

Just avoid holding it that way.

In other words, if you need low latency audio input:

Just avoid stereo input on Android for multi-track recorders and DAWs.

Just avoid DVS input on Android DJ apps.

Just avoid stereo on Android for VOIP beam-forming with multiple mics.

Just avoid stereo for USB audio for recording music on Android.

To wit, just don't use stereo…or multi-channel…like you have been up to now on Android.

This is not only entirely unreasonable but isn't an actual solution.

Shifting Blame

Furthermore, in an attempt to shift technical blame from Android's bug to the Superpowered Latency Test App by suggesting that our app is flawed because it expects stereo, the same Developer Advocate opens up an issue on the Superpowered GitHub.

As we've stated on that very thread:

The issue is not in the latency measurement app, but in Android.

Let us state unequivocally, for the Superpowered Latency App to expect stereo input "we're not holding it wrong".

iOS, the undisputed home of low latency, pro audio on mobile, handles all audio in stereo -- and Android itself, had no problems with stereo input until Android 8.0.

Shifting the blame to the user for expecting reasonable operation didn't work for Jobs, and won't work here either.

Speaking of expectations, we fully expect that the Android audio team will fix this all in Android 8.1 -- but we don't expect that the Android audio community be treated with such condescension, and we don't expect that we be asked to change our latency measurement app to mono and thereby, the standard, working assumption of latency measurement in stereo...because of a bit of lipstick on a pig.

We stand by our findings.