Add a couple of missing attach_buffers() calls after _ports has been changed. I...

[ardour2.git] / manual / xml / jack.xml

<?xml version="1.0" standalone="no"?>

<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [

]>

<section id="sn-configuring-jack">
  <title>Getting Audio In, Out and Around Your Computer</title>
  <para>
    Before you can begin to use Ardour, you will need to get the audio
    input/output capabilities of your system working and properly
    configured. There are two aspects to this process: getting your audio
    interface (soundcard) working, and configuring it to work with the Jack
    Audio Connection Kit (<ulink url="http://jackaudio.org/">JACK</ulink>).
  </para>

  <section id="sn-jack">
    <title>JACK</title>
    <para>
      It is extremely important to understand that Ardour does not interact
      directly with your audio interface when it is running. Instead, all of
      the audio data signals that Ardour receives and generates are sent to
      and from JACK, a piece of software that routes audio data between an
      audio interface and audio applications, in real time.
    </para>

    <para>
      Traditionally, most of the audio sources that you would want to
      record, as well as a lot of the more significant effects processing,
      existed outside the computer. Consequently one of the biggest issues
      in integrating a computer into the operation of the studio is how to
      move audio data in and out of the computer.
    </para>

    <para>
      However, it is becoming increasingly common for studios to use audio
      sources and effects processing that are comprised completely of
      software, quite often running on the same machine as an audio
      sequencer or digital audio workstation (DAW). A new problem arises in
      such situations, because moving audio in and out of the DAW no longer
      involves your hardware audio interface. Instead, data has to be moved
      from one piece of software to another, preferably with the same kind
      of sample synchronisation you’d have in a properly configured
      digital hardware system. This is a problem that has been solved at
      least a couple of times (ReWire from PropellerHeads and DirectConnect
      from Digidesign are the two most common examples), but JACK is a new
      design developed as an open source software project, and is thusly
      available for anyone to use, learn from, extend, *fix or modify.
    </para>

    <para>
      New users may not initially realize that by using Jack, their computer
      becomes an extremely flexible and powerful audio tool - especially
      with Ardour acting as the ’heart’ of the system.
    </para>
  </section>

  <section id="getting-audio-working">
    <title>Getting Your Audio Interface Working</title>
    <note>
      <para>
        Although Ardour runs on OS X as well as Linux, this documentation
        describes only a Linux (ALSA) system. The issues faced on OS X tend
        to be entirely different, and are centered mostly on JACK. There are
        also alternative audio device driver families for Linux but they are
        also not discussed here.
      </para>
    </note>

    <para>
      Getting your audio interface working can be the hardest part of
      setting your computer up to run Ardour, or it could be one of the
      easiest. The level of difficulty you will face depends on the type of
      audio interface ("soundcard") you are using, the operating system
      version you are using, and your own understanding of how it all works.
    </para>

    <para>
      In an ideal world, your computer already has a working audio
      interface, and all you need do is to start up qjackctl and run JACK.
      You can determine if you face this ideal situation by doing a few
      simple tests on your machine. The most obvious test is whether
      you’ve already heard audio coming out of your computer. If you are
      in this situation, you can skip ahead to
      <xref linkend="selecting-capture-source"/>.
    </para>
  </section>

  <section id="checking-for-an-audio-interface">
    <title>Checking For an Audio Interface</title>
    <para>
      If you’ve never tried to play audio on your computer before, you
      should use a basic playback program such as play, aplay or possibly
      xmms. Find an audio file on your machine (<command>locate
      .wav</command> may help here), and try to play it. There are several
      possibilities:
    </para>

    <itemizedlist>
      <listitem>
        <para>
          You may get an error from the program
        </para>
      </listitem>

      <listitem>
        <para>
          You may hear nothing
        </para>
      </listitem>

      <listitem>
        <para>
          You may hear something, but its too quiet
        </para>
      </listitem>

      <listitem>
        <para>
          you may hear something from the wrong loudspeakers.
        </para>
      </listitem>
    </itemizedlist>
  </section>

  <section id="selecting-capture-source">
    <title>Selecting Capture Source</title>
    <para>
      Many audio interfaces, particularly the cheaper varieties that are
      often found built into computers, have ways to plug in both
      microphones and instruments or other audio equipment to be recorded.
      This immediately poses a question: how does Ardour (or any software)
      know which signal to record, the one coming into the microphone input,
      or the one arriving at the "line in" socket? The same question arises
      also for "high-end" audio interfaces, though in different ways.
    </para>

    <para>
      The short answer is: Ardour doesn’t. Instead, this is a choice you
      have to make using a program a program that understands how to control
      the mixing hardware on the audio interface. Linux/ALSA has a number of
      such programs: alsamixer, gamix, aumix, kmix are just a few of them.
      Each of them offers you a way to select which of the possible
      recordable signals will be used for as the "capture source". How you
      select the preferred signal varies from program to program, so you
      will have to consult the help documentation for whichever program you
      choose to use.
    </para>

    <para>
      There are also a few programs that offer ways to control just one
      particular kind of audio interface. For example, the
      <application>hdspmixer</application> program offers control over the
      very powerful matrix mixer present on several RME audio interface.
      <application>envy24ctrl</application> does the same for a number of
      interfaces built around the common ice1712/envy24 chipset, found in
      devices from M-Audio, Terratec and others. Please note that this quite
      similar to the situation for Windows and MacOS users, where each audio
      interface often comes with its own control program that allows certain
      critical configuration choices to be made.
    </para>

    <section id="problems-with-input-signal">
      <title>"I don’t get any signal when I record …"</title>
      <para>
        The most common problem for first-time audio users on Linux is to
        try to record something and get no signal at all, or alternatively,
        a very low signal. The low signal problem typically arises from one
        or more of the following issues:
      </para>

      <itemizedlist>
        <listitem>
          <para>
            a microphone input plugged into the "line in" socket of the
            interface. The signal levels delivered by microphones are very
            small, and require amplification before they can be used by most
            audio circuitry. In professional recording studios, this is done
            using a dedicated box called a "pre-amplifier". If your audio
            interface has a "mic input" socket, then it has its own
            pre-amplifier built in, although its probably not a very good
            one. If you make the mistake of plugging a microphone into the
            "line in" socket, you will get either an inaudible or very quiet
            signal.
          </para>
        </listitem>

        <listitem>
          <para>
            the wrong capture source selected in the audio interface’s
            hardware mixer (see above)
          </para>
        </listitem>

        <listitem>
          <para>
            the "capture" gain level in the audio interface’s hardware
            mixer is turned down too low. You will need to use a hardware
            mixer application (as described above) to increase this.
          </para>
        </listitem>
      </itemizedlist>

      <note>
        <para>
          You will notice in the mixer strip for each track in ardour that
          you can change the selection of the monitoring source between
          input/pre/post. Adjusting the fader while watching the ’input’
          levels will NOT have any affect on the levels. As mentioned above,
          ardour is dependent on external mixer settings for a source level.
        </para>
      </note>
    </section>
  </section>

  <section id="monitoring-choices">
    <title>Monitoring Choices</title>
    <para>
      Its unfortunate that we have to raise this issue at a point in the
      manual where you, the reader, may not even knoiw what "monitoring"
      means. However, it is such an absolutely critical aspect of using any
      digital audio workstation that we need to at least cover the basics
      here. The only people who don’t need to care about monitoring are
      those who will never use ardour to record a live performance (even on
      performed using a software synthesizer).
    </para>

    <para>
      Monitoring is the term we use to describe listening to what ardour is
      recording. If you are playing a guitar and recording it with ardour,
      you can probably hear the guitar’s own sound, but there are many
      situations where relying on the sound of the instrument is completely
      inadequate. For example, with an electronic instrument, there is no
      sound until the electrical signal that it generates has been processed
      by an amplifier and fed to a loudspeaker. But if Ardour is recording
      the instrument’s signal, what is responsible for sending it to the
      amp+loudspeakers? It can get a lot more complex than that: if you are
      recording multiple performers at the same time, each performer needs
      to hear their own playing/singing, but they also probably need to hear
      some of their colleagues’ sound as well. You might be overdubbing
      yourself - playing a new line on an instrument while listening to
      tracks you’ve already recorded - how do you hear the new material as
      well as the existing stuff?
    </para>

    <para>
      Well, hopefully, you’re convinced that there are some questions to
      be dealt with surrounding monitoring, see
      <xref linkend="sn-monitoring"/> for more in depth information.
    </para>
  </section>

  <section id="using-multiple-soundcards">
    <title>Can I use multiple soundcards</title>
    <para>
      There are really lots of great reasons why you should not even attempt
      to do this. But seriously, save your money for a while and buy
      yourself a properly designed multichannel soundcard.
    </para>
  </section>

  <section id="qjackctl">
    <title>Qjackctl</title>
    <para>
      JACK itself does not come with graphical user interface - to start
      JACK and control it you need to have access to a command line and a
      basic knowledge of Unix-like operating systems. However,
      <ulink url="http://qjackctl.sourceforge.net/">qjackctl</ulink> is a
      wonderful application that wraps JACK up with a graphical interface
      that is both nice to look at and useful at same time. qjackctl is the
      recommended way of using JACK.
    </para>
    <mediaobject>
      <imageobject>
        <imagedata fileref="images/qjackctl.png"/>
      </imageobject>
    </mediaobject>
    <para>
      You should be able to start qjackctl from the “application menu”
      of your system, typically found on the panel/appbar/dock or whatever
      its called that lives at the top/bottom/left/right of your screen.
    </para>

    <para>
      [ need screenshot of GNOME/KDE/OSX menus here ]
    </para>
  </section>
<!--
        <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" 
                href="Some_Subsection.xml" />
        -->
</section>