Re: [linux-audio-dev] introduction & ideas

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

Subject: Re: [linux-audio-dev] introduction & ideas
From: David Olofson (david_AT_gardena.net)
Date: Tue Mar 05 2002 - 18:37:00 EET


On Monday 04 March 2002 00.52, Paul Davis wrote:
> >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.

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.

> its precisely because audio/video are continuous streams that we
> can add a consistent delay to the system, and people are
> (reasonably) happy.

Yeah... The stream frame rate is the clock.

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

You could work with *bytes* instead, and pad with some "harmless"
event like 0xfe...

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

I've actually considered building a MIDI interface that operates that
way down to the hardware level. However, the ISA interface isn't
exactly state-of-the-art, and I'm not all that into PCI design...
*heh*

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

Then, how do they manage raw MIDI data...? It wouldn't be much work
just extracting the raw data from the SysEx packets and pass it on to
some "old style" MIDI handling code in an application.

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

Right - the biggest problem here would be the requirement for dynamic
memory management in real time context...

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

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!)

//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 -'


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

This archive was generated by hypermail 2b28 : Tue Mar 05 2002 - 20:49:04 EET