I am not an expert on multi-threaded CoreMIDI client programming, but
write the driver in question. It sounds like you are trying to receive
large sysex message. The driver is trying to avoid sending you every
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
buffer (say for the sake of discussion it's 256 bytes long because I
remember). When the message ends OR the buffer fills, then the driver
the buffer up to CoreMIDI. In theory, this is supposed to reduce
because my assumption is that you can't really do anything with a
sysex message anyway,
Check out CZ-101 sysex if you're feeling masochistic. Its protocol is
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
and packing each byte into a Mach message that gets
shipped across at least two process barriers didn't seem like a good
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.
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