Subject: Re: [linux-audio-dev] rtlinux, MIDI timecode
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri May 05 2000 - 01:32:31 EEST
my thoughts:
MTC = 2 bytes every 8.3ms ?
not a big deal IMHO:
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.
> >
> >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 ?
I agree here: we don't want queues when dealing with realtime data
which must be delivered as soon as possible
>
> >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.
Yes, I fully agree: WE STRONGLY need UTIME for demanding multimedia apps.
How about about to write a polite mail to Linus and friends, (representing the
linux audio community) about the need of UTIME and the low-latency patches
in standard kernels ? without these features Linux is not a viable solution for
professional apps.
( UTIME is already here , 2.2.x lowlatency is basically finished, it needs only
a bit SMP tweaking and we are done,
(Linus rejected Ingo's 2.3.x preemptive kernels because he made it too
preemptive and slowed down the spinlocks etc, but anyway
his old low-latency approach has proved to perform really good, as long
as your SCHED_FIFO thread do not call any non-deterministic functions,
therefore anyone will be happy with that kind of performance, especially
considering the fact that running large plugin chains at latencies <2ms
will burn almost all CPU power while doing function calling parameter
passing and cache trashing :-) )
>
> 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.
Then my code above would work just nicely:
in my lowlatency tests I demonstrated that the max jitter was around
500usecs ,and that VERY sporadic. Therefore the MTC sending
will be rock solid when run on a low latency kernel.
>
> 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.
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 ?
Anyway don't trust RTC by counting the number of ticks:
use it as a method to sleep with good granularity, and then
use TSC or gettimeofday() as a precise timing source, and
act accordingly if a tick is missed.
Benno.
This archive was generated by hypermail 2b28 : Fri May 05 2000 - 02:25:45 EEST