Re: Native CoreAudio plugin for Herrie - proper API usage?
Re: Native CoreAudio plugin for Herrie - proper API usage?
- Subject: Re: Native CoreAudio plugin for Herrie - proper API usage?
- From: Jeff Moore <email@hidden>
- Date: Mon, 18 Jun 2007 17:50:49 -0700
It's not an interrupt thread, per se, but it is a special kind of
thread called a time constraint thread. A time constraint thread has a
few special properties. First when it is created, the creator tells
the scheduler about the various constraints on the thread such as how
often it has to wake up and when it is awake, how much time it will
take to do it's work. Then in order to meet these constraints, these
threads are the highest priority threads on the system. Further, these
threads don't priority degrade as long as they are within their
constraints. This is why spin locks don't work here.
So in a lot of ways, it is very much like an interrupt, but it isn't
really one.
On Jun 18, 2007, at 4:07 PM, Ed Schouten wrote:
Hello Jeff,
* Jeff Moore <email@hidden> wrote:
My biggest concern would be how you are handling the critical
section. It is
never a good thing to block inside your IOProc, so you have to
finesse this
so that you don't lock any mutexes or spin in a spin lock (which
won't
behave correctly on the IO thread anyway).
I'm not familiar with the entire design behind CoreAudio, but does
this
mean that the thread that handles the IOProc is actually an interrupt
thread, allocated inside a user process?
Anyway, I got rid of the mutex usage inside of the IOProc; some atomic
integer operations to set the buffer length will suffice. Thanks for
your feedback! :-)
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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