fix some typos, clarify wording

diff --git a/_manual/19_synchronization/02_latency-and-latency-compensation.html b/_manual/19_synchronization/02_latency-and-latency-compensation.html
index 2ce04981ecd724b7ce25af5a86856ca418aeaf39..950b5310c40f088ef2655329f98d8cbabf0b8694 100644 (file)
--- 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 <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>