Subject: Re: [linux-audio-dev] introduction & ideas
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Mar 04 2002 - 01:52:38 EET
>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.
sure, but this doesn't change my point that the clocks run at
different rates.
its precisely because audio/video are continuous streams that we can
add a consistent delay to the system, and people are (reasonably)
happy.
but with MIDI, we've got a clock running at a most-desirable rate of
31.25kHz, yet no continuous data stream. MIDI data ends up with
timestamps that are all over the place with respect to the
regular-as-clockwork ticks of the (say) audio clock. hence, we can't
schedule based on the audio clock without annoying users, and hence we
end up potentially out of sync with that clock. this can be corrected
for by using a PLL, but its a pain to code.
one possible alternative would be to deliver 31250bps to the device
driver, but there is no way to mark which bits are "real" and which
are "padding". this contrasts with audio (and i would imagine video
too) in that there is a way to dump send "no data here" (zero) bytes
as part of the regular data flow. it would be really cool to have a
MIDI port that did this - it would function just like an audio
interface, and would use some way of marking bits as ones that really
need to be sent and ones that don't. you'd just stream to it exactly
the same way as we stream to an audio device: it wakes us up, says
"hey, i need 31250 * N bits", and we deliver whatever we think is the
right data for that time slice.
i don't know of any MIDI devices that do this. too bad.
> 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.
that doesn't really work very well in the general case. Things like
SysEx messages may take seconds to deliver/receive, and they can also
be huge. Most programs will be pretty unhappy to receive just part of
a sysex message - they either will want to do all the parsing or none
of it. asking them to deal with packetized delivery of semantically
whole MIDI messages won't win many friends, i fear. if you try to
deliver them in one lump, that can cause major stress for a buffer
system optimized on the assumption that most messages are less than 32
bytes.
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.
--p
--p
This archive was generated by hypermail 2b28 : Mon Mar 04 2002 - 06:41:31 EET