Subject: Re: [linux-audio-dev] rtlinux, MIDI timecode
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri May 05 2000 - 03:01:14 EEST
On Fri, 05 May 2000, Paul Barton-Davis wrote:
> >set up the RTC timer to 2Khz
> >( 500usec precision).
> >
> >with this algorithm even if you lose a tick evey now and then,
> >you will still have all MTC messages delivered with millisecond precision
> >
> >actual_time=get actual time
> >next_mtc_time = actual_time += 8.3ms
> >while(1) {
> > read() from RTC device ( blocks our process for 500usec)
> > actual_time=get actual time using TSC or gettimeofday()
> > if(actual_time >= next_mtc_time) {
> > send_the_2_MTC_bytes();
> > next_mct_time += 8.3ms
> > }
> >}
>
> >let me know what you think about the code above.
>
> I'm going to try this after I try the even simpler (and less
> IRQ-loading) approach of sending all the MTC data immediately after
> sending a new fragment to the audio interface. This implies jitter of
> the same as the fragment size/time, but I want to see if this is
> accepted by the MTC receiver.
As long the jitter is tolerated, I would prefer this method over the RTC
one too.
>
> <If that doesn't work, then I'll go for something like your example above.
> >If you have to sync the SMPTE for every frame/two frames, just modify my code
> >above in order to check the differences between SMPTE time and
> >next_mtc_time, and if they differ override it with the right time.
> >Assuming that the floating point "next_mtc_time" variable increments in
> >1/30 steps , the drift will be very very small compared to the real SMPTE time
> >,
> >and that means as soon a drift of 500usecs is detected, the next MTC message
> >is delivered 500usecs later or sooner.
> >
> >Or am I missing something ?
>
> Well, not much, just a little bit. The MTC receiver expects to see
> *every* quarter frame message. Its not OK to skip a few, because then
> it concludes that the MTC transmitter is broken. So whenever you find
> that the current SMPTE time is ahead of the last-sent MTC, you have to
> send all the qtr frame messages needed to catch up, not just those
> representing the current time.
You are right (I had this in mind but was too lazy to write some pseudo-code),
the if statement should look as follows:
if(actual_time >= next_mtc_time) {
send_all_pending_MTC_frames(); (use either a timestamp or just check the
actual time - previous time, in order to figure out how many MTC frames you
have to send)
next_mct_time += 8.3ms
}
Anyway UTIME would be just nice in this case, since we can even adapt the
interval (with usec resolution) to the changed conditions,
that means very light IRQ load.
Benno.
This archive was generated by hypermail 2b28 : Fri May 05 2000 - 03:45:58 EEST