diff --git a/include/latency-and-latency-compensation.html b/include/latency-and-latency-compensation.html index 62009f24..89a6e1ed 100644 --- a/include/latency-and-latency-compensation.html +++ b/include/latency-and-latency-compensation.html @@ -14,10 +14,11 @@
Since sound is a mechanical perturbation in a fluid, it travels at comparatively slow speed - of about 340 m/s. As a consequence, your acoustic guitar or piano has 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 your instrument and your ear. + between the instrument and the player's ear.
+Electric signals travel quite fast (on the order of the speed of light), @@ -26,31 +27,36 @@ so their contribution to the total latency may be considerable on otherwise very low-latency systems. Conversion delay is usually below 1 ms.
+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. + 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 + 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.)
- Figure: Latency chain. - 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 + 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 point is that latency is always additive and a sum of many independent factors.
-Processing latency is usually divided into capture latency (the time it takes for the digitized audio to be available for digital processing, usually @@ -77,10 +83,10 @@ milliseconds.
-- Low latency is not always a feature you want to have. It + Low latency is not always a feature one wants 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). @@ -92,18 +98,21 @@
For a few applications, low latency is critical:
+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.)
+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.
+Low latency is important when using the computer as an effect rack for @@ -111,6 +120,7 @@ latency might be tolerable, if the direct sound is not routed through the computer.
+Some sound engineers use a computer for mixing live performances. @@ -120,10 +130,12 @@
In many other cases, such as playback, recording, overdubbing, mixing,
mastering, etc. latency is not important, since it can easily be
- compensated for.
- 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.
+ compensated for.
+
+ 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.
- As you may see, the second approach is prone to various implementation + 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 + to the audio signal that is heared on the speakers (and is not where Ardour reads files from disk).
@@ -152,7 +164,7 @@ 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 + Ardour 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.
@@ -166,10 +178,14 @@ 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: Jack Latency Compensation. -
+ + +In the figure above, clients A and B need to be able to answer the following two questions: @@ -197,7 +213,6 @@ measure it.
-Linux DSP guru Fons Adriaensen wrote a tool called jack_delay @@ -206,7 +221,7 @@ called jack_iodelay.
- Jack_iodelay allows you to measure the total latency of the system, + Jack_iodelay allows to measure the total latency of the system, subtracts the known latency of JACK itself and suggests values for jackd's audio-backend parameters.
@@ -216,7 +231,7 @@ difference in phase so it can estimate with great accuracy the time taken.- You can close the loop in a number of ways: + The loop can be closed in a number of ways:
- Once you have closed the loop you have to: + Once the loop has been closed, one must: