Re: Questions on data in MIDIPackets
Re: Questions on data in MIDIPackets
- Subject: Re: Questions on data in MIDIPackets
- From: Brian Willoughby <email@hidden>
- Date: Thu, 21 Feb 2002 16:42:42 -0800
[ My assumption is that if the time stamp is for the head of the
[ packet, that the time stamp corresponds to the time the first byte
[ started transmitting, not the time it finished transmitting. You
[ are right, though, it could mean either. I guess we just came up
[ with a reason for poor Doug to edit the documentation again...
I think we're going to have to make a very convincing case to the Apple
engineers to get time stamps for the moment when the first byte started
transmitting. The reason I say this is because of how this will be
implemented. The easiest implementation is to stamp the current time as each
interrupt fires with new input data. Byte-oriented streams such as serial
ports will only save the first time stamp for each multi-byte message and toss
the rest, while longer bits streams such as USB will probably always receive
entire packets with a single time stamp. Either way, the time stamps for the
moment when the data is finished transmitting are easiest to compute (i.e.
now), whereas it will take interface-specific values in order to compute the
moment when the data started transmitting - because this information is only
known by the interface chips, not the processor handling the interrupts which
occur only for complete bytes/words.
[ I was thinking that the driver would be adjusting the time stamp
[ for whatever the transmission delay was.
MIDI 1.0 is simple, but USB has 2 speeds, and there will eventually be USB 2.0
to consider. I really doubt that the current implementation of Apple's MIDI
interrupt service routines subtract the transit time from time stamps. But
they might if there is good reason to do so.
[ Note that any MIDI driver receiving a MIDI event cannot react to
[ it until it has received the entire event (because the buffers
[ must contain complete events). It could capture the time stamp
[ after receiving the first byte and that would be the most accurate
[ if the sender couldn't run at full line speeds.
Reaction time for a Mac OS X MIDI driver is different from that of a dedicated
MIDI device due to the CoreMIDI API design. Although this is a reasonable
limitation, I still don't think it means that the time stamps should reflect
this limitation (the earliest reaction time). Rather, it seems important to
make the time stamp match the physical event timing as closely as possible,
regardless of any minimum reaction time on any given interface or API.
Again, I don't know how important this is to the average customer who
purchases a MIDI sequencer for recording. It's up to the ISVs to say how
important it is to maximize the accuracy. My pet example would be recording
digital audio in parallel with live performance MIDI, and that seems to be a
good example where getting the time stamps to reflect the physical event as
closely as possible will potentially be an advantage that Mac OS X could offer
above other operating system options. I've already read in other messages to
this list that sample-accurate MIDI timing is important. With MIDI 1.0, moving
time stamps from the end of the first byte to the beginning represents a
change of about 14 CD-DA samples.
Brian Willoughby
Sound Consulting
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.