manual/xml/synchronization_concepts.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-synchronization_concepts">
   8   <title>Synchronization Concepts</title>
   9   <para>
  10     As soon as you start handling audio on more than one device, it is
  11     important to understand and to think about
  12     <emphasis>synchronization</emphasis> : how to get the devices to have
  13     the same sense of time and speed.
  14   </para>
  15
  16   <para>
  17     However, there are two fundamentally different kinds of synchronization:
  18   </para>
  19
  20   <section id="sample-clock">
  21     <title>Sample Clock</title>
  22     <para>
  23       As outlined in the <emphasis>introductory concepts</emphasis> section,
  24       digital audio is created by taking a "sample" of an analog signal
  25       level on a periodic basis, say 48000 times per seconds (the "sample
  26       rate"). A dedicated clock (the "sample clock") ((actually, an
  27       oscillating crystal, but technology people call such things clocks))
  28       "ticks" at that rate, and every time it does, a new sample is
  29       measured. The way the clock is used to convert digital audio back to
  30       an analog signal (i.e. to be sent to some loudspeakers) is more
  31       complex, but the clock is still an absolutely fundamental part of the
  32       mechanism.
  33     </para>
  34
  35     <para>
  36       Whenever you connect two digital audio devices together in order to
  37       move audio data from one to the other, you <emphasis>must ensure they
  38       share the same sample clock</emphasis> . Why is this necessary? The
  39       oscillating crystals used for the sample clock are generally very
  40       stable (they always tick at the same speed), but there are always
  41       minute differences in the speed that any two clocks tick at. When used
  42       by themselves, this makes no difference, but connect two digital audio
  43       devices together and these minute differences will eventually
  44       accumulate over time. Eventually, one of the devices will be trying to
  45       read a sample "in the middle" of the other device's tick, and the
  46       result is a small click or pop in the audio stream.
  47     </para>
  48   </section>
  49
  50   <section id="timeline-sync">
  51     <title>Timeline Sync</title>
  52     <para>
  53       The concept of a timeline comes up over and over again when working
  54       with a digital audio workstation, and also with video editing systems.
  55       By "timeline" we mean nothing more than some way to define a "name"
  56       for the point where certain sounds (and/or visual images) occur. When
  57       you work in Ardour's editor window, the rulers near the top provide
  58       one or more timelines in different units. You can look at the editor
  59       window and say "this sound starts at 1 minute 32 seconds" or "this
  60       tracks fades out starting at bar 13 beat 22".
  61     </para>
  62
  63     <para>
  64       But what happens when you want to share a timeline between two
  65       different devices? For example, you may want to run a hardware video
  66       editor in conjunction with ardour, and always have the visual and
  67       audio playback be at the same point "in time". How do they each know
  68       what "in time" means? How do they know where the other one is? A
  69       mechanism for answering these questions provides <emphasis>timeline
  70       synchronization</emphasis> .
  71     </para>
  72
  73     <para>
  74       Timeline synchronization is entirely different from sample clock
  75       synchronization. Two devices can share a sample clock, but never use
  76       timeline information. Two devices can be sharing timeline information,
  77       but run on different sample clocks - they might not even have sample
  78       clocks if they are analog devices.
  79     </para>
  80   </section>
  81
  82   <section id="word-clock">
  83     <title>Word Clock</title>
  84     <para>
  85       "Word Clock" is the name given to a signal used to distribute the
  86       "ticks" of a sample clock to multiple devices. Most digital audio
  87       devices that are intended for professional use have a word clock
  88       connector and a way to tell the device to use either its internal
  89       sample clock (for standalone use), or to use the word clock signal as
  90       the sample clock. Because of the electrical characteristics of the
  91       signal, it is very important that any length of cable used to
  92       distribute word clock is "terminated" with a 75 ohm resistor at both
  93       ends. Unfortunately, some devices include this terminator themselves,
  94       some contain a switchable resistor and some do not. Worse still, the
  95       user manuals for many devices do not provide any information on their
  96       termination configuration. It is often necessary to ask the
  97       manufacturer in cases where it is not made very obvious from marking
  98       near the word clock connectors on the device.
  99     </para>
 100   </section>
 101
 102   <section id="timecode">
 103     <title>Timecode</title>
 104     <para>
 105       "Timecode" is a signal that contains positional or "timeline"
 106       information. There are several different kinds of timecode signal, but
 107       by far the most important is known as SMPTE. Its name is an acronym
 108       for the Society for Motion Picture T?? Engineering, and timecode is
 109       just one of the standards they defined, but its the most well known.
 110       Because of its origins in the film/video world, SMPTE is very centered
 111       on the time units that matter to film/video editors. The base unit is
 112       called a "frame" and corresponds to a single still image in a film or
 113       video. There are typically on the order of 20-30 frames per second, so
 114       the actual resolution of SMPTE timecode is not very good compared to
 115       audio-based units where there are tens of thousands of "frames" per
 116       second.
 117     </para>
 118   </section>
 119
 120   <section id="SMPTE">
 121     <title>SMPTE</title>
 122     <para>
 123       SMPTE defines time using a combinations of hours, minutes, seconds,
 124       frames and subframes, combined with the frame rate. In a film/video
 125       environment, SMPTE is typically stored on the film/video media, and
 126       sent from the device used to play it. There are different ways of
 127       storing it on the media - you may come across terms like LTR and VTC -
 128       but the crucial idea to grasp is that the film/video has a timecode
 129       signal "stamped" into it, so that it is always possible to determine
 130       "what time it is" when any given image is visible.
 131     </para>
 132
 133     <para>
 134       SMPTE timecode is sent from one system to another as an analog audio
 135       signal. You could listen to it if you wanted to, though it sounds like
 136       a generally screeching and unpleasant noise. What the SMPTE standard
 137       defines is a way to encode and decode the
 138       hrs:mins:secs:frames:subframes time into or from this audio signal.
 139     </para>
 140   </section>
 141
 142   <section id="mtc">
 143     <title>MTC</title>
 144     <para>
 145       The other very common form of timecode is known as "MTC" (MIDI Time
 146       Code). However, MTC is actually nothing more than a different way to
 147       transmit SMPTE timecode. It uses the exact same units as SMPTE
 148       timecode, but rather than send the signal as audio MTC defines a
 149       transmission method that uses a MIDI cabable and a data protocol. MTC
 150       consumes a measurable, but small, percentage of the available
 151       bandwidth on a MIDI cable (on the order of 2-3%). Most of the time, it
 152       is wise to use a single cable for MTC and MMC (MIDI Machine Control)
 153       and not share it with "musical" MIDI data (the kind that an instrument
 154       would send while being played).
 155     </para>
 156   </section>
 157
 158   <section id="jack-transport">
 159     <title>JACK Transport</title>
 160     <para>
 161       For Ardour and other programs that use <emphasis>JACK</emphasis>,
 162       there is another method of doing timeline synchronization that is not
 163       based on SMPTE or MTC.
 164     </para>
 165   </section>
 166 <!--
 167         <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
 168                 href="Some_Subsection.xml" />
 169         -->
 170 </section>