Re: setting up independent timing thread
Re: setting up independent timing thread
- Subject: Re: setting up independent timing thread
- From: Kurt Revis <email@hidden>
- Date: Fri, 12 Jul 2002 15:55:57 -0700
On Friday, July 12, 2002, at 11:12 AM, Jim Coker wrote:
I'm writing a MIDI sequencing application using Cocoa/Objective-C for
the UI and C for MIDI handling.
In order to setup an internal clock, as well as service free-running
MIDI LFOs, I need
to setup a thread that wakes up approx every millisecond to do
clock-related calculations,
deal with incoming events grabbed by my MIDI ReadProc, and pre-schedule
outgoing
MIDI events.
I have two obvious choices for thread API's -- either Cocoa NSThreads
or pthreads
You don't really have to make a choice here. NSThreads are implemented
on top of pthreads on top of Mach threads, and you can sprinkle calls to
all three layers into one program, if you like. It's not really the
best idea in general, but right now, sometimes it's the only way to do
things.
(I have an ObjC class which uses NSThread to start a timing thread, but
uses the Mach thread API to set the scheduling parameters, and uses
POSIX API to wake up periodically.)
but what isn't obvious is how to most effectively setup timed
activation of the thread and what priority it should have.
Well, first of all, check the archives of this list -- around May 5
there was a good discussion of how to set up thread priorities. (I have
been saying this a lot lately...) You probably will have to make your
timing thread time-constraint, but you really should experiment a bit to
see if that is really necessary.
Then you just have the issue of how to put your thread to sleep for a
millisecond. There are a frightening number of ways to do this, and of
course they're all slightly different. You will probably get the best
results with lower-level APIs. I bet usleep(1000) will work just fine
for you. (Ignore the man page for usleep--it's almost completely wrong.)
(Oh yeah: checking my mailbox, I wrote another explanation of sleeping
issues on April 28, which you might also want to read.)
CFRunLoopTimer looks promising, but I'm having a hard time finding
sufficient doc on it.
CFRunLoopTimer might work, but is more overhead than you really need.
Months ago I did some timing tests with NSTimer (which is basically just
a wrapper on CFRunLoopTimer) and found that I couldn't get anywhere near
1 ms resolution. Results were more like 50-100 ms. But maybe I was
doing something wrong; I didn't take very good notes at the time.
Hope this helps.
--
Kurt Revis
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.