+++ /dev/null
----
-layout: default
-title: Latency and Latency-Compensation
-menu_title: Latency
----
-
-<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="/diagrams/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="/diagrams/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-diverged / blobdiff