Paul Davis
45d3ec1437
git-svn-id: svn://localhost/ardour2/branches/2.1-staging@1698 d708f5d6-7413-0410-9779-e7cbd77b26cf
171 lines
7.8 KiB
XML
171 lines
7.8 KiB
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-synchronization_concepts">
|
|
<title>Synchronization Concepts</title>
|
|
<para>
|
|
As soon as you start handling audio on more than one device, it is
|
|
important to understand and to think about
|
|
<emphasis>synchronization</emphasis> : how to get the devices to have
|
|
the same sense of time and speed.
|
|
</para>
|
|
|
|
<para>
|
|
However, there are two fundamentally different kinds of synchronization:
|
|
</para>
|
|
|
|
<section id="sample-clock">
|
|
<title>Sample Clock</title>
|
|
<para>
|
|
As outlined in the <emphasis>introductory concepts</emphasis> section,
|
|
digital audio is created by taking a "sample" of an analog signal
|
|
level on a periodic basis, say 48000 times per seconds (the "sample
|
|
rate"). A dedicated clock (the "sample clock") ((actually, an
|
|
oscillating crystal, but technology people call such things clocks))
|
|
"ticks" at that rate, and every time it does, a new sample is
|
|
measured. The way the clock is used to convert digital audio back to
|
|
an analog signal (i.e. to be sent to some loudspeakers) is more
|
|
complex, but the clock is still an absolutely fundamental part of the
|
|
mechanism.
|
|
</para>
|
|
|
|
<para>
|
|
Whenever you connect two digital audio devices together in order to
|
|
move audio data from one to the other, you <emphasis>must ensure they
|
|
share the same sample clock</emphasis> . Why is this necessary? The
|
|
oscillating crystals used for the sample clock are generally very
|
|
stable (they always tick at the same speed), but there are always
|
|
minute differences in the speed that any two clocks tick at. When used
|
|
by themselves, this makes no difference, but connect two digital audio
|
|
devices together and these minute differences will eventually
|
|
accumulate over time. Eventually, one of the devices will be trying to
|
|
read a sample "in the middle" of the other device's tick, and the
|
|
result is a small click or pop in the audio stream.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="timeline-sync">
|
|
<title>Timeline Sync</title>
|
|
<para>
|
|
The concept of a timeline comes up over and over again when working
|
|
with a digital audio workstation, and also with video editing systems.
|
|
By "timeline" we mean nothing more than some way to define a "name"
|
|
for the point where certain sounds (and/or visual images) occur. When
|
|
you work in Ardour's editor window, the rulers near the top provide
|
|
one or more timelines in different units. You can look at the editor
|
|
window and say "this sound starts at 1 minute 32 seconds" or "this
|
|
tracks fades out starting at bar 13 beat 22".
|
|
</para>
|
|
|
|
<para>
|
|
But what happens when you want to share a timeline between two
|
|
different devices? For example, you may want to run a hardware video
|
|
editor in conjunction with ardour, and always have the visual and
|
|
audio playback be at the same point "in time". How do they each know
|
|
what "in time" means? How do they know where the other one is? A
|
|
mechanism for answering these questions provides <emphasis>timeline
|
|
synchronization</emphasis> .
|
|
</para>
|
|
|
|
<para>
|
|
Timeline synchronization is entirely different from sample clock
|
|
synchronization. Two devices can share a sample clock, but never use
|
|
timeline information. Two devices can be sharing timeline information,
|
|
but run on different sample clocks - they might not even have sample
|
|
clocks if they are analog devices.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="word-clock">
|
|
<title>Word Clock</title>
|
|
<para>
|
|
"Word Clock" is the name given to a signal used to distribute the
|
|
"ticks" of a sample clock to multiple devices. Most digital audio
|
|
devices that are intended for professional use have a word clock
|
|
connector and a way to tell the device to use either its internal
|
|
sample clock (for standalone use), or to use the word clock signal as
|
|
the sample clock. Because of the electrical characteristics of the
|
|
signal, it is very important that any length of cable used to
|
|
distribute word clock is "terminated" with a 75 ohm resistor at both
|
|
ends. Unfortunately, some devices include this terminator themselves,
|
|
some contain a switchable resistor and some do not. Worse still, the
|
|
user manuals for many devices do not provide any information on their
|
|
termination configuration. It is often necessary to ask the
|
|
manufacturer in cases where it is not made very obvious from marking
|
|
near the word clock connectors on the device.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="timecode">
|
|
<title>Timecode</title>
|
|
<para>
|
|
"Timecode" is a signal that contains positional or "timeline"
|
|
information. There are several different kinds of timecode signal, but
|
|
by far the most important is known as SMPTE. Its name is an acronym
|
|
for the Society for Motion Picture T?? Engineering, and timecode is
|
|
just one of the standards they defined, but its the most well known.
|
|
Because of its origins in the film/video world, SMPTE is very centered
|
|
on the time units that matter to film/video editors. The base unit is
|
|
called a "frame" and corresponds to a single still image in a film or
|
|
video. There are typically on the order of 20-30 frames per second, so
|
|
the actual resolution of SMPTE timecode is not very good compared to
|
|
audio-based units where there are tens of thousands of "frames" per
|
|
second.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="SMPTE">
|
|
<title>SMPTE</title>
|
|
<para>
|
|
SMPTE defines time using a combinations of hours, minutes, seconds,
|
|
frames and subframes, combined with the frame rate. In a film/video
|
|
environment, SMPTE is typically stored on the film/video media, and
|
|
sent from the device used to play it. There are different ways of
|
|
storing it on the media - you may come across terms like LTR and VTC -
|
|
but the crucial idea to grasp is that the film/video has a timecode
|
|
signal "stamped" into it, so that it is always possible to determine
|
|
"what time it is" when any given image is visible.
|
|
</para>
|
|
|
|
<para>
|
|
SMPTE timecode is sent from one system to another as an analog audio
|
|
signal. You could listen to it if you wanted to, though it sounds like
|
|
a generally screeching and unpleasant noise. What the SMPTE standard
|
|
defines is a way to encode and decode the
|
|
hrs:mins:secs:frames:subframes time into or from this audio signal.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="mtc">
|
|
<title>MTC</title>
|
|
<para>
|
|
The other very common form of timecode is known as "MTC" (MIDI Time
|
|
Code). However, MTC is actually nothing more than a different way to
|
|
transmit SMPTE timecode. It uses the exact same units as SMPTE
|
|
timecode, but rather than send the signal as audio MTC defines a
|
|
transmission method that uses a MIDI cabable and a data protocol. MTC
|
|
consumes a measurable, but small, percentage of the available
|
|
bandwidth on a MIDI cable (on the order of 2-3%). Most of the time, it
|
|
is wise to use a single cable for MTC and MMC (MIDI Machine Control)
|
|
and not share it with "musical" MIDI data (the kind that an instrument
|
|
would send while being played).
|
|
</para>
|
|
</section>
|
|
|
|
<section id="jack-transport">
|
|
<title>JACK Transport</title>
|
|
<para>
|
|
For Ardour and other programs that use <emphasis>JACK</emphasis>,
|
|
there is another method of doing timeline synchronization that is not
|
|
based on SMPTE or MTC.
|
|
</para>
|
|
</section>
|
|
<!--
|
|
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
href="Some_Subsection.xml" />
|
|
-->
|
|
</section>
|