Subject: Re: [linux-audio-dev] rtlinux, MIDI timecode
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu May 04 2000 - 21:12:50 EEST
>Some options that you have probably rejected, but I'm curious to hear why:
>
>Is any `smart' MIDI interface supported? If not, writing an MPU-401
>driver might be more fun than porting to RTLinux.
How would this help ? There is no SMPTE signal, there is just on-disk
sound with computed time in the HDR program. The smart MIDI interfaces
can't do anything with this situation.
The only possible help an external MIDI box might offer is to buffer
timecode messages until they should be sent, but thats prone to errors
as well - can you easily flush pending messages when the "tape
transport" stops, etc ?
>Since you have to run with Ingo's patch, what's one more? Use UTIME,
I don't run with Ingo's patch, I use 2.3.99pre6. kswapd kills me right
now, but Rik&Andrea should hopefully get this fixed in the next few days.
>with their Posix.4 interval timers if you like. If you're feeling
>political, find out why UTIME isn't in the kernel and get it there. :-)
True, this would be nice.
>How much jitter can a SMPTE receiver in general, and your mixer in
^^^^^
MTC
>particular, tolerate? (If you are even considering non-RTLinux,
>presumably an occasional couple of milliseconds is okay.)
This is a question that I can't answer right now. I have no access to
anyone at (in my case) Mackie to find out what level of jitter they
tolerate, and I don't have a test program setup to try different
levels. There has to be some room for this, because a MIDI wire is
liable to the same kind of collisions as an ethernet. Since a NoteOn
would consume 3 * 320usec (close to 1msec), they must tolerate a
certain amount.
However, this is still not the heart of the problem. The problem is
getting the user-space application to queue up the MTC quarter frame
messages so that each set of 4 represents just a single SMPTE frame
advance. That is: the user space app has to queue 4 2 byte messages
for every SMPTE fps-count. If it doesn't do this, the MTC receiver
will conclude (correctly) that there is an error-prone MTC
transmitter.
Assume we are using SMPTE 30 fps. Thus, every 33msec, we need to queue
up 4 bytes. If we miss, ah.... now here's an interesting
question. Suppose the MTC transmitter, my program, does this:
while (1) {
... arrange to sleep for about 33msec ...
... get current SMPTE time ...
... write enough qtr frame messages to catch up ...
}
its likely that whatever arrangement I make to sleep for 33msec will
not be very accurate, but if we then send any missing MTC qtr frame
messages, the receiver will just see jitter, rather than missing
messages. I wonder if this will satisfy most receivers ?
this differs from what i was trying to do:
while (1) {
... arrange to sleep for 33msec ...
... get current SMPTE time ...
... send corresponding qtr frame message(s) ...
}
the difference is both subtle and obvious at the same time.
And how
>expensive is it to take an RTC interrupt? If it's not too painful to
>run at 8kHz (and if it is, something's wrong), rounding to the nearest
>RTC gives a jitter of +/- 0.5/8192 sec, only two MIDI bits.
True. The problem is, the RTC gets unreliable above about 4kHz,
because it will stop generating interrupts if we ever fail to ack one.
The load at 8kHz is not too bad, but the unreliability is.
David Woodhouse suggested switching the system's use of the RTC and
the 8253 timer, since the latter is basically infinitely
programmable. There are comments along these lines in the kernel
source too, so this seems like quite a nice idea. I will be looking
into it some more.
However, first, I will the scheme above. Then I will try a 1024Hz
interrupt frequency (every 1msec) from the RTC, and see if the
(relatively large) jitter inherent in this confuses the MTC receiver
in question.
--p
This archive was generated by hypermail 2b28 : Thu May 04 2000 - 21:41:38 EEST