Removing unused images, a tiny bit of styling

[ardour-manual] / include / latency-and-latency-compensation.html

diff --git a/include/latency-and-latency-compensation.html b/include/latency-and-latency-compensation.html
index fda8ec96e83b1de231dc32f266a08e65760a785e..62009f24d66c3bcf862f6080c72315427ec95e1c 100644 (file)
--- a/include/latency-and-latency-compensation.html
+++ b/include/latency-and-latency-compensation.html
@@ -45,9 +45,9 @@
 
 <img src="/images/latency-chain.png"  title="Latency chain" alt="Latency chain" />
 <p>
-  <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
+  <em>Figure: Latency chain.</em> 
+  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.
 </p>
 
@@ -55,7 +55,7 @@
   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
   one audio period), and <dfn>playback latency</dfn> (the time it takes for
-  In practice, the combination of both matters. It is called <dfn>roundtrip
+  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,
   processed and played back.
 </p>
@@ -78,12 +78,12 @@
 </p>
 
 
-<h2>Low Latency usecases</h2>
+<h2>Low Latency use cases</h2>
 <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).
+  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.
@@ -95,7 +95,7 @@
 <h3>Playing virtual instruments</h3>
 <p>
   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
+  produces will throw off the timing of most instrumentalists (save church
   organists, whom we believe to be awesome latency-compensation organic systems.)
 </p>
 <h3>Software audio monitoring</h3>
@@ -132,19 +132,19 @@
   played back is internally aligned with the sound that is being recorded.
 </p>
 <p>
-  This is where latency-compensation comes into play. There are two ways to
+  This is where latency compensation comes into play. There are two ways to
   compensate for latency in a DAW, <dfn>read-ahead</dfn> and
   <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
   later, it is exactly aligned with the material that is being recorded.
-  Since we know that play-back has latency, the incoming audio can be delayed
+  Since we know that playback 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 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 you hear on the speakers (and is not where Ardour
   reads files from disk).
 </p>
 <p>
@@ -180,7 +180,7 @@
     edge of the JACK graph (capture)?
   </li>
   <li>
-    How long will it be until the data writen to port Ao or Bo arrives at the
+    How long will it be until the data written to port Ao or Bo arrives at the
     edge of the JACK graph (playback)?
   </li>
 </ul>
@@ -201,7 +201,7 @@
 <h2>Calibrating JACK Latency</h2>
 <p>
   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,
+  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
   called <dfn>jack_iodelay</dfn>.
 </p>
@@ -236,7 +236,7 @@
 </p>
 <ol>
   <li>Launch jackd with the configuration you want to test.</li>
-  <li>Launch <kbd class="input">jack_delay</kbd> on the commandline.</li>
+  <li>Launch <kbd class="input">jack_delay</kbd> on the command line.</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>
 </ol>