Here's How To Check Audio Latency & Why It's Important For Your App

Far too much latency...

“The existing app has far too much latency to be useful for the real-time application. We get about 400 milliseconds from the internal mic to the wired headset output. It needs to be less than 40, preferably less than 10 milliseconds to be useful in real time”, one of our clients once wrote to us. He was toying with an idea for an Android app and made his own research on it. However, considering the results of the audio latency* he achieved, it would not make any sense to develop such a real-time app.

Audio latency is what you first encounter while developing any audio application for Android using a microphone. That is one of those cases when the results of the preliminary research can either prove or disprove your concept before the development. So, it was decided that our team makes our own audio latency analysis to check the client's calculations.

How are we checking audio latency for Android?

Audio latency can include different factors like input latency, output latency, touchscreen lag and so on.
We calculated only the latency of the device without any additional software processing, which is enough to see whether it is worth investigating the app idea further.

Let’s imagine the following scenario: we need an application that captures a microphone and passes audio data to the output through the Bluetooth speaker.

Audio latency, in this case, depends on two things:

Round-trip audio latency is the time between capturing audio data, performing data zero processing in the application and playing the data. It depends on several factors:

•  mobile device;
•  Android version;
• capturing/playback approach.

 Bluetooth latency depends on:

• data format;
• Bluetooth codec.

Measuring

The following picture illustrates how the application works and how the testing is performed:

Here, a special Android application performs recording and an immediate playback as fast as possible using the standard Java methods.

In order to calculate the latency we pair the Android device with the Bluetooth receiver, run this application on Android device, run an audio recording application on the PC (Audacity) with the stereo microphones connected, and just knock on the table near the microphone on the Android device

As a result, the PC will record two knocks: the original one and yet another one that passed all processing path. Measuring the distance between two knocks in the audio editing software will give the total latency:

If we cut off the Bluetooth receiver and connect the Speaker directly to the  Android device, we will obtain round-trip latency.

It is shown in the No Bluetooth column (see the table below). The minimum value is 100 ms, which is not so good.

I believe that it is possible to achieve better results using the low-level OpenSL ES. Here is some statistics by Google which show that the best result for Nexus 9 with Android 5.1.1 is 32 ms.

Yet another set of statistics shows that it is possible to get much better results: for example 18 ms using LG G4 (LGE LG-F500L), and 15 ms using Samsung Galaxy S5 (Samsung SM-G900H).

Note that Samsung devices at the top of this list use Samsung Professional Audio SDK, which is intended for low-latency audio. It seems that a lot of Samsung devices support this technology.

Another thing that influences the total audio latency is Bluetooth latency. We get it by subtracting latency measured with the connected Bluetooth receiver and round-trip latency.

The best result is for HTC One M7 with the ViMicRowX Bluetooth receiver: 330 - 290 = 40 ms, however round-trip for this device is too high (290 ms).

Such good values for Bluetooth latency are due to the fact that this device supports low-latency Bluetooth codec aptX. Here is the list of devices that support aptX. Note that there are no Nexus devices.

Here is the information about aptX latency.

So in order to get total low latency, the device should be fast enough (or be Samsung Professional Audio enabled) and support aptX codec. Note that Bluetooth receiver should support aptX too.

We mentioned at the beginning that the data format also affects Bluetooth latency. Unfortunately, there is no simple way to force Android to use specific Bluetooth configuration. Here is the Issue 7906 (Audio routing to the mono Bluetooth headset) in the issues tracking system, which was changed to the Obsolete status on Mar 15, 2015, by the project manager without explanation. So, currently, it is unknown whether Android supports mono headsets.

What we can do is check what data format is used in the Bluetooth channel in the following way:

1. Enable the Bluetooth HCI snoop log option in the device Developer options (note that it is available starting from Android 4.4):

2. Enable Bluetooth and pair it with your Bluetooth headset.

3. Look for the btsnoop_hci.log* file on your device SDCARD (most likely /sdcard path) and copy it to your PC.

4. Install and launch the Wireshark application on your PC and open the copied file.

5. Apply the btavdtp  filter and look for the Sent Command - SetConfiguration packet:

This screenshot shows that the aptX codec is selected. But there are no data format details:

Here is another log that shows that the SBC codec is selected with the data format details:

The hardware used for testing:

1) Belkin CarAudio Connect AUX (uses the CSR 57E687CG chip)  that does not support aptX;

2) DYI CSR 8645 receiver that supports aptX;

3) DYI LN-BT02 (uses the ViMicRowX WS9621NLSF chip);

4) Nokia BH503;

5) DYI microphones (stereo mic).

Results of our investigation

As you can see, they appeared to be similar with the client`s, which, unfortunately, proved that the realisation of his app isn't yet possible: