manual/include/monitor-signal-flow.html
Shamus Hammons dfec6899ef Initial cleanup of manual content.
This includes fixing em-dashes, badly spaced colons, various
misspellings, removal of spurious {% %} constructs, conversion of <br />
to <br> (still too many <br>s kicking around), and initial light cleanup
of a few sections that caught my eye.
2017-02-14 09:18:56 -06:00

35 lines
1.6 KiB
HTML

<p>There are three basic ways to approach monitoring: </p>
<h3>External Monitoring</h3>
<img class="right"
src="/images/external-monitoring.png" />
<p>When using <dfn>external monitoring</dfn>, Ardour plays no role in
monitoring at all. Perhaps the recording set-up has an external mixer which
can be used to set up monitor mixes, or perhaps the sound-card being used
has a "listen to the input" feature. This approach yields zero or near-zero
latency. On the other hand it requires external hardware, and the monitoring
settings are less flexible and not saved with the session.</p>
<h3>JACK-Based Hardware Monitoring</h3>
<img class="right" src="/images/jack-monitoring.png" />
<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,
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.
</p>
<h3>Software Monitoring</h3>
<img class="right" src="/images/ardour-monitoring.png" />
<p>With the <dfn>software monitoring</dfn> approach, all monitoring is
performed by Ardour&mdash;it makes track inputs available at track
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.
</p>