From 876124925eb2b43064a58dcc118e685ac876514c Mon Sep 17 00:00:00 2001 From: Robin Gareus Date: Sat, 16 Feb 2013 00:55:21 +0100 Subject: [PATCH] fix HTML --- .../02_latency-and-latency-compensation.html | 8 ++++---- .../03_timecode-generators-and-slaves.html | 6 +++--- .../04_overview-of-timecode-related-settings.html | 2 +- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/_manual/19_synchronization/02_latency-and-latency-compensation.html b/_manual/19_synchronization/02_latency-and-latency-compensation.html index deccb31..2ce0498 100644 --- a/_manual/19_synchronization/02_latency-and-latency-compensation.html +++ b/_manual/19_synchronization/02_latency-and-latency-compensation.html @@ -23,7 +23,7 @@ In order to achieve exact time synchronization all sources of latency need to be
  • 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

    +

    Latency chain

    Figure: Latency chain. The numbers are an example for a typical PC. With professional gear and an optimized system the total roundtrip latency is usually lower. The important point is that latency is always additive and a sum of many independent factors.

    @@ -49,7 +49,7 @@ It is important to note that processing latency in a jackd is a matter o

    -The digital I/O latency is usually negligible for integrated or PCI audio devices but for USB or FireWire interfaces the bus clocking and buffering can add some milliseconds. +The digital I/O latency is usually negligible for integrated or PCI audio devices but for USB or FireWire interfaces the bus clocking and buffering can add some milliseconds.

    @@ -114,7 +114,7 @@ In above figure, clients A and B need to be able to answer the following two que

    -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. +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.

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

    diff --git a/_manual/19_synchronization/03_timecode-generators-and-slaves.html b/_manual/19_synchronization/03_timecode-generators-and-slaves.html index 33a9141..08f0bb2 100644 --- a/_manual/19_synchronization/03_timecode-generators-and-slaves.html +++ b/_manual/19_synchronization/03_timecode-generators-and-slaves.html @@ -39,7 +39,7 @@ Each Ardour session has a specific timecode frames-per-second setting which is c

    -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.

    +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.

    @@ -135,7 +135,7 @@ An edge case can also occur with 29.97 drop-frame timecode. While the SMPTE 12M-

    -When enabled the external timecode source is assumed to use 29.970000 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 yields zero timecode drift. +When enabled the external timecode source is assumed to use 29.970000 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 yields zero timecode drift.

    @@ -183,7 +183,7 @@ The incoming timecode signal needs to arrive at the ardour:LTC-in p

    -Ardour's transport is aligned to LTC-frame start/end positions according to the SMPTE 12M-1999 spec which means that the first bit of an LTC-Frame is aligned to different Lines of a Video-Frame, depending on the TV standard used. Only for Film (24fps) does the LTC-Frame directly match the video Frame boundaries. +Ardour's transport is aligned to LTC-frame start/end positions according to the SMPTE 12M-1999 spec which means that the first bit of an LTC-Frame is aligned to different Lines of a Video-Frame, depending on the TV standard used. Only for Film (24fps) does the LTC-Frame directly match the video Frame boundaries.

    LTC frame alignment

    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 623cbf0..b50a768 100644 --- a/_manual/19_synchronization/04_overview-of-timecode-related-settings.html +++ b/_manual/19_synchronization/04_overview-of-timecode-related-settings.html @@ -35,7 +35,7 @@ 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 & 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.
    • +
  • 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.
    • -- 2.37.2