3 title: Latency and Latency-Compensation
9 href="http://en.wikipedia.org/wiki/Latency_%28audio%29"><dfn>Latency</dfn></a>
10 is a system's reaction time to a given stimulus. There are many factors that
11 contribute to the total latency of a system. In order to achieve exact time
12 synchronization all sources of latency need to be taken into account and
16 <h2>Sources of Latency</h2>
18 <h3>Sound propagation through the air</h3>
20 Since sound is a mechanical perturbation in a fluid, it travels at
21 comparatively slow <a href="http://en.wikipedia.org/wiki/Speed_of_sound">speed</a>
22 of about 340 m/s. As a consequence, your acoustic guitar or piano has a
23 latency of about 1–2 ms, due to the propagation time of the sound
24 between your instrument and your ear.
26 <h3>Digital-to-Analog and Analog-to-Digital conversion</h3>
28 Electric signals travel quite fast (on the order of the speed of light),
29 so their propagation time is negligible in this context. But the conversions
30 between the analog and digital domain take a comparatively long time to perform,
31 so their contribution to the total latency may be considerable on
32 otherwise very low-latency systems. Conversion delay is usually below 1 ms.
34 <h3>Digital Signal Processing</h3>
36 Digital processors tend to process audio in chunks, and the size of that chunk
37 depends on the needs of the algorithm and performance/cost considerations.
38 This is usually the main cause of latency when you use a computer and one you
39 can try to predict and optimize.
41 <h3>Computer I/O Architecture</h3>
43 A computer is a general purpose processor, not a digital audio processor.
44 This means our audio data has to jump a lot of fences in its path from the
45 outside to the CPU and back, contending in the process with some other parts
46 of the system vying for the same resources (CPU time, bus bandwidth, etc.)
49 <h2>The Latency chain</h2>
51 <img src="/diagrams/latency-chain.png" title="Latency chain" alt="Latency chain" />
53 <em>Figure: Latency chain.</em>
54 The numbers are an example for a typical PC. With professional gear and an
55 optimized system the total roundtrip latency is usually lower. The important
56 point is that latency is always additive and a sum of many independent factors.
60 Processing latency is usually divided into <dfn>capture latency</dfn> (the time
61 it takes for the digitized audio to be available for digital processing, usually
62 one audio period), and <dfn>playback latency</dfn> (the time it takes for
63 In practice, the combination of both matters. It is called <dfn>roundtrip
64 latency</dfn>: the time necessary for a certain audio event to be captured,
65 processed and played back.
68 It is important to note that processing latency in a jackd is a matter of
69 choice. It can be lowered within the limits imposed by the hardware (audio
70 device, CPU and bus speed) and audio driver. Lower latencies increase the
71 load on the system because it needs to process the audio in smaller chunks
72 which arrive much more frequently. The lower the latency, the more likely
73 the system will fail to meet its processing deadline and the dreaded
74 <dfn>xrun</dfn> (short for buffer over- or under-run) will make its
75 appearance more often, leaving its merry trail of clicks, pops and crackles.
79 The digital I/O latency is usually negligible for integrated or
80 <abbr title="Periphal Component Interface">PCI</abbr> audio devices, but
81 for USB or FireWire interfaces the bus clocking and buffering can add some
86 <h2>Low Latency usecases</h2>
88 Low latency is <strong>not</strong> always a feature you want to have. It
89 comes with a couple of drawbacks: the most prominent is increased power
90 consumption because the CPU needs to process many small chunks of audio data,
91 it is constantly active and can not enter power-saving mode (think fan-noise).
92 Since each application that is part of the signal chain must run in every
93 audio cycle, low-latency systems will undergo<dfn>context switches</dfn>
94 between applications more often, which incur a significant overhead.
95 This results in a much higher system load and an increased chance of xruns.
98 For a few applications, low latency is critical:
100 <h3>Playing virtual instruments</h3>
102 A large delay between the pressing of the keys and the sound the instrument
103 produces will throw-off the timing of most instrumentalists (save church
104 organists, whom we believe to be awesome latency-compensation organic systems.)
106 <h3>Software audio monitoring</h3>
108 If a singer is hearing her own voice through two different paths, her head
109 bones and headphones, even small latencies can be very disturbing and
110 manifest as a tinny, irritating sound.
112 <h3>Live effects</h3>
114 Low latency is important when using the computer as an effect rack for
115 inline effects such as compression or EQ. For reverbs, slightly higher
116 latency might be tolerable, if the direct sound is not routed through the
121 Some sound engineers use a computer for mixing live performances.
122 Basically that is a combination of the above: monitoring on stage,
123 effects processing and EQ.
126 In many other cases, such as playback, recording, overdubbing, mixing,
127 mastering, etc. latency is not important, since it can easily be
128 compensated for.<br />
129 To explain that statement: During mixing or mastering you don't care
130 if it takes 10ms or 100ms between the instant you press the play button
131 and sound coming from the speaker. The same is true when recording with a count in.
134 <h2>Latency compensation</h2>
136 During tracking it is important that the sound that is currently being
137 played back is internally aligned with the sound that is being recorded.
140 This is where latency-compensation comes into play. There are two ways to
141 compensate for latency in a DAW, <dfn>read-ahead</dfn> and
142 <dfn>write-behind</dfn>. The DAW starts playing a bit early (relative to
143 the playhead), so that when the sound arrives at the speakers a short time
144 later, it is exactly aligned with the material that is being recorded.
145 Since we know that play-back has latency, the incoming audio can be delayed
146 by the same amount to line things up again.
149 As you may see, the second approach is prone to various implementation
150 issues regarding timecode and transport synchronization. Ardour uses read-ahead
151 to compensate for latency. The time displayed in the Ardour clock corresponds
152 to the audio-signal that you hear on the speakers (and is not where Ardour
153 reads files from disk).
156 As a side note, this is also one of the reasons why many projects start at
157 timecode <samp>01:00:00:00</samp>. When compensating for output latency the
158 DAW will need to read data from before the start of the session, so that the
159 audio arrives in time at the output when the timecode hits <samp>01:00:00:00</samp>.
160 Ardour3 does handle the case of <samp>00:00:00:00</samp> properly but not all
161 systems/software/hardware that you may inter-operate with may behave the same.
164 <h2>Latency Compensation And Clock Sync</h2>
167 To achieve sample accurate timecode synchronization, the latency introduced
168 by the audio setup needs to be known and compensated for.
171 In order to compensate for latency, JACK or JACK applications need to know
172 exactly how long a certain signal needs to be read-ahead or delayed:
174 <img src="/diagrams/jack-latency-excerpt.png" title="Jack Latency Compensation" alt="Jack Latency Compensation" />
176 <em>Figure: Jack Latency Compensation.</em>
179 In the figure above, clients A and B need to be able to answer the following
184 How long has it been since the data read from port Ai or Bi arrived at the
185 edge of the JACK graph (capture)?
188 How long will it be until the data writen to port Ao or Bo arrives at the
189 edge of the JACK graph (playback)?
194 JACK features an <abbr title="Application Programming Interface">API</abbr>
195 that allows applications to determine the answers to above questions.
196 However JACK can not know about the additional latency that is introduced
197 by the computer architecture, operating system and soundcard. These values
198 can be specified by the JACK command line parameters <kbd class="input">-I</kbd>
199 and <kbd class="input">-O</kbd> and vary from system
200 to system but are constant on each. On a general purpose computer system
201 the only way to accurately learn about the total (additional) latency is to
206 <h2>Calibrating JACK Latency</h2>
208 Linux DSP guru Fons Adriaensen wrote a tool called <dfn>jack_delay</dfn>
209 to accurately measure the roundtrip latency of a closed loop audio chain,
210 with sub-sample accuracy. JACK itself includes a variant of this tool
211 called <dfn>jack_iodelay</dfn>.
214 Jack_iodelay allows you to measure the total latency of the system,
215 subtracts the known latency of JACK itself and suggests values for
216 jackd's audio-backend parameters.
219 jack_[io]delay works by emitting some rather annoying tones, capturing
220 them again after a round trip through the whole chain, and measuring the
221 difference in phase so it can estimate with great accuracy the time taken.
224 You can close the loop in a number of ways:
228 Putting a speaker close to a microphone. This is rarely done, as air
229 propagation latency is well known so there is no need to measure it.
232 Connecting the output of your audio interface to its input using a
233 patch cable. This can be an analog or a digital loop, depending on
234 the nature of the input/output you use. A digital loop will not factor
235 in the <abbr title="Analog to Digital, Digital to Analog">AD/DA</abbr>
240 Once you have closed the loop you have to:
243 <li>Launch jackd with the configuration you want to test.</li>
244 <li>Launch <kbd class="input">jack_delay</kbd> on the commandline.</li>
245 <li>Make the appropriate connections between your jack ports so the loop is closed.</li>
246 <li>Adjust the playback and capture levels in your mixer.</li>