On Fri, 21 Jul 2000, Maarten de Boer wrote:
> >
> > I don't think you necessarily mean jitter, do you ? More like latency?
> > Unless you're referring to times when the SMPTE signal crosses the
> > fragment (interrupt) boundaries ?
>
> Yes, that is exactly what I am refering to. Theoratically, when the SMPTE
> would have a constant speed, the fragment size could be set to always
> contain exactly one SMPTE frame. But SMPTE speed is not fixed, and also
> not all sound cards allow sample-accurate setting of the fragment size.
>
> Imagine we use a fragment size of 256, at 22050 Hz (which I found sufficient
> to recognize the SMPTE), we can be 0.012 sec off. At 30 SMPTE frame/sec, this
> is more than a third of the SMPTE frame duration.
>
> Maarten
So you mean that the application will get new SMPTE frames with up to
10msec jitter because the relatively big fragment size/low frequency.
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 ?
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 thought SMPTE used a very complicated and expensive approach to encode the
timing information :-) )
Anyway this SMPTE jitter issue is one more reason to run all apps in sync
(with the rtsoundserver/plugin model) using small framesizes in order of 32-128
samples.
All jitters below 1-2msec (audio, MIDI , SMPTE, timers etc) and no more
disappointed power-users.
:-)
Benno.
