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