Re: IOProc limitations
Re: IOProc limitations
- Subject: Re: IOProc limitations
- From: Jeff Moore <email@hidden>
- Date: Fri, 01 Jun 2001 12:19:53 -0700
on 5/31/01 6:52 PM, James McCartney <email@hidden> wrote:
>
on 5/31/01 7:44 PM, Jeff Moore at email@hidden wrote:
>
>
>
> Bear in mind, that you don't need to be holding a mutex to signal on it's
>
> associated condition variable (assuming you're using the PThread API).
>
>
Oh, I thought you had to hold a mutex just like on cond_wait.
>
I guess I just got in that habit writing semaphores with counters.
>
So that clears up all my concerns about that.
Yeah, I had the same revelation a while back. Took a large load off of my
mind and my CPU =)
>
The other thing, is that if you are doing throughput processing, not doing
>
it in the IOProc causes an extra buffer of latency, correct? Because you
>
then must have the output ready when the IOProc runs, but you don't have the
>
input yet. So you must operate on the previous buffer of input.
That is correct. Offloading the work to another thread does imply adding a
buffer of latency. This is one of the reasons you can drive the system with
buffer sizes of 64 frames.
When I say "Your IOProc should do it's business as quickly as possible and
return", it is still up to you and your app to figure out exactly what your
business is. Through processing with the lowest possible latency is an awful
good reason to do some significant work in your IOProc. You just have to be
careful about how much time you take and balance that against the needs of
the rest of the system.
--
Jeff Moore
Core Audio
Apple