fix HTML
This commit is contained in:
parent
27ff2f09a1
commit
876124925e
|
|
@ -23,7 +23,7 @@ In order to achieve exact time synchronization all sources of latency need to be
|
|||
<li><strong>Computer I/O Architecture</strong>: 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.</li>
|
||||
</ul>
|
||||
|
||||
<p><img src="/ardour/manual/html/diagrams/latency-chain.png" title="Latency chain" alt="Latency chain" /></a></p>
|
||||
<p><img src="/ardour/manual/html/diagrams/latency-chain.png" title="Latency chain" alt="Latency chain" /></p>
|
||||
<p><em>Figure: Latency chain.</em> 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.</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -49,7 +49,7 @@ It is important to note that <strong>processing latency in a jackd is a matter o
|
|||
</p>
|
||||
|
||||
<p>
|
||||
The digital I/O latency is usually negligible for integrated or <acronym title="Periphal Component Interface">PCI</acronym> 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 <abbr title="Periphal Component Interface">PCI</abbr> audio devices but for USB or FireWire interfaces the bus clocking and buffering can add some milliseconds.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -114,7 +114,7 @@ In above figure, clients A and B need to be able to answer the following two que
|
|||
</ul>
|
||||
|
||||
<p>
|
||||
JACK features an <acronym title="Application Programming Interface">API</acronym> 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 <code>-I</code> and <code>-O</code> 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 <abbr title="Application Programming Interface">API</abbr> 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 <code>-I</code> and <code>-O</code> 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.
|
||||
</p>
|
||||
|
||||
|
||||
|
|
@ -137,7 +137,7 @@ You can close the loop in a number of ways:
|
|||
</p>
|
||||
<ul>
|
||||
<li>Putting a speaker close to a microphone. This is rarely done, as air propagation latency is well known so there is no need to measure it.</li>
|
||||
<li>Connecting the output of your audio interface to its input using a patch cable. This can be an analog or a digital loop, depending on the nature of the input/output you use. A digital loop won't factor in the <acronym title="Analog to Digital, Digital to Analog">AD/DA</acronym> converter latency.</li>
|
||||
<li>Connecting the output of your audio interface to its input using a patch cable. This can be an analog or a digital loop, depending on the nature of the input/output you use. A digital loop won't factor in the <abbr title="Analog to Digital, Digital to Analog">AD/DA</abbr> converter latency.</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ Each Ardour session has a specific timecode frames-per-second setting which is c
|
|||
</p>
|
||||
|
||||
<p>
|
||||
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.</p>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -135,7 +135,7 @@ An edge case can also occur with 29.97 drop-frame timecode. While the SMPTE 12M-
|
|||
</p>
|
||||
|
||||
<p>
|
||||
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 <acronym title="specification">spec</acronym> 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 <abbr title="specification">spec</abbr> 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.
|
||||
</p>
|
||||
|
||||
|
||||
|
|
@ -183,7 +183,7 @@ The incoming timecode signal needs to arrive at the <code>ardour:LTC-in</code> p
|
|||
</p>
|
||||
|
||||
<p>
|
||||
Ardour's transport is aligned to LTC-frame start/end positions according to the SMPTE 12M-1999 <acronym title="specification">spec</acronym> 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 <abbr title="specification">spec</abbr> 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.
|
||||
</p>
|
||||
|
||||
<p><img src="/ardour/manual/html/diagrams/ltc-transport-alignment.png" title="LTC frame alignment" alt="LTC frame alignment"/></p>
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Timecode related settings are accessed from the menu:
|
|||
<li><strong>External timecode source</strong> – select timecode source: JACK, LTC, MTC, MClk</li>
|
||||
<li><strong>Match session video frame rate to external timecode</strong> – This option controls the value of the video frame rate <em>while chasing</em> an external timecode source. <strong>When enabled</strong> the session video frame rate will be changed to match that of the selected external timecode source. <strong>When disabled</strong> 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.</li>
|
||||
<li><strong>External timecode is sync locked</strong> – <strong>When enabled</strong> indicates that the selected external timecode source shares sync (Black & Burst, Wordclock, etc) with the audio interface.</li>
|
||||
<li><strong>Lock to 29.9700 fps instead of 30000/1001</strong> – <strong>When enabled</strong> 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 <acronym title="specification">spec</acronym> 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.</li>
|
||||
<li><strong>Lock to 29.9700 fps instead of 30000/1001</strong> – <strong>When enabled</strong> 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 <abbr title="specification">spec</abbr> 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.</li>
|
||||
<li><strong>LTC incoming port</strong> – offers a session agnostic way to retain the LTC port connection.</li>
|
||||
<li><strong>Enable LTC generator</strong> – does just what it says.</li>
|
||||
<li><strong>Send LTC while stopped</strong> – <b>When enabled</b> 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.</li>
|
||||
|
|
|
|||
Loading…
Reference in New Issue