26 Sep
2009
26 Sep
'09
8:36 a.m.
On Sat, Sep 26, 2009 at 06:28:12AM +0200, Florian Faber wrote:
Fons.
Deriving the word clock from the timecode or video
frequencies, or ensuring both audio and video clocks
derive from the same source, is of course the real
solution to this problem. But it does assume you have
the hardware to do this.
Slaving a sample clock to SMPTE could be done
relatively easily in software provided you can
control the sample clock in software in small
steps. It doesn't even require decoding the SMPTE,
just extracting the bit clock is enough. This is
why I asked you about this feature in the RME
drivers some time ago.
Ciao,
--
FA
Io lo dico sempre: l'Italia รจ troppo stretta e lunga.
Not really. Suppose you have to do this:
1. copy an audio track from a video recording,
2. do some work on it,
3. copy the result back to the video recording.
Your (nominal) sample rate is 48k, the video is
exactly 100s long when played at the exact frame
rate.
If the the clock used by the video equipment and your
sample clock are not coherent (not derived from the
same source), there will be a relative error between
them, both in steps 1 and 3.
If the source is analogue video (and analogue audio), you derive your
word clock from the VBI/video lines or SMPTE, if you have this information.
If the source is digital, well, there is no problem, since you work on a
fixed number of samples.
So please tell me how this can ever happen in real life?