Subject: Re: [linux-audio-dev] MIDI sync issues; mmc, mtc, ...
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Dec 21 2000 - 20:24:29 EET
>I have only recently come to understand just how crude the timimg of
>user-space realtime threads is. I'm amazed you folks have been able
>to accomplish so much within those limitations.
We don't work with those limitations, that's how :)
The "timing" of user-space realtime threads is actually amazingly
precise when they are driven by a h/w interrupt. The "resolution" of
the system timer clock, however, is generally very poor. Thats why we
don't use it for anything. That includes thread scheduling for RT
threads. The only thing i use the system clock for in my apps is to
schedule the GUI to do regular updates at about the screen refresh
rate, and its reasonably capable of doing that :)
>For something with a stable, standardized interface like MTC, I tend
>to think in terms of a kernel-mode implementation, perhaps using an
>interrupt handler driven by one of the various realtime clocks
>provided by various sound cards or other system hardware. It seems
>possible to achieve one or two orders of magnitude less jitter that
>way.
Completely wrong. First mistake: you can't do significantly better in
the kernel than in user space with a SCHED_FIFO thread driven by the
audio interface or RTC interrupts. How good is it ? With a fragment
size corresponding to 2.666msec, the audio thread in ardour is woken
up at that interval +/- 0.07msec. That's with
2.4.0-test9+lowish-latency.
Second mistake: MTC is a message stream sent by an audio device of
some kind that describes where it believes it is in time, using
absolute location with a given zero reference. The kernel cannot
possibly do this unless you move the entire application into the
kernel. What happens if the audio app is using varispeed ? The passage
of "MTC time" will occcur at different rates as the playback speed is
adjusted. How can the kernel know this ?
>The ALSA sequencer design fully supports user-space and kernel-mode
>clients attaching to various ports to send and recieve MIDI messages
>using multi-client queues. I'm imagining a relatively simple driver
>that just "keeps the beat", with user-mode clients telling it about
>tempo changes and stuff like that. Maybe someone has already written
>one.
You're not talking about about MTC. MTC does not help you to "keep the
beat". The passage of time visible from MTC data is unaffected by
tempo changes. You're referring to MIDI clock, and I still fail to
understand how the kernel can help with this in an application that
(of necessity) is running an audio thread with SCHED_FIFO scheduling
priority. this thread has better timing than the kernel generally has,
and it also can adjust things at precisely the right time, instead of
dealing with potential queues of pre-determined data that need
flushing, etc.
In general, I don't believe that the ALSA sequencer is useful for
anything but routing (including multiplexing). There is some
excellent work to allow it to use the RTC, and thus escape from its
current typical dependency on the low-resolution system clock. But in
general, it doesn't offer any real benefits for sync transmission or
reception that I can discern, and it adds another layer of code, plus
the dreaded system call, that are the anathema of real time low
latency systems.
>Of course, this approach only works on systems running ALSA. But,
>MIDI support under OSS looks like it's probably too crude for such a
>sophisticated application, anyway. Am I wrong about that?
OSS is a heap of junk in most areas when it comes to sophisticated
applications. It can't support multichannel cards in a h/w independent
way, and the OSS sequencer is just so crude and naive that its more or
less useless for anything except playing back SMF's.
--p
This archive was generated by hypermail 2b28 : Thu Dec 21 2000 - 20:56:54 EET