On Fri, 21 Jul 2000, [EMAIL PROTECTED] wrote:
> So you mean that the application will get new SMPTE frames with up to
> 10msec jitter because the relatively big fragment size/low frequency.
Yes
> Seems that the solution lies (again) in using small fragmentsizes.
>
> Eg using 128byte fragments (stereo) = 32 samples, you can push the jitter
> down to 700usecs, I think that would be ok ?
I guess so.
> May I ask a stupid question: is in practice a card / piece of hw with SMPTE
> support (input) nothing more than a DAC which reads the analogue signal and
> decodes the timing ?
I can't imagine any other method of doing it. Anyway, it works for me :-)
> (I thought SMPTE used a very complicated and expensive approach to encode the
> timing information :-) )
The main reason why I implemented a software SMPTE decoder was that I found
hw SMPTE decoders so expensive (that's 3 years ago, I don't know if prices
dropped) :-)
Maarten
