X-Git-Url: http://shamusworld.gotdns.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=include%2Fmonitor-signal-flow.html;h=5560d4b33619bef77175e39d12014344c21c9242;hb=8842cf2c02a0ff38f83798d10388c3c81b2d20d4;hp=84b4eef8269c678e1d3cb1968fca3c3442495f7c;hpb=1bc084d882bf5792634c5fd08c35eff78de26b02;p=ardour-manual

diff --git a/include/monitor-signal-flow.html b/include/monitor-signal-flow.html
index 84b4eef..5560d4b 100644
--- a/include/monitor-signal-flow.html
+++ b/include/monitor-signal-flow.html
@@ -17,7 +17,7 @@
   latency.  On the other hand it requires external hardware, and the monitoring
   settings are less flexible and not saved with the session.</p>
 
-<h3 class="clear">JACK-Based Hardware Monitoring</h3>
+<h3 class="clear">Audio driver Hardware Monitoring</h3>
 
 <figure class="right">
     <img src="/images/jack-monitoring.png" alt="Hardware Monitoring">
@@ -29,7 +29,7 @@
 <p>Some sound cards have the ability
   to mix signals from their inputs to their outputs with very low or even zero
   latency, a feature called <dfn>hardware monitoring</dfn>.
-  Furthermore, on some cards this function can be controlled by JACK. This is a nice arrangement,
+  Furthermore, on some cards this function can be controlled by Ardour. This is a nice arrangement,
   if the sound card supports it, as it combines the convenience of having the
   monitoring controlled by Ardour with the low latency operation of doing it
   externally.
@@ -49,6 +49,6 @@
   outputs, governed by various controls. This approach will almost always have
   more routing flexibility than JACK-based monitoring. The disadvantage is
   that there will be some latency between the input and the output, which
-  depends for the most part on the JACK buffer size that is being used.
+  depends for the most part on the buffer size that is being used.
 </p>