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