1 <html devsite> 2 <head> 3 <title>Measuring Audio Latency</title> 4 <meta name="project_path" value="/_project.yaml" /> 5 <meta name="book_path" value="/_book.yaml" /> 6 </head> 7 <body> 8 <!-- 9 Copyright 2017 The Android Open Source Project 10 11 Licensed under the Apache License, Version 2.0 (the "License"); 12 you may not use this file except in compliance with the License. 13 You may obtain a copy of the License at 14 15 http://www.apache.org/licenses/LICENSE-2.0 16 17 Unless required by applicable law or agreed to in writing, software 18 distributed under the License is distributed on an "AS IS" BASIS, 19 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 20 See the License for the specific language governing permissions and 21 limitations under the License. 22 --> 23 24 25 26 <p> 27 This page describes common methods for measuring input and output latency. 28 </p> 29 30 31 32 <h2 id="measuringOutput">Measuring Output Latency</h2> 33 34 <p> 35 There are several techniques available to measure output latency, 36 with varying degrees of accuracy and ease of running, described below. Also 37 see the <a href="testing_circuit.html">Testing circuit</a> for an example test environment. 38 </p> 39 40 <h3 id="ledTest">LED and oscilloscope test</h3> 41 <p> 42 This test measures latency in relation to the device's LED indicator. 43 If your production device does not have an LED, you can install the 44 LED on a prototype form factor device. For even better accuracy 45 on prototype devices with exposed circuity, connect one 46 oscilloscope probe to the LED directly to bypass the light 47 sensor latency. 48 </p> 49 50 <p> 51 If you cannot install an LED on either your production or prototype device, 52 try the following workarounds: 53 </p> 54 55 <ul> 56 <li>Use a General Purpose Input/Output (GPIO) pin for the same purpose.</li> 57 <li>Use JTAG or another debugging port.</li> 58 <li>Use the screen backlight. This might be risky as the 59 backlight may have a non-negligible latency, and can contribute to 60 an inaccurate latency reading. 61 </li> 62 </ul> 63 64 <p>To conduct this test:</p> 65 66 <ol> 67 <li>Run an app that periodically pulses the LED at 68 the same time it outputs audio. 69 <p class="note"><strong>Note:</strong> To get useful results, it is crucial to use the correct 70 APIs in the test app so that you're exercising the fast audio output path. 71 See <a href="latency_design.html">Design For Reduced Latency</a> for 72 background.</p> 73 </li> 74 <li>Place a light sensor next to the LED.</li> 75 <li>Connect the probes of a dual-channel oscilloscope to both the wired headphone 76 jack (line output) and light sensor.</li> 77 <li>Use the oscilloscope to measure 78 the time difference between observing the line output signal versus the light 79 sensor signal.</li> 80 </ol> 81 82 <p>The difference in time is the approximate audio output latency, 83 assuming that the LED latency and light sensor latency are both zero. 84 Typically, the LED and light sensor each have a relatively low latency 85 on the order of one millisecond or less, which is sufficiently low enough 86 to ignore.</p> 87 88 <h2 id="measuringRoundTrip">Measuring Round-Trip Latency</h2> 89 90 <p> 91 <a href="http://en.wikipedia.org/wiki/Round-trip_delay_time">Round-trip latency</a> 92 is the sum of output latency and input latency. 93 </p> 94 95 <h3 id="larsenTest">Larsen test</h3> 96 <p> 97 One of the easiest latency tests is an audio feedback 98 (Larsen effect) test. This provides a crude measure of combined output 99 and input latency by timing an impulse response loop. This test is not very useful 100 for detailed analysis 101 by itself because of the nature of the test, but it can be useful for 102 calibrating other tests, and for establishing an upper bound.</p> 103 104 <p>To conduct this test:</p> 105 <ol> 106 <li>Run an app that captures audio from the microphone and immediately plays the 107 captured data back over the speaker.</li> 108 <li>Create a sound externally, 109 such as tapping a pencil by the microphone. This noise generates a feedback loop. 110 Alternatively, one can inject an impulse into the loop using software.</li> 111 <li>Measure the time between feedback pulses to get the sum of the output latency, input latency, and application overhead.</li> 112 </ol> 113 114 <p>This method does not break down the 115 component times, which is important when the output latency 116 and input latency are independent. So this method is not recommended for measuring 117 precise output latency or input latency values in isolation, but might be useful 118 for establishing rough estimates.</p> 119 120 <p> 121 Output latency to on-device speaker can be significantly larger than 122 output latency to headset connector. This is due to speaker correction and protection. 123 </p> 124 125 <p> 126 We have published an example implementation at 127 <a href="https://android.googlesource.com/platform/frameworks/wilhelm/+/master/tests/examples/slesTestFeedback.cpp">slesTestFeedback.cpp</a>. 128 This is a command-line app and is built using the platform build environment; 129 however it should be straightforward to adopt the code for other environments. 130 You will also need the <a href="avoiding_pi.html#nonBlockingAlgorithms">non-blocking</a> FIFO code 131 located in the <code>audio_utils</code> library. 132 </p> 133 134 <h3 id="loopback">Audio Loopback Dongle</h3> 135 136 <p> 137 The <a href="loopback.html">Dr. Rick O'Rang audio loopback dongle</a> is handy for 138 measuring round-trip latency over the headset connector. 139 The image below demonstrates the result of injecting an impulse 140 into the loop once, and then allowing the feedback loop to oscillate. 141 The period of the oscillations is the round-trip latency. 142 The specific device, software release, and 143 test conditions are not specified here. The results shown 144 should not be extrapolated. 145 </p> 146 147 <img src="images/round_trip.png" alt="round-trip measurement" id="figure1" /> 148 <p class="img-caption"> 149 <strong>Figure 1.</strong> Round-trip measurement 150 </p> 151 152 <p>You may need to remove the USB cable to reduce noise, 153 and adjust the volume level to get a stable oscillation. 154 </p> 155 156 <h2 id="measuringInput">Measuring Input Latency</h2> 157 158 <p> 159 Input latency is more difficult to measure than output latency. The following 160 tests might help. 161 </p> 162 163 <p> 164 One approach is to first determine the output latency 165 using the LED and oscilloscope method and then use 166 the audio feedback (Larsen) test to determine the sum of output 167 latency and input latency. The difference between these two 168 measurements is the input latency. 169 </p> 170 171 <p> 172 Another technique is to use a GPIO pin on a prototype device. 173 Externally, pulse a GPIO input at the same time that you present 174 an audio signal to the device. Run an app that compares the 175 difference in arrival times of the GPIO signal and audio data. 176 </p> 177 178 <h2 id="reducing">Reducing Latency</h2> 179 180 <p>To achieve low audio latency, pay special attention throughout the 181 system to scheduling, interrupt handling, power management, and device 182 driver design. Your goal is to prevent any part of the platform from 183 blocking a <code>SCHED_FIFO</code> audio thread for more than a couple 184 of milliseconds. By adopting such a systematic approach, you can reduce 185 audio latency and get the side benefit of more predictable performance 186 overall. 187 </p> 188 189 190 <p> 191 Audio underruns, when they do occur, are often detectable only under certain 192 conditions or only at the transitions. Try stressing the system by launching 193 new apps and scrolling quickly through various displays. But be aware 194 that some test conditions are so stressful as to be beyond the design 195 goals. For example, taking a bugreport puts such enormous load on the 196 system that it may be acceptable to have an underrun in that case. 197 </p> 198 199 <p> 200 When testing for underruns: 201 </p> 202 <ul> 203 <li>Configure any DSP after the app processor so that it adds 204 minimal latency.</li> 205 <li>Run tests under different conditions 206 such as having the screen on or off, USB plugged in or unplugged, 207 WiFi on or off, Bluetooth on or off, and telephony and data radios 208 on or off.</li> 209 <li>Select relatively quiet music that you're very familiar with, and which is easy 210 to hear underruns in.</li> 211 <li>Use wired headphones for extra sensitivity.</li> 212 <li>Give yourself breaks so that you don't experience "ear fatigue."</li> 213 </ul> 214 215 <p> 216 Once you find the underlying causes of underruns, reduce 217 the buffer counts and sizes to take advantage of this. 218 The eager approach of reducing buffer counts and sizes <i>before</i> 219 analyzing underruns and fixing the causes of underruns only 220 results in frustration. 221 </p> 222 223 <h3 id="tools">Tools</h3> 224 <p> 225 <code>systrace</code> is an excellent general-purpose tool 226 for diagnosing system-level performance glitches. 227 </p> 228 229 <p> 230 The output of <code>dumpsys media.audio_flinger</code> also contains a 231 useful section called "simple moving statistics." This has a summary 232 of the variability of elapsed times for each audio mix and I/O cycle. 233 Ideally, all the time measurements should be about equal to the mean or 234 nominal cycle time. If you see a very low minimum or high maximum, this is an 235 indication of a problem, likely a high scheduling latency or interrupt 236 disable time. The <i>tail</i> part of the output is especially helpful, 237 as it highlights the variability beyond +/- 3 standard deviations. 238 </p> 239 240 </body> 241 </html> 242
