Re: Midi sysex request in new thread
Re: Midi sysex request in new thread
- Subject: Re: Midi sysex request in new thread
- From: Doug Wyatt <email@hidden>
- Date: Fri, 17 Dec 2004 10:18:17 -0800
On Dec 17, 2004, at 9:48, Pete Gontier wrote:
I am not an expert on multi-threaded CoreMIDI client programming, but
I did
write the driver in question. It sounds like you are trying to receive
a
large sysex message. The driver is trying to avoid sending you every
byte as
it's received from USB (actually, they arrive in chunks of 1 to 12, but
that's neither here nor there). It's accumulating bytes into a
non-small
buffer (say for the sake of discussion it's 256 bytes long because I
can't
remember). When the message ends OR the buffer fills, then the driver
sends
the buffer up to CoreMIDI. In theory, this is supposed to reduce
overhead,
because my assumption is that you can't really do anything with a
partial
sysex message anyway,
Check out CZ-101 sysex if you're feeling masochistic. Its protocol is
something like:
sender: F0 xx... (no F7)
receiver: F0 xx... F7
sender: xx... F7
To support this, you'd want to send the buffer up to CoreMIDI if you
timeout waiting for the F7.
(CoreMIDI doesn't care about this because it only looks at the data
inside packets for the purposes of merging multiple senders to a
destination -- if one sender is in the middle of a sysex, no other
senders can send anything to that destination (except realtime) without
having their packets deferred, until the sysex ends or a timeout
elapses.)
and packing each byte into a Mach message that gets
shipped across at least two process barriers didn't seem like a good
idea
for throughput.
CoreMIDI hasn't worked this way since 10.2.2 or so. Now there are ring
buffers in shared memory between the server and client; Mach messages
are only sent on transitions between the empty and non-empty states.
But your buffering does indeed still reduce messaging and
process-switching overhead -- good.
Doug
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden