Re: Newbie documentation for MIDI
Re: Newbie documentation for MIDI
- Subject: Re: Newbie documentation for MIDI
- From: Philippe Wicker <email@hidden>
- Date: Sun, 1 Dec 2002 13:22:17 +0100
On Sunday, December 1, 2002, at 08:57 AM, Kurt Revis wrote:
On Tuesday, November 26, 2002, at 11:48 AM, Philippe Wicker wrote:
I don't know how notification posting works, but I assume it is
similar to posting a carbon event.
Not really. It's pretty simple: when a notification is posted to a
notification center, the notification center just looks up all objects
which are observing that notification, and sends a message to each
observer in turn. There's no queuing behavior at all.
Ooops, I realized after having read some others postings on that topic
that my assumption was incorrect. But anyway, because the notification
is executed in the context of the notifier thread, this mechanism does
not solve the problem of concurrent accesses to complex structures
shared between the UI thread and "MIDI" or "AUDIO" threads.
The idea is to write "events" in a non blocking FIFO which is
periodically polled by the UI thread (CFRunLoop with timer ?).
In some particular use cases a FIFO isn't even necessary. For instance,
if one want to draw a cursor that reflects the current song position,
then the needed information may simply be stored in a UInt32 which will
be updated or acquired atomically. The need of a FIFO or something
equivalent turns up when the consumer thread (the UI thread) not only
needs the last value but a bunch of intermediate values. Updating a VU
meter could be an illustration of such a use case.
Here's something similar which no one mentioned last week. You can
create a run loop source and attach it to one thread--say your app's
main thread, where all UI interaction happens. Then you can cause
this run loop source to activate from a different thread, like this:
// It's up to you to set these up:
CFRunLoopRef mainThreadRunLoop;
// Gotten via CFRunLoopGetCurrent() while running in the main
thread
CFRunLoopSourceRef runLoopSource;
// call CFRunLoopSourceCreate() to create this,
// and CFRunLoopAddSource() to add it to the main thread's run
loop
// In the work thread:
// Signal the run loop source, so it runs
CFRunLoopSourceSignal(runLoopSource);
// And make sure the run loop wakes up right away (otherwise it
may take a few seconds)
CFRunLoopWakeUp(mainThreadRunLoop);
// Sometime soon the runLoopSource's callback will get called in
the main thread.
Surely a nice solution if it is not blocking.
This is basically equivalent to using an NSPort or CFMachPort, I
think, but I don't know if the exact blocking details are the same (if
this matters to you).
Blocking behavior does matter to me.
This is obvious for the "AUDIO" thread. If it is working on small
buffers (to minimize the latency for instance), then the callback
period will be small and the job must not be blocked to avoid audio
drops and glitches (well, I assume that the callback period will be
determined by the size of the buffer, eg 2.9 milliseconds for a
128/44.1 KHz samples buffer).
In my opinion, this is also true for the "MIDI" thread although less
stringent in that case. If the "MIDI" thread is waiting for the UI
thread, which may be in turn be preempted for some reason, then the
"MIDI" thread blocking time can be important. If in some situation this
blocking time reaches, say, 50 or 100 milliseconds, this may produce
unacceptable latency (particularly when the musician is playing live).
This method doesn't require any periodic polling, and it only uses
CoreFoundation so there's no Objective-C required.
I will probably sometimes switch to Objective-C. But all my "legacy"
and current code is in C++. I feel comfortable with that language and
not (yet) with Obj-C. Besides, I frequently use multiple inheritance
(from abstract - Java-like interface - and concrete classes) and I am
used to that way of thinking.
Philippe Wicker
email@hidden
_______________________________________________
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.