Re: [linux-audio-dev] MIDI sync issues; mmc, mtc, ...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] MIDI sync issues; mmc, mtc, ...
From: Jack O'Quin (joq_AT_io.com)
Date: Thu Dec 21 2000 - 22:11:22 EET


Paul Barton-Davis <pbd_AT_Op.Net> writes:

> 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.

That's interesting, much better than I thought. Thanks for setting me
straight. :-)

Of course, for some applications, a jitter of +/- 2.6% might not be
considered terribly good. How often do you see that range of
variation, is it a two-sigma case?

> 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 ?

Well, the idea was to tell the driver whatever kind of beats per
minute, pulses per quarter note, and song position information it
needs to generate this stream. When the tempo changes, some
application would need to send it a message. I was assuming this
would be relatively rare.

I was also assuming that the application might choose to receive its
own timing by subscribing to this MIDI port, almost as if these pulses
came from an external source. Of course, some applications might find
that extremely inconvenient.

> 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.

That makes sense. Sorry about goofing up the MTC and MIDI clock
terminology. Good terminology is important for discussing anything
coherently. :-)

I had a somewhat simpler application than Ardour in mind. But,
perhaps those folks would just use the built-in timing of
/dev/sequencer and its ilk.

> >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.

That was certainly my impression. A few years ago I experimented with
recording MIDI keyboard input. Back then, the only application I
could get working included it's own MIDI driver (yuk!).

Thanks for taking the time to educate me, Paul.

-- 
  Jack O'Quin
  Austin, Texas, USA


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Dec 21 2000 - 23:48:07 EET