diff --git a/_manual/19_synchronization/02_latency-and-latency-compensation.html b/_manual/19_synchronization/02_latency-and-latency-compensation.html index 2ce0498..950b531 100644 --- a/_manual/19_synchronization/02_latency-and-latency-compensation.html +++ b/_manual/19_synchronization/02_latency-and-latency-compensation.html @@ -53,7 +53,7 @@ The digital I/O latency is usually negligible for integrated or 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 (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.

@@ -79,12 +79,12 @@ During tracking it is important that the sound that is currently being played ba

-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 (relative to the playhead), so that when the sound hits the speakers a short time later, it is exactly aligned with 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).