1 page.title=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>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-neglible 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 71 <p class="note"><b>Note:</b> To get useful results, it is crucial to use the correct 72 APIs in the test app so that you're exercising the fast audio output path. 73 See <a href="latency_design.html">Design For Reduced Latency</a> for 74 background. 75 </p> 76 </li> 77 <li>Place a light sensor next to the LED.</li> 78 <li>Connect the probes of a dual-channel oscilloscope to both the wired headphone 79 jack (line output) and light sensor.</li> 80 <li>Use the oscilloscope to measure 81 the time difference between observing the line output signal versus the light 82 sensor signal.</li> 83 </ol> 84 85 <p>The difference in time is the approximate audio output latency, 86 assuming that the LED latency and light sensor latency are both zero. 87 Typically, the LED and light sensor each have a relatively low latency 88 on the order of one millisecond or less, which is sufficiently low enough 89 to ignore.</p> 90 91 <h3>Larsen test</h3> 92 <p> 93 One of the easiest latency tests is an audio feedback 94 (Larsen effect) test. This provides a crude measure of combined output 95 and input latency by timing an impulse response loop. This test is not very useful 96 by itself because of the nature of the test, but it can be useful for calibrating 97 other tests</p> 98 99 <p>To conduct this test:</p> 100 <ol> 101 <li>Run an app that captures audio from the microphone and immediately plays the 102 captured data back over the speaker.</li> 103 <li>Create a sound externally, 104 such as tapping a pencil by the microphone. This noise generates a feedback loop.</li> 105 <li>Measure the time between feedback pulses to get the sum of the output latency, input latency, and application overhead.</li> 106 </ol> 107 108 <p>This method does not break down the 109 component times, which is important when the output latency 110 and input latency are independent. So this method is not recommended for measuring output latency, but might be useful 111 to help measure output latency.</p> 112 113 <h2 id="measuringInput">Measuring Input Latency</h2> 114 115 <p> 116 Input latency is more difficult to measure than output latency. The following 117 tests might help. 118 </p> 119 120 <p> 121 One approach is to first determine the output latency 122 using the LED and oscilloscope method and then use 123 the audio feedback (Larsen) test to determine the sum of output 124 latency and input latency. The difference between these two 125 measurements is the input latency. 126 </p> 127 128 <p> 129 Another technique is to use a GPIO pin on a prototype device. 130 Externally, pulse a GPIO input at the same time that you present 131 an audio signal to the device. Run an app that compares the 132 difference in arrival times of the GPIO signal and audio data. 133 </p> 134 135 <h2 id="reducing">Reducing Latency</h2> 136 137 <p>To achieve low audio latency, pay special attention throughout the 138 system to scheduling, interrupt handling, power management, and device 139 driver design. Your goal is to prevent any part of the platform from 140 blocking a <code>SCHED_FIFO</code> audio thread for more than a couple 141 of milliseconds. By adopting such a systematic approach, you can reduce 142 audio latency and get the side benefit of more predictable performance 143 overall. 144 </p> 145 146 147 <p> 148 Audio underruns, when they do occur, are often detectable only under certain 149 conditions or only at the transitions. Try stressing the system by launching 150 new apps and scrolling quickly through various displays. But be aware 151 that some test conditions are so stressful as to be beyond the design 152 goals. For example, taking a bugreport puts such enormous load on the 153 system that it may be acceptable to have an underrun in that case. 154 </p> 155 156 <p> 157 When testing for underruns: 158 </p> 159 <ul> 160 <li>Configure any DSP after the app processor so that it adds 161 minimal latency.</li> 162 <li>Run tests under different conditions 163 such as having the screen on or off, USB plugged in or unplugged, 164 WiFi on or off, Bluetooth on or off, and telephony and data radios 165 on or off.</li> 166 <li>Select relatively quiet music that you're very familiar with, and which is easy 167 to hear underruns in.</li> 168 <li>Use wired headphones for extra sensitivity.</li> 169 <li>Give yourself breaks so that you don't experience "ear fatigue."</li> 170 </ul> 171 172 <p> 173 Once you find the underlying causes of underruns, reduce 174 the buffer counts and sizes to take advantage of this. 175 The eager approach of reducing buffer counts and sizes <i>before</i> 176 analyzing underruns and fixing the causes of underruns only 177 results in frustration. 178 </p> 179 180 <h3 id="tools">Tools</h3> 181 <p> 182 <code>systrace</code> is an excellent general-purpose tool 183 for diagnosing system-level performance glitches. 184 </p> 185 186 <p> 187 The output of <code>dumpsys media.audio_flinger</code> also contains a 188 useful section called "simple moving statistics." This has a summary 189 of the variability of elapsed times for each audio mix and I/O cycle. 190 Ideally, all the time measurements should be about equal to the mean or 191 nominal cycle time. If you see a very low minimum or high maximum, this is an 192 indication of a problem, likely a high scheduling latency or interrupt 193 disable time. The <i>tail</i> part of the output is especially helpful, 194 as it highlights the variability beyond +/- 3 standard deviations. 195 </p> 196
