Subject: Re: [linux-audio-dev] introduction & ideas
From: David Olofson (david_AT_gardena.net)
Date: Sun Mar 03 2002 - 02:20:55 EET
On Monday 25 February 2002 18.06, Paul Davis wrote:
[...audio and video...]
> MIDI is different, because its not streamed - its an asynchronous
> data flow that can go from saturating the wire to having no data at
> all for extended periods of time and back again. video and audio
> are not like this, AFAIK.
Well, that's true for raw MIDI data - but to use it for anything
serious (apart from implementing a cheap software MIDI thru), you
need to timestamp the events an some point.
As the timestamps are in, I prefer to think of a "series of MIDI
events" as - guess what - a stream! Even if it's a variable data rate
stream of structured data, it's still a stream with a steady
heartbeat, in the form of the clock used for the timestamping. Thus,
it can be "chopped up" into buffers of suitable size (measured in
time), and handled according to the SE model, just like audio or
video.
BTW, even Windoze handles MIDI this way these days! ;-)
(The truth is that it *has* to, as a result of it's [lack of] real
time performance. "Replacing jitter with constant delay.")
[...]
> I think this is much harder than you think :) Most MIDI devices
> cannot tell you when MIDI data will be delivered to the wire. Even
> the at the hardware level, there is a (small) FIFO that buffers
> between the device driver and the UART chip. On decent hardware,
> this tends to be 8-16 bytes long, which represents 3-5
> NoteOn/NoteOff messages and about a few msecs of real time.
The never ending joy caused by the tremendous bandwidth of MIDI! :-)
Short of hacking the driver to get FIFO status readback, all you can
do is to assume that the bandwidth will be at least x*31250 bps,
where X is some sensible value just below 1.0.
Any serious MIDI interface (*) will do what most UARTs do; just send
bytes in the FIFO as fast as possible - so you can assume that
whenever you write N bytes, all of them will be "out the door" in
(N * seconds_per_byte) seconds. Whenever you detect a MIDI write
after the bytes written by the last one should have been sent, just
reset your counters to the initial (empty FIFO) state.
As long as the bandwidth utilization stays on a reasonable (that is,
you occasionally get a chance to reset your counters), you can
estimate the output latency for the next N MIDI bytes at any time.
(*) Note that most consumer card MIDI interfaces are *crap*...
> My own approach to this has tended to be to deliver data directly
> to the device driver (i.e. do not use a "sequencer" layer) at my
> best approximation to when it should be delivered to the wire, and
> assume that the device driver and the hardware will work hard to do
> the best they can.
That's what most sequencers used to do before Windoze got the new
timestamped API - and it worked well enough. (At least if you had a
prefectly "healty" system...)
> Notions of time are best handled entirely in an application, as far
> as i can tell. I don't want an external system to try to deliver my
> stuff "when it is supposed to" unless "when" is "right now".
It *should* work well as long as there's a solid way to translate
your internal time into timestamps...
> The
> system's sense of priorities and so forth might be very different
> to what I want.
...but indeed, it's entirely possible that your user space SCHED_FIFO
thread does a *much* better job than the kernel sequencer, at least
on cards without hardware timing. (Unfortunately, that feature was
removed from the so-called "MPU-401 compatibles" many years ago. That
was when PCs got fast enough to do the timing in software, but before
Windoze practically eliminated that option, without even providing an
API that could support new cards *with* h/w timing...)
//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 : Mon Mar 04 2002 - 00:46:37 EET