1 ## Audio Latency Measurement 2 3 Audio output latency as measured by WALT is the time that passes from the moment an application 4 decides to output a tone until it can be detected via the headphone jack. Microphone latency is 5 defined similarly. 6 7 Low latency audio IO on Android can be achieved via JNI C/C++ code. 8 Documentation and sample code can be found on the 9 [High Performance Audio website](http://googlesamples.github.io/android-audio-high-performance/). 10 11 12 ### Reported values 13 14 We are trying to stick to the following (overlapping) principles 15 1. Timestamp events as close to hardware as possible. Most events up the stack can be easily timed with software alone. 16 1. Measure time intervals that are likely to have low variability. 17 18 ##### Playback 19 20 In order to avoid warm up latency during audio playback it is 21 [recommended to constantly enqueue buffers containing silence](http://googlesamples.github.io/android-audio-high-performance/guides/audio-output-latency.html#avoid-warm-up-latency). 22 WALT app follows this pattern. 23 24 The audio data buffers are enqueued in the 25 [player callback](https://github.com/google/walt/blob/v0.1.6/android/WALT/app/src/main/jni/player.c#L107) 26 and the latency reported by WALT app is the time from the 27 [Enqueue() call](https://github.com/google/walt/blob/v0.1.6/android/WALT/app/src/main/jni/player.c#L123) 28 until there is a detectable signal on the wire. Note that this does not include the time between the moment the app decided to output a tone until the Enqueue() call. This is somewhat counterintuitive but this time is deliberately omitted. In case of the WALT app code this time is likely be uniformly distributed between 0 and the length of the buffer (5 ms in case of Nexus 5) and therefore would contribute considerable variance but little interesting information if included in the reported latency. 29 30 ##### Recording 31 The reported latency is the time from the moment the last frame in a buffer was recorded until the 32 [recorder callback](https://github.com/google/walt/blob/v0.1.6/android/WALT/app/src/main/jni/player.c#L345) 33 receiving that buffer is executed. 34 35 TODO: Is the round trip latency expected to be Recording latency + Playback latency + one buffer length? 36 37 ### Sample measurements 38 39 | Device | OS version | Buffer | Playback [ms] | Recording* [ms] | 40 | :--- | :--- | :--- | ---: | ---: | 41 | Nexus 5 | M4B30Z (6.0.1) | 240 frames @ 48 kHz = 5 ms | 27.6 | 2.5 | 42 | Nexus 5X | NRD91P (7.0) | 192 frames @ 48 kHz = 4 ms | 14.9 | 3.5 | 43 | Nexus 7 | LMY47Q (5.1) | 240 frames @ 48 kHz = 5 ms | 32.1 | 16.3 | 44 | Nexus 9 | MMB29K (6.0.1) | 128 frames @ 48 kHz = 2.6 ms | 9.8 | 1.0 | 45 | Nexus 6P | MHC19I (6.0.1) | 192 frames @ 48 kHz = 4 ms | 15.3 | 1.6 | 46 | Pixel | NDE63P (7.1) | 192 frames @ 48 kHz = 4 ms | 8.9 | 1.7 | 47 | Pixel XL | NDE63H (7.1) | 192 frames @ 48 kHz = 4 ms | 9.1 | 1.6 | 48 49 \* WALT clock synchronization accuracy is about 1 ms hence the relative error for recording latency can be fairly high. 50 51 #### Published round trip measurements 52 Superpowered Inc. maintains an open source app for measuring round trip audio latency - 53 [Superpowered Latency App](https://github.com/superpoweredSDK/SuperpoweredLatency). 54 55 * [Audio round trip measurements published by Android group](https://source.android.com/devices/audio/latency_measurements.html#measurements) 56 * [Audio round trip measurements published by Superpowered Inc.](http://superpowered.com/latency) 57 58 59 ### Hardware 60 61 Audio signal for measuring microphone latency is generated as a square wave using the Teensy tone() 62 function ([currently at 5 kHz](https://github.com/google/walt/blob/v0.1.6/arduino/walt/walt.ino#L310)). 63 The signal is attenuated by a simple circuit similar to the 64 [ChromeOS/Android audio loopback dongle](https://source.android.com/devices/audio/loopback.html). 65 66 Audio output signal from the phone is detected when audio line voltage crosses a predefined 67 threshold (currently about 65 mV). 68
