Re: MIDI timestamp ordering (was: MIDI processing question)
Re: MIDI timestamp ordering (was: MIDI processing question)
- Subject: Re: MIDI timestamp ordering (was: MIDI processing question)
- From: Doug Wyatt <email@hidden>
- Date: Mon, 5 Apr 2004 16:06:07 -0700
On Apr 1, 2004, at 3:46, Kent Clelland wrote:
hi doug & bill and everyone else.
I' m experiencing some unexpected behaviour in MIDI processing and
before I go coding myself in circles I want to check and see if my
expectations aren't maybe a little bit too high ; -)
here is what is happening:
I enable MIDI input to my application like this:
::
MIDIInputPortCreate(mClient,CFSTR("Output"),ReadProc,(void*)this,&mInPo
rt[inIndex]);
and when I receive MIDIPacketLists in my ReadProc() I am _expecting_
that they are sorted in timestamp - ascending order. although I have
not been able to find any solid documentation for or against this, I
am simply expecting that a modern operating system driver will
naturally place the packets in the list as they arrive and how can a
later packet arrive before an earlier one anyway? (huhuh)
HOWEVER, what I am _experiencing_ is that I am in fact recieving
events in the MIDIPacketList sometimes in ascending order and
sometimes in descending, and I *guess* I will someday maybe get some
in an arbitrary order.
so my question is the following: is it wrong for the application
programmer to expect the osX midi system to deliver sorted packet
lists?
[ or one could formulate it this way ]
is it a mistake that MIDIPacketLists are being delivered with
arbitrary timestamp sorting?
[ in which case : ]
whose mistake is it? the USB driver's author?
http://www.motu.com/downloads/MTPMac/usbx_1.22.hqx
or what???
in fact it seems a little silly that if in 90% of the time packets are
being recieved in a given timestamp ordering, to then insert
application code in the MIDI ReadProc() to (RE)Sort the list because
90% of the time this code will only be overhead. PLUS the method
with which these packets are delivered is not the most conducive to
sorting... walking the list with MIDIPacketNext()..
some colleagues are of the opinion that because this seems to only
happen with one particular driver (at the moment) that the driver
"sucks" and there's not alot we can do about it. *HOWEVER* I
personally am of the opinion that since the documentation is not 100%
comprehensive it is a better idea to field the issue here in this
forum, because maybe on the other side of the sargasso they are saying
that those music apps "suck" because they don't sort their incoming
MIDI ... documentation interpretations can lead to such pithy
situations... soooo---> am I missing some documentation? maybe I'm
looking in the wrong place?!
so this all boils down to this multiple choice question:
1) it is the MIDI driver's responsibility to deliver MIDI packets in
the correct order.
[ OR ]
2) it is the application developer's responsibility to (re)sort all
recieved MIDI packets.
Kent, all,
My suspicion is that the out of order events are coming in from
different MIDI sources. Is this true?
Even if those sources are on the same piece of hardware, the way that a
MIDIPacketList can only represent one source stream suggests that if
events arrive from multiple sources within the same small time window,
it's easy to imagine the driver generating two packetlists like this:
from A:
time T event 1
time T + 2 event 3
from B:
time T + 1 event 2
The driver might be able to reduce the likelihood of doing this, by
splitting the packetlist from A into two, but suppose the driver is
receiving data from its hardware in the same kind of per-source data
structure -- and that B's packetlist arrives 1 ms later in a different
USB bus frame.
I would like to say that a driver should be responsible for presenting
events in ascending timestamp order -- but only on a per-source basis.
Driver developers -- if this isn't possible for you, could you please
explain why not? I think requiring that an individual source's
timestamps are delivered in order is necessary to guarantee the
integrity of a MIDI stream.
But I can't say that an application can or should make any assumptions
about the relationships of the timestamps of messages coming from
different sources -- i.e., an application must be prepared for the
timestamps from different sources to be out of order.
Why? Sorting would require knowing the maximum latency between a
timestamp generated outside the computer, and the time when the sort is
performed, and imposing that latency on *all* incoming data so that the
sort can be performed correctly, at a time when the packet-sorter could
assume that all of the data to be sorted has arrived. But we don't
currently know what that latency is, and I'm not sure it *can* be known
with 100% reliability. An event might arrive just late enough to miss
being sorted, and then it would either have to be dropped --
unacceptable -- or, its "backward" timestamp would be delivered to the
application -- the same situation that we're in right now.
Applications tend to rely on timestamps in two ways:
- recording, where it shouldn't be a big deal to sort events after the
fact or even during recording
- rendering on a deadline and using the timestamps for more accurate
event scheduling. Here too you run into the problem of not really
knowing the latency from the source to the renderer except by guessing
based on the incoming timestamps.
So I would say, sort the timestamps if you can, and if you can't ...
well, that's a longer discussion.
Best regards,
Doug
--
Doug Wyatt
Core Audio, Apple
_______________________________________________
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.