]> Shamusworld >> Repos - ardour-manual/commitdiff
tweaks to the sync-chapter.
authorRobin Gareus <robin@gareus.org>
Fri, 15 Feb 2013 20:49:33 +0000 (21:49 +0100)
committerRobin Gareus <robin@gareus.org>
Fri, 15 Feb 2013 20:49:33 +0000 (21:49 +0100)
_manual/19_synchronization/02_latency-and-latency-compensation.html
_manual/19_synchronization/03_timecode-generators-and-slaves.html
_manual/19_synchronization/04_overview-of-timecode-related-settings.html

index a091806f0eab964e06e388f2fed8f4926eba0cc7..a014d4336148b0a3dcab0ae012bf901df8a23cb6 100644 (file)
@@ -1,6 +1,7 @@
 ---
 layout: default
 title: Latency and Latency-Compensation
+menu_title: About Latency
 ---
 
 <h2>Latency</h2>
@@ -22,8 +23,8 @@ 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 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&#039;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="Figure 1: Latency chain" alt="Figure 1: Latency chain" /></a></p>
-<p>Figure 1: 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.</p>
+<p><img src="/ardour/manual/html/diagrams/latency-chain.png"  title="Latency chain" alt="Latency chain" /></a></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>
 There is not much that can done about the first two other than using headphones or sitting near the loudspeaker and buying quality gear.
@@ -109,11 +110,11 @@ To achieve sample accurate timecode synchronization, the latency introduced by t
 In order to compensate for Latency, JACK or JACK applications need to know exactly how long a certain signal needs to be read-ahead or delayed:
 </p>
 
-<p><img src="/ardour/manual/html/diagrams/jack-latency-excerpt.png"  title="Figure 2: Jack Latency Compensation" alt="Figure 2: Jack Latency Compensation" /></p>
-<p>Figure 2: Jack Latency Compensation. This figure outlines the jack latency API. -- excerpt from http://jackaudio.org/files/jack-latency.png</p>
+<p><img src="/ardour/manual/html/diagrams/jack-latency-excerpt.png"  title="Jack Latency Compensation" alt="Jack Latency Compensation" /></p>
+<p><em>Figure: Jack Latency Compensation.</em>  This figure outlines the jack latency API. -- excerpt from http://jackaudio.org/files/jack-latency.png</p>
 
 <p>
-In Figure 2, clients A and B need to be able to answer the following two questions:
+In above figure, clients A and B need to be able to answer the following two questions:
 </p>
 <ul>
 <li>how long has it been since te data read from port Ai or Bi arrived at the edge of the JACK graph (capture)?</li>
@@ -121,7 +122,7 @@ In Figure 2, clients A and B need to be able to answer the following two questio
 </ul>
 
 <p>
-JACK includes 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 indicated by <code>-I</code> and <code>-O</code> in Figure 2 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 includes 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 indicated by <code>-I</code> and <code>-O</code> 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.
 </p>
 
 
index dba6f799cf112b32b5093012cae0e0a965ce25e5..c2cdbe2be8d013f5d41d7770600d58fecc2fe4f9 100644 (file)
@@ -51,7 +51,7 @@ The relevant settings for timecode generator can be found in the Preferences dia
 </p>
 
 <p>
-The timecode is sent to jack-ports <strong><code>ardour:MTC out</code></strong>, <strong><code>ardour:MIDI clock out</code></strong> and <strong><code>ardour:LTC-out</code></strong>. Multiple generators can be active simultaneously.
+The timecode is sent to jack-ports <code>ardour:MTC out</code>, <code>ardour:MIDI clock out</code> and <code>ardour:LTC-out</code>. Multiple generators can be active simultaneously.
 </p>
 
 <p>
@@ -114,7 +114,7 @@ In both cases the first option is preferred: clock sync + same FPS setting.
 <h3>Frames-per-second</h3>
 
 <p>
-If the frames-per-second don&#039;t match, ardour can either re-calculate (map) the frames or the configured FPS (<code>session &gt; properties</code>) can be changed automatically while the Slave is active. The behavior is configured with the checkbox in <code>Edit &gt; Preferences &gt; Transport</code> labeled <code>Match session video frame rate to external timecode</code>: <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.
+If the frames-per-second don&#039;t match, ardour can either re-calculate (map) the frames or the configured FPS (<code>session &gt; properties</code>) can be changed automatically while the Slave is active. The behavior is configured with the checkbox in <code>Edit &gt; Preferences &gt; Transport</code> labeled <code>Match session video frame rate to external timecode</code>: 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.
 </p>
 
 <p>
@@ -122,19 +122,19 @@ An edge case can also occur with 29.97 drop-frame timecode. While the SMPTE 12M-
 </p>
 
 <p>
-<strong>When enabled</strong> 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 <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.
 </p>
 
 
 
-<h3>Clock sync lock</h3>
+<h3>Clock Sync Lock</h3>
 
 <p>
 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.
 </p>
 
 <p>
-The checkbox <code>External timecode is sync locked</code> allows to select the behavior according to your setup. <strong>When enabled</strong> indicates that the selected external timecode source shares sync (Black &amp; Burst, Wordclock, etc) with the audio interface.
+The checkbox <code>External timecode is sync locked</code> allows to select the behavior according to your setup. When enabled indicates that the selected external timecode source shares sync (Black &amp; Burst, Wordclock, etc) with the audio interface.
 </p>
 
 <p>
@@ -154,7 +154,7 @@ MIDI Clock is not a timecode format but tempo-based time. The absolute reference
 </p>
 
 <p>
-Note that the MIDI Clock source must be connected to <strong><code>ardour:MIDI clock in</code></strong> port.
+Note that the MIDI Clock source must be connected to <code>ardour:MIDI clock in</code> port.
 </p>
 
 
