manual/xml/monitoring.xml

   1 <?xml version="1.0" standalone="no"?>
   2
   3 <!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
   4
   5 ]>
   6
   7 <section id="sn-monitoring">
   8   <title>Monitoring</title>
   9   <para>
  10     If you are recording an acoustic instrument or voice with no
  11     pre-existing recorded material as an accompaniment, then you probably
  12     don't need to worry about monitoring. Just make sure you've made the
  13     right <link linkend="sn-jack">connections</link> and you should be ready
  14     to record without reading this section.
  15   </para>
  16
  17   <para>
  18     However, if a musician is playing an instrument (it doesn't matter what
  19     kind) while listening to some pre-existing material, then it is
  20     important that some mechanism exists to allow her to hear both her own
  21     playing and the accompaniment. The same is true in a slightly different
  22     way if the instrument makes no sound until the electrical signal it
  23     creates has been amplified and fed to some loudspeakers. Listening to
  24     the performance in this way is called monitoring.
  25   </para>
  26
  27   <para>
  28     So, if you are recording an electrical or software instrument/signal,
  29     and/or the musician wants to listen to existing material while
  30     performing, then you need to ensure that signal routing is setup to
  31     allow monitoring. You have 2 basic choices:
  32   </para>
  33
  34   <section id="hardware-monitoring">
  35     <title>Hardware Monitoring</title>
  36     <para>
  37       Hardware monitoring uses the capabilities of your audio interface to
  38       route an incoming signal (e.g. someone playing a guitar into a
  39       microphone) to an output connection (for example, the speaker outputs,
  40       or a dedicated analog monitoring stereo pair). Most audio interfaces
  41       can do this, but how you get them to do so, and what else they can do
  42       varies greatly. We can divide audio interfaces into 3 general
  43       categories:
  44     </para>
  45
  46     <itemizedlist>
  47       <listitem>
  48         <para>
  49           relatively simple, typically stereo, devices that allow the signal
  50           being recorded to be routed back to the main outputs (most
  51           "consumer" audio interfaces fit this description, along with
  52           anything that provides an "AC97-compliant CODEC")
  53         </para>
  54       </listitem>
  55
  56       <listitem>
  57         <para>
  58           multichannel devices that allow a given input channel to be routed
  59           back to its corresponding output channel (the main example is the
  60           RME Digi9652)
  61         </para>
  62       </listitem>
  63
  64       <listitem>
  65         <para>
  66           multichannel devices that allow any input channel, along with any
  67           playback channel, to be routed to any output channel (the RME HDSP
  68           and various interfaces based on the envy24/ice1712 chipsets, such
  69           as the M-Audio Delta 1010, EZ-8 and various Terratec cards)
  70         </para>
  71       </listitem>
  72     </itemizedlist>
  73
  74     <section id="monitoring-consumer-audio-interfaces">
  75       <title>"Consumer" audio interfaces and monitoring</title>
  76       <para>
  77         For interfaces in the first category, there is no standard method of
  78         getting the signal routing correct. The variations in the wiring of
  79         hardware mixing chips, and the capabilities of those chips, means
  80         that you will have to get familiar with a hardware mixer control
  81         program and the details of your audio interface. In the simple
  82         cases, simply increasing the level named "Line In" or "Mic" in the
  83         hardware mixer control program will suffice. But this is not a
  84         general rule, because there is no general rule.
  85       </para>
  86
  87       <para>
  88         The following diagram shows a fairly typical AC97-based audio
  89         interface schematic:
  90       </para>
  91       <mediaobject>
  92         <imageobject>
  93           <imagedata fileref="images/simplemixer.png"/>
  94         </imageobject>
  95       </mediaobject>
  96       <para>
  97         Notice:
  98       </para>
  99
 100       <itemizedlist>
 101         <listitem>
 102           <para>
 103             there are multiple input connections, but only one can be used
 104             as the capture source
 105           </para>
 106         </listitem>
 107
 108         <listitem>
 109           <para>
 110             it is (normally) possible to route the input signals back to the
 111             outputs, and independently control the gain for this "monitored"
 112             signal
 113           </para>
 114         </listitem>
 115
 116         <listitem>
 117           <para>
 118             it may or may not be possible to choose the playback stream as
 119             the capture stream
 120           </para>
 121         </listitem>
 122       </itemizedlist>
 123     </section>
 124
 125     <section id="monitoring-prosumer-audio-interfaces">
 126       <title>High end "prosumer" interfaces and monitoring</title>
 127       <para>
 128         For the only interface in the second category, the RME Digi9652
 129         ("Hammerfall"), the direct monitoring facilities are simplistic but
 130         useful in some circumstances. They are best controlled using
 131         <emphasis>JACK hardware monitoring</emphasis>.
 132       </para>
 133
 134       <para>
 135         When using one of the interfaces in the third category, most people
 136         find it useful to use hardware monitoring, but prefer to control it
 137         using a dedicated hardware mixer control program. If you have an RME
 138         HDSP system, then <command>hdspmixer</command> is the relevant
 139         program. For interfaces based on the envy24/ice1712/ice1724
 140         chipsets, such as the Delta1010, Terratecs and others,
 141         <command>envy24ctl</command> is the right choice. Both programs
 142         offer access to very powerful matrix mixers that permit many
 143         different variations on signal routing, for both incoming signals
 144         and the signals being played back by the computer. You will need to
 145         spend some time working with these programs to grasp their potential
 146         and their usage in different situations.
 147       </para>
 148
 149       <para>
 150         The following diagram gives a partial view of the monitoring
 151         schemantics for this class of audio interface. Each input can be
 152         routed back to any output, and each such routing has its own gain
 153         control. The diagram only shows the routings for "in1" to avoid
 154         becoming completely incomprehensible.
 155       </para>
 156       <mediaobject>
 157         <imageobject>
 158           <imagedata fileref="images/matrixmixer.png"/>
 159         </imageobject>
 160       </mediaobject>
 161     </section>
 162   </section>
 163
 164   <section id="jack-hardware-monitoring">
 165     <title>JACK hardware monitoring</title>
 166     <para></para>
 167   </section>
 168
 169   <section id="software-monitoring">
 170     <title>Software monitoring</title>
 171     <para>
 172       Much simpler than hardware monitoring is "software monitoring". This
 173       means that any incoming signal (say, through a Line In connector) is
 174       delivered to software (such as Ardour) which can then deliver it back
 175       to any output it chooses, possibly having subjected it to various
 176       processing beforehand. The software can also mix signals together
 177       before delivering them back to the output. The fact that software
 178       monitoring can blend together incoming audio with pre-recorded
 179       material while adjusting for latency and other factors is the big plus
 180       for this method. The major downside is latency. There will always be a
 181       delay between the signal arriving at your audio interface inputs and
 182       it re-emerging from the outputs, and if this delay is too long, it can
 183       cause problems for the performer who is listening. They will sense a
 184       delay between pressing a key/pulling the bow/hitting the drum etc. and
 185       hearing the sound it produces.
 186     </para>
 187
 188     <para>
 189       However, if your system is capable of low latency audio, its likely
 190       that you can use software monitoring effectively if it suits your
 191       goals.
 192     </para>
 193   </section>
 194
 195   <section id="controlling-monitoring-within-ardour">
 196     <title>Controlling monitoring choices within Ardour</title>
 197     <para></para>
 198   </section>
 199 <!--
 200         <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
 201                 href="Some_Subsection.xml" />
 202         -->
 203 </section>