[linux-audio-dev] smpte generating code

Paul Davis paul at linuxaudiosystems.com
Wed Dec 4 14:45:01 UTC 2002


>by the way, i quote from one of the messages:
>
>> i wish to god that SMPTE had never taken off. its the most ridiculous
>> thing since, errr, oh, something like APL. more precisely, its fine
>> for video timing, but its *insane* that its become accepted for audio
>> timing.
>
>written by paul david :-) . changed your mind, paul? ;-)

not at all :)

the problem is that MTC is almost impossible for us to generate in 
a way that other devices will lock to. i say "almost impossible"
because i believe that the "firm timers" work in 2.5/2.6 will probably
fix this. its hard because although other devices see the MTC that
(say) ardour emits, but they note that it doesn't arrive at regular
1-video-frame intervals. instead, its "bursty", following some clock
other than the steady passage of SMPTE time (the clock might be the
audio interrupt, or the RTC, etc.).

my thought was that i could avoid this by actually emitting SMPTE
itself, which is an audio stream, and thus can be generated with
perfect sample accuracy as we go. this can then allow people with
equipment that can read a SMPTE signal and/or convert it to MTC to get
their devices to lock to Ardour's timecode, rather than respond to it.

this is important because some devices will not handle or emit
requests to record correctly when they can't lock to timecode.

i still think that using SMTPE as the standard for audio timing is
absurd. 

--p




More information about the Linux-audio-dev mailing list