ardour/manual
13
0
Fork 0
Code Pull Requests Releases Activity

fix some typos, clarify wording

Browse Source
This commit is contained in:
Robin Gareus 2013-03-11 01:51:04 +01:00
parent 994f86e7fe
commit 05ccd18414
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
_manual/19_synchronization/02_latency-and-latency-compensation.html
View File

@ -53,7 +53,7 @@ The digital I/O latency is usually negligible for integrated or <abbr title="Per
</p>
<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). Furthermore, if more than one application (sound-processor) is involved in processing the sound, each of these needs to run for a short time 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 <a href="https://rt.wiki.kernel.org/" title="https://rt.wiki.kernel.org/">realtime-kernel</a>.
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). 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 <a href="https://rt.wiki.kernel.org/" title="https://rt.wiki.kernel.org/">realtime-kernel</a>.
</p>
<p>
@ -79,12 +79,12 @@ During tracking it is important that the sound that is currently being played ba
</p>
<p>
This is where latency-compensation comes into play. There are two possibilities to compensate for latency in a DAW: <em>read-ahead</em> 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 <em>write-behind</em> 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: <em>read-ahead</em> 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 <em>write-behind</em>; 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 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).
</p>
<p>