Re: question about CoreMIDI & cocoa
Re: question about CoreMIDI & cocoa
- Subject: Re: question about CoreMIDI & cocoa
- From: Doug Wyatt <email@hidden>
- Date: Fri, 1 Oct 2004 07:08:07 -0700
Every process with a CoreMIDI client in it has its own MIDI input
realtime thread. In a lot of simple cases, it isn't that horrible to
block it.
It's often not like an audio plug-in where your code is just one of
many things that happen on that thread, and where blocking can cause an
I/O glitch. If an app blocks its own input thread, the worst thing that
happens from a system performance point of view is that you've added a
few dozen microseconds of thread-switch overhead -- not a killer -- and
your input is no longer arriving as close to instantaneously as you
might like.
If you're writing an AudioUnit, on the other hand, please disregard
everything I just said and do not block the MIDI input thread.
Doug
On Sep 29, 2004, at 0:39, Kurt Revis wrote:
On Sep 28, 2004, at 8:42 AM, Robert Grant wrote:
Now that Kurt Revis has made the spectacularly useful MIDI Monitor
source available I highly recommend you take a look:
http://www.snoize.com/MIDIMonitor/Source/
Thanks for the plug... but unfortunately that code doesn't follow all
the "best practices" for the CoreMIDI thread, either. Specifically,
it allocates memory, locks a pthread mutex, and adds to a CFArray --
all things which might block the CoreMIDI thread for a while.
(For anyone playing along at home, this is midiReadProc() in
SMInputStream.m.)
One thing it does do correctly is to use a separate thread for the
bulk of the MIDI processing (which could need to do additional
allocations, do lots of processing, block for significant amounts of
time, etc.).
The "right thing" to do would be to use a lockless ring buffer to
communicate from the CoreMIDI thread to the processing thread. Then
the CoreMIDI thread would never block. The main difficulty with this
is that you could receive an arbitrary amount of data from CoreMIDI,
so it's possible that your ring buffer could become full -- in that
case you have very little choice but to give up and allocate memory
anyway. But then reading from the ring buffer is more complicated,
since you have to look in both the main ring buffer and an overflow
area. One of these days I'll get around to writing this, but I
haven't yet.
That said, if you're not doing anything musical with the received MIDI
data, this is probably completely adequate. In fact,
performSelectorOnMainThread: will probably be just fine. But if you
want to make sure you get the best MIDI responsiveness possible,
you'll have to do some more work. As always, the last 10% of the
problem takes 90% of the effort.
--
Kurt Revis
email@hidden
_______________________________________________
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