manual/include/on-clock-and-time.html

71 lines
2.8 KiB
HTML
Raw Normal View History

2013-02-15 13:21:59 -05:00
<p>
<dfn>Synchronization</dfn> in multimedia involves two concepts which are
often confused: <dfn>clock</dfn> (or speed) and <dfn>time</dfn> (location
2014-02-18 17:13:02 -05:00
in time).
2013-02-15 13:21:59 -05:00
</p>
<p>
2017-03-09 06:39:33 -05:00
A <dfn>clock</dfn> determines the speed at which one or more systems
operate. In the audio world this is generally referred to as
2017-01-03 12:03:08 -05:00
<a href="https://en.wikipedia.org/wiki/Word_clock" title="https://en.wikipedia.org/wiki/Word_clock">Word Clock</a>.
It does not carry any absolute reference to a point in time: A clock is
2014-02-18 17:13:02 -05:00
used to keep a system's sample rate regular and accurate.
Word clock is usually at the frequency of the sample rate&mdash;at 48&nbsp;kHz,
its period is about 20&nbsp;μs. Word Clock is the most
common sample rate based clock but other clocks do exist such as Black and
2014-02-18 17:13:02 -05:00
Burst, Tri-Level and DARS. Sample rates can be derived from these clocks as well.
2013-02-15 13:21:59 -05:00
</p>
<p>
Time or <dfn>timecode</dfn> specifies an absolute position on a timeline,
such as <code>01:02:03:04</code> (expressed as Hours:Mins:Secs:Frames). It is
2014-02-18 17:13:02 -05:00
actual <em>data</em> and not a clock <em>signal</em> per se.
The granularity of timecode is <dfn>Video Frames</dfn> and is an order of
magnitude lower than, say, Word Clock which is counted in
2014-02-18 17:13:02 -05:00
<dfn>samples</dfn>. A typical frame rate is 25&nbsp;<abbr title="frames
per second">fps</abbr> with a period of
40&nbsp;ms.
In the case of 48&nbsp;kHz and 25&nbsp;fps, there are 1920 audio samples
2014-02-18 17:13:02 -05:00
per video frame.
2013-02-15 13:21:59 -05:00
</p>
<p>
2014-02-18 17:13:02 -05:00
The concepts of clock and timecode are reflected in JACK and Ardour:
2013-02-15 13:21:59 -05:00
</p>
<p>
JACK (Ardour does this internally if using the ALSA backend) provides
clock synchronization and is not concerned with time code
2014-02-18 17:13:02 -05:00
(this is not entirely true, more on jack-transport later).
On the software side, jackd provides sample-accurate synchronization
2014-02-18 17:13:02 -05:00
between all JACK applications.
On the hardware side, JACK and Ardour use the clock of the audio-interface.
Synchronization of multiple interfaces requires hardware support to sync
2014-02-18 17:13:02 -05:00
the clocks.
If two interfaces run at different clocks the only way to align the
signals is via re-sampling (SRC&mdash;Sample Rate Conversion), which is
2017-02-14 10:20:06 -05:00
expensive in terms of CPU usage and may decrease fidelity if done
2014-02-18 17:13:02 -05:00
incorrectly.
2013-02-15 13:21:59 -05:00
</p>
<p>
Timecode is used to align systems already synchronized by a clock to
a common point in time, this is application specific and various
2014-02-18 17:13:02 -05:00
standards and methods exist to do this.
2013-02-15 13:21:59 -05:00
</p>
2014-02-18 17:13:02 -05:00
<p class="note">
To make things confusing, there are possibilities to synchronize clocks
using timecode. e.g. using mechanism called <dfn>jam-sync</dfn> and a
2014-02-18 17:13:02 -05:00
<dfn>phase-locked loop</dfn>.
2013-02-15 13:21:59 -05:00
</p>
2013-02-15 18:49:44 -05:00
<p>
An interesting point to note is that LTC (Linear Time Code) is a
Manchester encoded, frequency modulated signal that carries both
clock and time. It is possible to extract absolute position data
2014-02-18 17:13:02 -05:00
and speed from it.
2013-02-15 18:49:44 -05:00
</p>
2017-03-14 23:57:34 -04:00