From: Robin Gareus Date: Fri, 15 Feb 2013 23:49:44 +0000 (+0100) Subject: rework content of the sync chapter X-Git-Url: http://shamusworld.gotdns.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=27ff2f09a183a7cd1d105bdd73a91d0e29e0b766;hp=7a02ccdce1f9599b9ea5b1a08f53f913474eec25;p=ardour-manual rework content of the sync chapter --- diff --git a/_manual/19_synchronization/01_on-clock-and-time.html b/_manual/19_synchronization/01_on-clock-and-time.html index e0bf469..a876824 100644 --- a/_manual/19_synchronization/01_on-clock-and-time.html +++ b/_manual/19_synchronization/01_on-clock-and-time.html @@ -20,10 +20,6 @@ The granularity of timecode is Video Frames and is an order of In the case of 48kHz and 25fps, there are 1920 samples per video frame.

-

-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 and speed from it. -

-

The concept of clock and timecode is reflected in JACK and Ardour:

@@ -43,4 +39,7 @@ Timecode is used to align systems already synchronized by a clock to a common po NB. to make things confusing, there are possibilities to synchronize clocks using timecode. e.g. using mechanism called jam-sync and a Phase-Locked-Loop.

+

+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 and speed from it. +

diff --git a/_manual/19_synchronization/02_latency-and-latency-compensation.html b/_manual/19_synchronization/02_latency-and-latency-compensation.html index 4e049d0..deccb31 100644 --- a/_manual/19_synchronization/02_latency-and-latency-compensation.html +++ b/_manual/19_synchronization/02_latency-and-latency-compensation.html @@ -20,7 +20,7 @@ In order to achieve exact time synchronization all sources of latency need to be
  • Digital-to-Analog and Analog-to-Digital conversion: electric signals travel quite fast, so their propagation time is negligible in this context, but the conversions between the analog and digital domain take a comparatively long time to perform, so their contribution to the total latency may be considerable. Fast converters are, for instance, one of the factors that distinguishes a quality audio interface from a cheap one, along with other features like low noise, low distortion, etc.
  • Digital Signal Processing: digital processors tend to process audio in chunks, and the size of that chunk depends on the needs of the algorithm and performance/cost considerations. This is usually the main cause of latency when you use a computer and one you can try to predict and optimize.
    • -
  • Computer I/O Architecture: a computer is a general purpose processor, not a digital audio processor. This means our audio data has to jump a lot of fences in his path from the outside to the CPU and back, contending in the process with some other parts of the system vying for the same resources (CPU time, bus bandwidth, etc.) Thanks to the combined efforts of kernel, audio driver and jackd developers, you are in position to tune your system a bit more towards the digital audio processing task, but don't expect miracles. Remember you can use your computer also to write documents, surf the net, save some lemmings… Polyvalence comes at a cost.
    • +
  • Computer I/O Architecture: a computer is a general purpose processor, not a digital audio processor. This means our audio data has to jump a lot of fences in its path from the outside to the CPU and back, contending in the process with some other parts of the system vying for the same resources (CPU time, bus bandwidth, etc.) Thanks to the combined efforts of kernel, audio driver and jackd developers, you are in position to tune your system a bit more towards the digital audio processing task, but don't expect miracles. Remember you can use your computer also to write documents, surf the net, save some lemmings… Polyvalence comes at a cost.

    • Latency chain

    @@ -45,7 +45,7 @@ But this division is an implementation detail of no great interest. What really

    -It is important to note that processing latency in a jackd is a matter of choice: It can be lowered within the limits imposed only by the hardware and audio driver. But the lower it is, the more likely the system will fail to meet its processing deadline and the dreaded xrun will make its appearance more often, leaving its merry trail of clicks, pops and crackles. +It is important to note that processing latency in a jackd is a matter of choice: It can be lowered within the limits imposed only by the hardware (audio-device, CPU and bus-speed) and audio driver. Lower latencies increase the load on the computer-system because it needs to process the audio in smaller chunks which arrive much more frequently. The lower the latency, the more likely the system will fail to meet its processing deadline and the dreaded xrun (short for buffer over-run and buffer under-run) will make its appearance more often, leaving its merry trail of clicks, pops and crackles.

    @@ -53,19 +53,11 @@ The digital I/O latency is usually negligible for integrated or JACK Audio Connection Kit has a few parameters to configure the latency. However the settings are constrained by hardware (audio-device, CPU and bus-speed). Lower latencies increase the load on the computer-system (it needs to process the audio in smaller chunks which arrive much more frequently). If the system can not keep up: an x-run (short for buffer over-run and buffer under-run) occurs which usually results in audible clicks or dropouts. +Low-latency is not always a feature you want to have. It comes with a couple of drawbacks: the most prominent is increased power-consumption because the CPU needs to process many small chunks of audio-data, it is constantly active and can not enter power-saving mode (think fan-noise). Furthermore, if more than one application (sound-processor) is involved in processing the sound, each of these needs to run for a short time well defined time for each audio-cycle which results in a much higher system-load and an increased chance of x-runs. Reliable low-latency (≤10ms) on GNU/Linux can usually only be achieved by running a realtime-kernel.

    -Low-latency is not always a feature you want to have. It comes with a couple of drawbacks: the most prominent is increased power-consumption because the CPU needs to process many small chunks of audio-data, it is constantly active and can not enter power-saving mode. Furthermore, if more than one application (sound-processor) is involved in processing the sound, the operating system performs a context-switch to run each of these for each audio-cycle which results in a much higher system-load and an increased chance of x-runs. -

    - -

    -Reliable low-latency (≤10ms) on GNU/Linux can usually only be achieved by running a realtime-kernel. -

    - -

    -Yet there are only few situations where a very low-latency is really important, because they require very quick response from the computer. Some examples that come quickly to mind are: +Yet there are only few situations where a low-latency is really important, because they require very quick response from the computer. Some examples that come quickly to mind are:

    -JACK includes an API that allows applications to determine the answers to above questions. However JACK can not know about the additional latency that is introduced by the computer architecture, operating system and soundcard. These values indicated by -I and -O and vary from system to system but are generally constant values. On a general purpose computer system the only way to accurately learn about the total latency is to measure it. +JACK features an API that allows applications to determine the answers to above questions. However JACK can not know about the additional latency that is introduced by the computer architecture, operating system and soundcard. These values are indicated by -I and -O and vary from system to system but are constant on each. On a general purpose computer system the only way to accurately learn about the total (additional) latency is to measure it.

    Calibrating JACK Latency

    -Linux DSP guru Fons Adriaensen wrote a tool called jack_delay to accurately measure the roundtrip latency of a closed loop audio chain, with sub-sample accuracy. JACK itself includes a variant of this called jack_iodelay. +Linux DSP guru Fons Adriaensen wrote a tool called jack_delay to accurately measure the roundtrip latency of a closed loop audio chain, with sub-sample accuracy. JACK itself includes a variant of this tool called jack_iodelay.

    @@ -137,7 +129,7 @@ Jack_iodelay allows you to measure the total latency of the system, subtracts th

    -jack_[io]delay works by emitting some rather annoying tones, capturing them again after a round trip through the whole chain, and measuring the difference in phase so it can estimate with great accuracy the time taken. This is not a theoretical estimation, jack_delay is a measuring tool that will provide very accurate answers. +jack_[io]delay works by emitting some rather annoying tones, capturing them again after a round trip through the whole chain, and measuring the difference in phase so it can estimate with great accuracy the time taken. This is not a theoretical estimation, jack_delay is a measuring tool that provides very accurate answers.

    @@ -145,7 +137,7 @@ You can close the loop in a number of ways:

    @@ -153,9 +145,8 @@ Once you have closed the loop you have to:

    1. Launch jackd with the configuration you want to test.
      2. -
    2. Launch jack_delay.
      3. +
    3. Launch jack_delay on the commandline.
    4. Make the appropriate connections between your jack ports so the loop is closed.
    5. Adjust the playback and capture levels in your mixer.
    - diff --git a/_manual/19_synchronization/03_timecode-generators-and-slaves.html b/_manual/19_synchronization/03_timecode-generators-and-slaves.html index 362ad2d..33a9141 100644 --- a/_manual/19_synchronization/03_timecode-generators-and-slaves.html +++ b/_manual/19_synchronization/03_timecode-generators-and-slaves.html @@ -35,15 +35,22 @@ Combining the timecode slave and generator modes, Ardour can also translate time

    Ardour Timecode Configuration

    -Each Ardour session has a specific timecode frames-per-second setting which is configured in session > properties > timecode. +Each Ardour session has a specific timecode frames-per-second setting which is configured in session > properties > timecode. The selected timecode affects the timecode-ruler in the main window as well as the clock itself.

    +

    +Note that some timecode formats are limited to a subset of Ardour's available fps. e.g. MTC is limited to 24, 25, 29.97 and 30 fps.

    +

    + +

    +The video-pullup modes change the effective samplerate of Ardour to allows for changing a film soundtrack from one frame rate to another. The scope is beyond this manual, but wikipedia's entry on Telecine may get you started. +

    Ardour Timecode Generator Configuration

    This is pretty straight forward: simply turn it on. The MTC and MIDI-Clock generator do not have any options. -For the LTC generator the volume of the generated LTC can be configured. JACK-transport can not be generated jack itself is always sample-sync to the jack-cycle and does not slave to anything. +For the LTC generator the volume of the generated LTC can be configured. JACK-transport can not be generated. Jack itself is always sample-sync to the jack-cycle and does not slave to anything.

    @@ -55,7 +62,7 @@ The timecode is sent to jack-ports ardour:MTC out, ardour:MID

    -Note that -as of writing- only the LTC generator supports latency compensation. This is due to the fact the ardour MIDI ports are not yet latency compensated. +Note that - at the time of writing this - only the LTC generator supports latency compensation. This is due to the fact the ardour MIDI ports are not yet latency compensated.

    @@ -63,6 +70,9 @@ In session > properties it is possible to define an offset betwe

    +

    +Both LTC and MTC are limited to max of 30fps. Using frame-rates larger than that will disable the generator. In both cases also only 24, 25, 29.97df and 30fps are well defined by specifications (such as SMPTE-12M, EU and the MIDI standard). +

    MTC Generator

    @@ -82,6 +92,9 @@ The volume of the LTC signal can be conigured in in the Preferences > T The LTC generator has an additional option to keep sending timecode even when the transport is stopped. This mode is intended to drive analog tape machines which unspool the tape if no LTC timecode is received.

    +

    +LTC is send regardless of Ardour's transport-speed. It is accurately generated even for very slow speeds (<5%) and only limited by the soundcard's sampling-rate and filter (see Gibbs phenomenon) for high speeds. +

    Ardour Slave Configuration

    @@ -114,7 +127,7 @@ In both cases the first option is preferred: clock sync + same FPS setting.

    Frames-per-second

    -If the frames-per-second don't match, ardour can either re-calculate (map) the frames or the configured FPS (session > properties) can be changed automatically while the Slave is active. The behavior is configured with the checkbox in Edit > Preferences > Transport labeled Match session video frame rate to external timecode: When enabled the session video frame rate will be changed to match that of the selected external timecode source. When disabled the session video frame rate will not be changed to match that of the selected external timecode source. Instead the frame rate indication in the main clock will flash red and Ardour will convert between the external timecode standard and the session standard. +If the frames-per-second don't match, ardour can either re-calculate (map) the frames or the configured FPS (session > properties) can be changed automatically while the slave is active. The behavior is configured with the checkbox in Edit > Preferences > Transport labeled Match session video frame rate to external timecode: When enabled the session video frame rate will be changed to match that of the selected external timecode source. When disabled the session video frame rate will not be changed to match that of the selected external timecode source. Instead the frame rate indication in the main clock will flash red and Ardour will convert between the external timecode standard and the session standard.

    @@ -130,7 +143,7 @@ When enabled the external timecode source is assumed to use 29.970000 fps instea

    Clock Sync Lock

    -As described in the introduction, timecode and clock are independent. If the external timecode-source is not sample-sync with the audio-hardware (and jack), ardour needs to vari-speed to adjust for the discrepancy. +As described in the On Clock and Time Section, timecode and clock are independent. If the external timecode-source is not sample-sync with the audio-hardware (and jack), ardour needs to vari-speed to adjust for the discrepancy.

    @@ -206,11 +219,7 @@ Ardour supports vari-speed and backwards playback but will only follow MTC speed

    -While Ardour is chasing MTC, the main transport clock will display the received Timecode as well as the delta between the incoming signal and Ardour's transport position. -

    - -

    -A global offset between incoming timecode and ardour's transport can be configured in Session > Properties. +When Ardour is chasing MTC, the main transport clock will display the received Timecode as well as the delta between the incoming signal and Ardour's transport position.

    diff --git a/_manual/19_synchronization/04_overview-of-timecode-related-settings.html b/_manual/19_synchronization/04_overview-of-timecode-related-settings.html index c9e486a..623cbf0 100644 --- a/_manual/19_synchronization/04_overview-of-timecode-related-settings.html +++ b/_manual/19_synchronization/04_overview-of-timecode-related-settings.html @@ -34,8 +34,12 @@ Timecode related settings are accessed from the menu:
    • External timecode source – select timecode source: JACK, LTC, MTC, MClk
    • Match session video frame rate to external timecode – This option controls the value of the video frame rate while chasing an external timecode source. When enabled the session video frame rate will be changed to match that of the selected external timecode source. When disabled the session video frame rate will not be changed to match that of the selected external timecode source. Instead the frame rate indication in the main clock will flash red and Ardour will convert between the external timecode standard and the session standard.
      • -
    • External timecode is sync locked – When enabled indicates that the selected external timecode source shares sync (Black &amp; Burst, Wordclock, etc) with the audio interface.
      • +
    • External timecode is sync locked – When enabled indicates that the selected external timecode source shares sync (Black & Burst, Wordclock, etc) with the audio interface.
    • Lock to 29.9700 fps instead of 30000/1001 – When enabled the external timecode source is assumed to use 29.97 fps instead of 30000/1001. SMPTE 12M-1999 specifies 29.97df as 30000/1001. The spec further mentions that drop-frame timecode has an accumulated error of -86ms over a 24-hour period. Drop-frame timecode would compensate exactly for a NTSC color frame rate of 30 * 0.9990 (ie 29.970000). That is not the actual rate. However, some vendors use that rate - despite it being against the specs - because the variant of using exactly 29.97 fps has zero timecode drift.
      • +
    • LTC incoming port – offers a session agnostic way to retain the LTC port connection.
      • +
    • Enable LTC generator – does just what it says.
      • +
    • Send LTC while stopped – When enabled Ardour will continue to send LTC information even when the transport (playhead) is not moving. This mode is intended to drive analog tape machines which unspool the tape if no LTC timecode is received.
      • +
    • LTC generator level – Specify the Peak Volume of the generated LTC signal in dbFS. A good value is 0dBu ^= -18dbFS in an EBU calibrated system