- 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
+ 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
- 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.
+ 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, an acoustic guitar or piano has a
+ latency of about 1–2 ms, due to the propagation time of the sound
+ between the instrument and the player's ear.
- 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,
+ 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>
so their contribution to the total latency may be considerable on
otherwise very low-latency systems. Conversion delay is usually below 1 ms.
</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.
+ 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 using a computer and the one that
+ can be predicted and optimized.
- 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.)
+ A computer is a general purpose processor, not a digital audio processor.
+ This means the 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.)
- <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
+ The numbers are an example for a typical PC. With professional gear and an
+ optimized system the total round-trip latency is usually lower. The important
- 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
+ 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
- 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,
+ In practice, the combination of both matters. It is called <dfn>round-trip
+ latency</dfn>: the time necessary for a certain audio event to be captured,
- 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
+ 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 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
+ 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
- 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
+ Low latency is <strong>not</strong> always a feature one wants to have. It
+ comes with a couple of drawbacks: the most prominent is increased power
- 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.
+ 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.
- 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
+ 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
bones and headphones, even small latencies can be very disturbing and
manifest as a tinny, irritating sound.
</p>
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
<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
- 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.
+ 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.
- 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.
+ In many other cases, such as playback, recording, overdubbing, mixing,
+ mastering, etc. latency is not important, since it can easily be
+ compensated for.
+</p>
+<p>
+ To explain that statement: During mixing or mastering, one doesn't care
+ if it takes 10ms or 100ms between the instant the play button is pressed
+ and the sound coming from the speaker. The same is true when recording with a count in.
- <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
+ <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
- 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
+ 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 is heared on the speakers (and is not where Ardour
- 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
+ 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>.
+ Ardour 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>
systems/software/hardware that you may inter-operate with may behave the same.
</p>
<h2>Latency Compensation And Clock Sync</h2>
<p>
-<img src="/images/jack-latency-excerpt.png" title="Jack Latency Compensation" alt="Jack Latency Compensation" />
-<p>
- <em>Figure: Jack Latency Compensation.</em>
-</p>
+
+<figure>
+ <img src="/images/jack-latency-excerpt.png" alt="Jack Latency Compensation">
+ <figcaption>
+ Jack Latency Compensation
+ </figcaption>
+</figure>
+
- 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
+ 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
- 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
+ Linux DSP guru Fons Adriaensen wrote a tool called <dfn>jack_delay</dfn>
+ to accurately measure the round-trip latency of a closed loop audio chain,
+ with sub-sample accuracy. JACK itself includes a variant of this tool
- Jack_iodelay allows you to measure the total latency of the system,
- subtracts the known latency of JACK itself and suggests values for
+ Jack_iodelay allows to measure the total latency of the system,
+ subtracts the known latency of JACK itself and suggests values for
- 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.
+ 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.
- 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>
+ Connecting the output of the 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 used. A digital loop will not factor
+ in the <abbr title="Analog to Digital, Digital to Analog">AD/DA</abbr>
- <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>
+ <li>Launch jackd with the configuration to test.</li>
+ <li>Launch <kbd class="input">jack_delay</kbd> on the command line.</li>
+ <li>Make the appropriate connections between the jack ports so the loop is closed.</li>
+ <li>Adjust the playback and capture levels in the mixer.</li>