1page.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
38see 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>
43This test measures latency in relation to the device's LED indicator.
44If 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>
121One 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
138system to scheduling, interrupt handling, power management, and device
139driver design. Your goal is to prevent any part of the platform from
140blocking a <code>SCHED_FIFO</code> audio thread for more than a couple
141of milliseconds. By adopting such a systematic approach, you can reduce
142audio latency and get the side benefit of more predictable performance
143overall.
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