Subject: Re: [linux-audio-dev] introduction & ideas
From: David Olofson (david_AT_gardena.net)
Date: Wed Mar 06 2002 - 06:40:08 EET
On Tuesday 05 March 2002 23.28, Martijn Sipkema wrote:
> > Ok, I was of course thinking of timestamping MIDI events with the
> > "audio clock". No problem when running a sequencer as a part of
> > the audio network, but it does get messy to timestamp the MIDI
> > events.
>
> I would prefer timestamping MIDI messages with some common clock.
> Then the audio system can return the actual transmission time for a
> buffer in this clock and MIDI and audio can be synced.
Yes, but as Paul has been trying to explain for a while, that's not
the problem. The problem is that the stoopid MIDI interfaces won't be
of much help when it's time to actually *use* those timestamps during
playback.
One solution would be that we get something (a hardware IRQ) to wake
us up at the right moment, so we can send some MIDI data, then check
when the next chunk is to be played, and go to sleep until then.
Another solution is doing it the audio way; just get (build...) a
MIDI interface that pumps a constant rate stream of bits or bytes.
Then, write data corresponding N "raw" bits at a time, where 31250/N
makes a sensible "buffer rate" for your MIDI playback thread. The
thread will block on writes, and provided you know how much total
buffering there is between you and the physical MIDI output, you will
know *exactly* (*) when each MIDI byte will be sent.
If we have enough buffering to cover the worst case scheduling
latency, there will be no timing jitter whatsoever on the MIDI output.
[...]
> I don't think an arbitrarily long sysex messages should be
> guaranteed to be delivered atomically. This is very hard to do and
> still be real time, i.e.
> don't use malloc.
*Exactly*.
> A preallocated memory pool could be used, but you
> will eventually run into a sysex message too large.
Unless the memory management system includes "chained blocks" - but
that would be a royal PITA for applications...
> Besides, I
> don't really see a problem with receiving the sysex message in
> chunks not larger than some maximum size.
Nor do I - an application will see it in that form at some point
anyway, unless it (or the MIDI API it's using) is violating
fundamental real time programming rules already in the raw MIDI input
code...
> > > and again, we can easily timestamp MIDI data on the way in -
> > > after all, its clocked by an "external" source. the problem is
> > > delivering it on time on the way out.
> >
> > Yeah... It's actually quite amazing that even "high end" MIDI
> > interfaces are as stupid as they are...! *heh*
>
> Even with the stupid interfaces timing should be quite good on a
> realtime operating system.
Well, yes, *if* you have a way of finding out exactly how many bytes
are in the output FIFO at any time. If you can't, and your output
thread isn't "hardsync'ed" to the MIDI clock, you'll have to accept
that you can only get accurate timing when the FIFO is empty as you
start writing. As the FIFO fills up, your idea of the "current MIDI
output latency" will gradually drift away from the actual figure.
Now, you *could* probably abuse a relatively decent MIDI interface by
padding with some harmless MIDI byte - but this buys us nothing
unless we know 1) that the MIDI interface will wake sleepers
up*immediately* when there is room in the output FIFO, and 2) the
size of the FIFO.
The sad reality is that many cards don't even have an IRQ for 1), and
that 2) can't be found out by asking the driver.
> > Wonder if your average MIDI interface would handle the 0xfe abuse
> > hack I suggested above... (Well, at least I know most
> > SoundBlaster cards won't handle it!)
>
> I don't really see an advantage to this approach. It might work for
> creating a clock, but it wouldn't work on multiport interfaces
> where the accurate timing is most needed.
Multiport interfaces *need* special features to manage timing, unless
they're on something that's many times faster than MIDI. Nothing much
to do about that.
> I don't think timing
> actually gets any better with this
> approach,
No, there's no point with it, provided you're using an RTL or RTAI
MIDI output driver.
If you aren't, you *will* need some form of buffering/queueing to
keep scheduling jitter from leaking into the MIDI stream.
Not that a good Linux/lowlatency build causes all that much jitter,
but it's still more than you'd get from any dedicated, professional
MIDI device, such as a hardware sequencer. *That's* what this is all
about, as I understand it; achieving dedicated h/w performance on
workstation based hardware.
We've already proved that this is possible with audio. Now, it turns
out that MIDI is actually *harder*, at least if we want to achieve
*true* dedicated h/w accuracy... *heh*
> and I'm still not even sure the serial port hardware can
> only start
> a byte every 320 microseconds.
At least, most UARTs can "trigger" their inputs at least at three
different positions per bit period, but I'm not sure about the
outputs. I do have a feeling that bit period accuracy is actually
rather common, though - if nothing else, because the internal state
machine of the UART actually gets *simpler* that way... (The "idle"
state can simply loop until there's data in the FIFO, rather than
keeping track of some "bit count" - which would vary with
start/data/stop bit counts, as well!)
> IMHO a MIDI driver should be a (real time) user space process able
> to accurately transmit MIDI events on the hardware from
> CLOCK_MONOTONIC or something similar.
Well, that's fine if
1) there's a h/w timer to wake the thread up at the
right times, and
2) it's OK that the scheduling jitter is visible on
the MIDI outputs.
Without "buffering" MIDI interfaces, a workstation is not going to
deliver the same timing accuracy as say, a h/w sequencer - not
without a hard real time kernel like RTL or RTAI.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'
This archive was generated by hypermail 2b28 : Sat Mar 09 2002 - 17:15:58 EET