-When speaking about synchronization, there is no way around also mentioning Latency: -Latency is how you call the reaction time of a system to a certain stimulus. There are many factors that contribute to the total latency of a given system. -In order to achieve exact time synchronization all sources of latency need to be take into account and compensated for. +When speaking about synchronization, it is also necessary to speak of latency. +Latency 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.
Figure 1: Latency chain. 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.
+
Figure: Latency chain. 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.
There is not much that can done about the first two other than using headphones or sitting near the loudspeaker and buying quality gear. @@ -44,30 +45,22 @@ But this division is an implementation detail of no great interest. What really
-It is important to note that processing latency in a jackd is a matter of choice: It can be lowered within the limits imposed only by the hardware and audio driver. But the lower it is, the more likely the system will fail to meet its processing deadline and the dreaded xrun will make its appearance more often, leaving its merry trail of clicks, pops and crackles. +It is important to note that processing latency in a jackd is a matter of choice: It can be lowered within the limits imposed only by the hardware (audio-device, CPU and bus-speed) and audio driver. Lower latencies increase the load on the computer-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 xrun (short for buffer over-run and buffer under-run) will make its appearance more often, leaving its merry trail of clicks, pops and crackles.
-The digital I/O latency is usually negligible for integrated or PCI audio devices but for USB or FireWire interfaces the bus clocking and buffering can add some milliseconds. +The digital I/O latency is usually negligible for integrated or PCI audio devices but for USB or FireWire interfaces the bus clocking and buffering can add some milliseconds.
-The JACK Audio Connection Kit has a few parameters to configure the latency. However the settings are constrained by hardware (audio-device, CPU and bus-speed). Lower latencies increase the load on the computer-system (it needs to process the audio in smaller chunks which arrive much more frequently). If the system can not keep up: an x-run (short for buffer over-run and buffer under-run) occurs which usually results in audible clicks or dropouts. +Low-latency is not 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). Furthermore, if more than one application (sound-processor) is involved in processing the sound, each of these needs to run for a short, well defined time for each audio-cycle which results in a much higher system-load and an increased chance of x-runs. Reliable low-latency (â¤10ms) on GNU/Linux can usually only be achieved by running a realtime-kernel.
-Low-latency is not 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. Furthermore, if more than one application (sound-processor) is involved in processing the sound, the operating system performs a context-switch to run each of these for each audio-cycle which results in a much higher system-load and an increased chance of x-runs. -
- --Reliable low-latency (â¤10ms) on GNU/Linux can usually only be achieved by running realtime-kernel. -
- --Yet there are only few situations where a very low-latency is really important, because they require very quick response from the computer. Some examples that come quickly to mind are: +Yet there are a few situations where a low-latency is really important, because they require very quick response from the computer.
-To explain the last statement: during mixing or mastering you don't care if it take 10 or 100ms between the instant you press the play button and sound coming from the speaker. The same is true when recording. +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.
-During tracking, it is however important that the sound that is currently played back is internally aligned with the sound that is being recorded. +During tracking it is important that the sound that is currently being played back is internally aligned with the sound that is being recorded.
-This is where latency-compensation comes into play: There are two possibilities to compensate for latency in a DAW: read-ahead the DAW actually starts playing a bit early. So that the sound hits the speakers a short time later, it is exactly aligned with the timecode of the material that is being recorded. -and write-behind since we know that the sound that is being played back has latency, the incoming audio can be delayed by the same amount to line things up again. +This is where latency-compensation comes into play. There are two possibilities to compensate for latency in a DAW: read-ahead 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. +And write-behind; since we know that play-back has latency, the incoming audio can be delayed by the same amount to line things up again.
-As you may see the second approach has various issues implementation issues regarding timecode and transport synchronization. Ardour uses internal 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). +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).
-NB. this is also one of the reasons why many projects start at timecode 01:00:00:00. 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 01:00:00:00. Ardour3 does handle the case of 00:00:00:00 properly but not all systems/software/hardware that you may inter-operate with may behave the same.
+As a side note, this is also one of the reasons why many projects start at timecode 01:00:00:00. 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 01:00:00:00. Ardour3 does handle the case of 00:00:00:00 properly but not all systems/software/hardware that you may inter-operate with may behave the same.
To achieve sample accurate timecode synchronization, the latency introduced by the audio-setup needs to be known and compensated for. @@ -109,26 +102,26 @@ To achieve sample accurate timecode synchronization, the latency introduced by t 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:
-
Figure 2: Jack Latency Compensation. This figure outlines the jack latency API. -- excerpt from http://jackaudio.org/files/jack-latency.png
+
Figure: Jack Latency Compensation. This figure outlines the jack latency API. -- excerpt from http://jackaudio.org/files/jack-latency.png
-In Figure 2, clients A and B need to be able to answer the following two questions: +In the figure above, clients A and B need to be able to answer the following two questions:
-JACK includes an API 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 indicated by -I and -O in Figure 2 and vary from system to system but are generally constant values. On a general purpose computer system the only way to accurately learn about the total latency is to measure it.
+JACK features an API 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 are indicated by -I and -O 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.
-Linux DSP guru Fons Adriaensen wrote a tool called jack_delay to accurately measure the roundtrip latency of a closed loop audio chain, with sub-sample accuracy. JACK itself includes a variant of this called jack_iodelay.
+Linux DSP guru Fons Adriaensen wrote a tool called jack_delay 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 jack_iodelay.
@@ -136,7 +129,7 @@ Jack_iodelay allows you to measure the total latency of the system, subtracts th
-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. This is not a theoretical estimation, jack_delay is a measuring tool that will provide very accurate answers. +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. This is not a theoretical estimation, jack_delay is a measuring tool that provides very accurate answers.
@@ -144,7 +137,7 @@ You can close the loop in a number of ways:
@@ -152,9 +145,8 @@ Once you have closed the loop you have to:
jack_delay on the commandline.