1## Audio Latency Measurement 2 3Audio output latency as measured by WALT is the time that passes from the moment an application 4decides to output a tone until it can be detected via the headphone jack. Microphone latency is 5defined similarly. 6 7Low latency audio IO on Android can be achieved via JNI C/C++ code. 8Documentation 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 14We are trying to stick to the following (overlapping) principles 151. Timestamp events as close to hardware as possible. Most events up the stack can be easily timed with software alone. 161. Measure time intervals that are likely to have low variability. 17 18##### Playback 19 20In 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). 22WALT app follows this pattern. 23 24The 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) 26and 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) 28until 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 31The 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) 33receiving that buffer is executed. 34 35TODO: 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 52Superpowered 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 61Audio signal for measuring microphone latency is generated as a square wave using the Teensy tone() 62function ([currently at 5 kHz](https://github.com/google/walt/blob/v0.1.6/arduino/walt/walt.ino#L310)). 63The 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 66Audio output signal from the phone is detected when audio line voltage crosses a predefined 67threshold (currently about 65 mV). 68