4 href="http://en.wikipedia.org/wiki/Latency_%28audio%29"><dfn>Latency</dfn></a>
5 is a system's reaction time to a given stimulus. There are many factors that
6 contribute to the total latency of a system. In order to achieve exact time
7 synchronization all sources of latency need to be taken into account and
11 <h2>Sources of Latency</h2>
13 <h3>Sound propagation through the air</h3>
15 Since sound is a mechanical perturbation in a fluid, it travels at
16 comparatively slow <a href="http://en.wikipedia.org/wiki/Speed_of_sound">speed</a>
17 of about 340 m/s. As a consequence, an acoustic guitar or piano has a
18 latency of about 1–2 ms, due to the propagation time of the sound
19 between the instrument and the player's ear.
22 <h3>Digital-to-Analog and Analog-to-Digital conversion</h3>
24 Electric signals travel quite fast (on the order of the speed of light),
25 so their propagation time is negligible in this context. But the conversions
26 between the analog and digital domain take a comparatively long time to perform,
27 so their contribution to the total latency may be considerable on
28 otherwise very low-latency systems. Conversion delay is usually below 1 ms.
31 <h3>Digital Signal Processing</h3>
33 Digital processors tend to process audio in chunks, and the size of that chunk
34 depends on the needs of the algorithm and performance/cost considerations.
35 This is usually the main cause of latency when using a computer and the one that
36 can be predicted and optimized.
39 <h3>Computer I/O Architecture</h3>
41 A computer is a general purpose processor, not a digital audio processor.
42 This means the audio data has to jump a lot of fences in its path from the
43 outside to the CPU and back, contending in the process with some other parts
44 of the system vying for the same resources (CPU time, bus bandwidth, etc.)
47 <h2>The Latency chain</h2>
50 Note! the rest of this document assumes the use of jackd for the audio
51 backend. While many of the concepts are true, the specifics may be different.
54 <img src="/images/latency-chain.png" alt="Latency chain">
61 The numbers are an example for a typical PC. With professional gear and an
62 optimized system the total round-trip latency is usually lower. The important
63 point is that latency is always additive and a sum of many independent factors.
66 Processing latency is usually divided into <dfn>capture latency</dfn> (the time
67 it takes for the digitized audio to be available for digital processing, usually
68 one audio period), and <dfn>playback latency</dfn> (the time it takes for the
69 audio that has been processed to be available in digital form).
70 In practice, the combination of both matters. It is called <dfn>round-trip
71 latency</dfn>: the time necessary for a certain audio event to be captured,
72 processed and played back.
75 It is important to note that processing latency in Ardour is a matter of
76 choice. It can be lowered within the limits imposed by the hardware (audio
77 device, CPU and bus speed) and audio driver. Lower latencies increase the
78 load on the system because it needs to process the audio in smaller chunks
79 which arrive much more frequently. The lower the latency, the more likely
80 the system will fail to meet its processing deadline and the dreaded
81 <dfn>xrun</dfn> (short for buffer over- or under-run) will make its
82 appearance more often, leaving its merry trail of clicks, pops and crackles.
86 The digital I/O latency is usually negligible for integrated or
87 <abbr title="Periphal Component Interface">PCI</abbr> audio devices, but
88 for USB or FireWire interfaces the bus clocking and buffering can add some
92 <h2>Low Latency use cases</h2>
95 Low latency is <strong>not</strong> always a feature one wants to have. It
96 comes with a couple of drawbacks: the most prominent is increased power
97 consumption because the CPU needs to process many small chunks of audio data,
98 it is constantly active and can not enter power-saving mode (think fan noise).
99 Since each application that is part of the signal chain must run in every
100 audio cycle, low-latency systems will undergo <dfn>context switches</dfn>
101 between applications more often, which incur a significant overhead.
102 This results in a much higher system load and an increased chance of xruns.
105 For a few applications, low latency is critical:
108 <h3>Playing virtual instruments</h3>
110 A large delay between the pressing of the keys and the sound the instrument
111 produces will throw off the timing of most instrumentalists (save church
112 organists, whom we believe to be awesome latency-compensation organic systems.)
115 <h3>Software audio monitoring</h3>
117 If a singer is hearing her own voice through two different paths, her head
118 bones and headphones, even small latencies can be very disturbing and
119 manifest as a tinny, irritating sound.
122 <h3>Live effects</h3>
124 Low latency is important when using the computer as an effect rack for
125 inline effects such as compression or EQ. For reverbs, slightly higher
126 latency might be tolerable, if the direct sound is not routed through the
132 Some sound engineers use a computer for mixing live performances.
133 Basically that is a combination of the above: monitoring on stage,
134 effects processing and EQ.
137 In many other cases, such as playback, recording, overdubbing, mixing,
138 mastering, etc. latency is not important, since it can easily be
142 To explain that statement: During mixing or mastering, one doesn't care
143 if it takes 10ms or 100ms between the instant the play button is pressed
144 and the sound coming from the speaker. The same is true when recording with a count in.
147 <h2>Latency compensation</h2>
149 During tracking it is important that the sound that is currently being
150 played back is internally aligned with the sound that is being recorded.
153 This is where latency compensation comes into play. There are two ways to
154 compensate for latency in a DAW, <dfn>read-ahead</dfn> and
155 <dfn>write-behind</dfn>. The DAW starts playing a bit early (relative to
156 the playhead), so that when the sound arrives at the speakers a short time
157 later, it is exactly aligned with the material that is being recorded.
158 Since we know that playback has latency, the incoming audio can be delayed
159 by the same amount to line things up again.
162 The second approach is prone to various implementation
163 issues regarding timecode and transport synchronization. Ardour uses read-ahead
164 to compensate for latency. The time displayed in the Ardour clock corresponds
165 to the audio signal that is heard on the speakers (and is not where Ardour
166 reads files from disk).
169 As a side note, this is also one of the reasons why many projects start at
170 timecode <samp>01:00:00:00</samp>. When compensating for output latency the
171 DAW will need to read data from before the start of the session, so that the
172 audio arrives in time at the output when the timecode hits <samp>01:00:00:00</samp>.
173 Ardour does handle the case of <samp>00:00:00:00</samp> properly but not all
174 systems/software/hardware that you may inter-operate with may behave the same.
177 <h2>Latency Compensation And Clock Sync</h2>
180 To achieve sample accurate timecode synchronization, the latency introduced
181 by the audio setup needs to be known and compensated for.
184 In order to compensate for latency, JACK or JACK applications need to know
185 exactly how long a certain signal needs to be read-ahead or delayed:
189 <img src="/images/jack-latency-excerpt.png" alt="Jack Latency Compensation">
191 Jack Latency Compensation
196 In the figure above, clients A and B need to be able to answer the following
201 How long has it been since the data read from port Ai or Bi arrived at the
202 edge of the JACK graph (capture)?
205 How long will it be until the data written to port Ao or Bo arrives at the
206 edge of the JACK graph (playback)?
211 JACK features an <abbr title="Application Programming Interface">API</abbr>
212 that allows applications to determine the answers to above questions.
213 However JACK can not know about the additional latency that is introduced
214 by the computer architecture, operating system and soundcard. These values
215 can be specified by the JACK command line parameters <kbd class="input">-I</kbd>
216 and <kbd class="input">-O</kbd> and vary from system
217 to system but are constant on each. On a general purpose computer system
218 the only way to accurately learn about the total (additional) latency is to
222 <h2>Calibrating JACK Latency</h2>
224 Linux DSP guru Fons Adriaensen wrote a tool called <dfn>jack_delay</dfn>
225 to accurately measure the round-trip latency of a closed loop audio chain,
226 with sub-sample accuracy. JACK itself includes a variant of this tool
227 called <dfn>jack_iodelay</dfn>.
230 Jack_iodelay allows to measure the total latency of the system,
231 subtracts the known latency of JACK itself and suggests values for
232 jackd's audio-backend parameters.
235 jack_[io]delay works by emitting some rather annoying tones, capturing
236 them again after a round trip through the whole chain, and measuring the
237 difference in phase so it can estimate with great accuracy the time taken.
240 The loop can be closed in a number of ways:
244 Putting a speaker close to a microphone. This is rarely done, as air
245 propagation latency is well known so there is no need to measure it.
248 Connecting the output of the audio interface to its input using a
249 patch cable. This can be an analog or a digital loop, depending on
250 the nature of the input/output used. A digital loop will not factor
251 in the <abbr title="Analog to Digital, Digital to Analog">AD/DA</abbr>
256 Once the loop has been closed, one must:
259 <li>Launch jackd with the configuration to test.</li>
260 <li>Launch <kbd class="input">jack_delay</kbd> on the command line.</li>
261 <li>Make the appropriate connections between the jack ports so the loop is closed.</li>
262 <li>Adjust the playback and capture levels in the mixer.</li>
265 On Linux, the latency of USB audio interfaces is not constant. It may
266 change when the interface is reconnected, on reboot and even when xruns
267 occur. This is due the buffer handling in the Linux USB stack. As a
268 workaround, it is possible to recalibrate the latency at the start of each
269 session and each time an xrun occurs.