@@ -166,15 +166,15 @@ The LTC slave decodes an incoming LTC signal on a jack-audio port. It will auto-
 </p>
 
 <p>
-The incoming timecode signal needs to arrive at the <strong><code>ardour:LTC-in</code></strong> port. Port-connections are restored for each session and the preference dialog offers an option to select it for all sessions.
+The incoming timecode signal needs to arrive at the <code>ardour:LTC-in</code> port. Port-connections are restored for each session and the preference dialog offers an option to select it for all sessions.
 </p>
 
 <p>
 Ardour&#039;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.
 </p>
 
-<p><img src="/ardour/manual/html/diagrams/ltc-transport-alignment.png"  title="Figure 3: LTC frame alignment" alt="Figure 3: LTC frame alignment"/></p>
-<p>Figure 3: LTC frame alignment for the 525/60 TV standard</p>
+<p><img src="/ardour/manual/html/diagrams/ltc-transport-alignment.png"  title="LTC frame alignment" alt="LTC frame alignment"/></p>
+<p><em>Figure: LTC frame alignment for the 525/60 TV standard</em></p>
 
 
 <p>
@@ -198,7 +198,7 @@ The user-bits in the received LTC frame are ignored.
 <h3>MTC - MIDI Timecode</h3>
 
 <p>
-Ardour&#039;s MTC slave parses full timecode (sysex messages) as well as MTC quarter-frames arriving on the <strong><code>ardour:MTC in</code></strong> port. The transport will only start rolling once a complete sequence of 8 quarter frames has been received.
+Ardour&#039;s MTC slave parses full timecode (sysex messages) as well as MTC quarter-frames arriving on the <code>ardour:MTC in</code> port. The transport will only start rolling once a complete sequence of 8 quarter frames has been received.
 </p>
 
 <p>
index 03096979b7beec9361d573366fa378ded94f52f6..c9e486a0ef955e9d180aaa394ccfda463abddff1 100644 (file)
@@ -1,52 +1,48 @@
 ---
 layout: default
 title: Overview of all Timecode related settings
+menu_title: Overview of Timecode settings
 ---
 
-<h2>Overview of all Timecode related settings</h2>
+<h2>Accessing the Settings and Preferences</h2>
 
 <p>
-Timecode related settings are accessed from the menus
+Timecode related settings are accessed from the menu:
 </p>
 
-<p>
-<code>Session &gt; Properties &gt; Timecode</code>
-</p>
-
-<p>
-<code>Edit &gt; Preferences &gt; Transport</code>
-</p>
-
-<p>
-<code>Edit &gt; Preferences &gt; MIDI</code>
-</p>
+<ul>
+       <li><code>Session &gt; Properties &gt; Timecode</code></li>
+  <li><code>Edit &gt; Preferences &gt; Transport</code></li>
+  <li><code>Edit &gt; Preferences &gt; MIDI</code></li>
+</ul>
 
 
 
-<h3>Timecode Settings</h3>
+<h2>Timecode Settings</h2>
+<p>Thes settings are session specific:</p>
 <ul>
-<li>"<strong>Timecode frames-per-second</strong>" – configure Timecode frames-per-second (23.976, 24, 24.975, 25, 29.97, 29.97 drop, 30, 30 drop, 59.94, 60). Note that all fractional framerates are actually fps*(1000.0/1001.0).</li>
-<li>"<strong>Pull up/down</strong>" – video-pullup modes change the effective samplerate of Ardour to allows for changing a film soundtrack from one frame rate to another. see <a href="http://en.wikipedia.org/wiki/Telecine" title="http://en.wikipedia.org/wiki/Telecine">Telecine</a></li>
-<li>"<strong>Slave Timecode offset</strong>" – The specified offset is added to the received timecode (MTC or LTC).</li>
-<li>"<strong>Timecode Generator offset</strong>" – Specify an offset which is added to the generated timecode (so far only LTC).</li>
-<li>"<strong>JACK Time Master</strong>" – provide Bar|Beat|Tick and other information to JACK</li>
+<li><strong>Timecode frames-per-second</strong> – configure Timecode frames-per-second (23.976, 24, 24.975, 25, 29.97, 29.97 drop, 30, 30 drop, 59.94, 60). Note that all fractional framerates are actually fps*(1000.0/1001.0).</li>
+<li><strong>Pull up/down</strong> – video-pullup modes change the effective samplerate of Ardour to allows for changing a film soundtrack from one frame rate to another. see <a href="http://en.wikipedia.org/wiki/Telecine" title="http://en.wikipedia.org/wiki/Telecine">Telecine</a></li>
+<li><strong>Slave Timecode offset</strong> – The specified offset is added to the received timecode (MTC or LTC).</li>
+<li><strong>Timecode Generator offset</strong> – Specify an offset which is added to the generated timecode (so far only LTC).</li>
+<li><strong>JACK Time Master</strong> – provide Bar|Beat|Tick and other information to JACK</li>
 </ul>
 
 
 
-<h3>Transport Preferences</h3>
+<h2>Transport Preferences</h2>
 <ul>
-<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 &amp;amp; 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>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 &amp;amp; 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>
 </ul>
 
 
 
-<h3>MIDI Preferences</h3>
+<h2>MIDI Preferences</h2>
 <ul>
-<li>"<strong>Send MIDI Timecode</strong>" – enable MTC generator</li>
-<li>"<strong>Send MIDI Clock</strong>" – enable MIDI Clock generator</li>
+<li><strong>Send MIDI Timecode</strong> – enable MTC generator</li>
+<li><strong>Send MIDI Clock</strong> – enable MIDI Clock generator</li>
 </ul>