Re: Locking the CoreAudio thread
Re: Locking the CoreAudio thread
- Subject: Re: Locking the CoreAudio thread
- From: Jeff Moore <email@hidden>
- Date: Fri, 18 Jan 2002 13:05:23 -0800
on 1/18/02 12:29 PM, Timothy J. Wood <email@hidden> wrote:
>
Any suggestions on how to temporarily block CoreAudio from issuing
>
callbacks would be much appreciated. Presumably IE avoids this problem
>
somehow...
I don't advise blocking the HAL's IOThread. You will get timing anomalies
that result in lost data. This is why there are no such locks you can take
to prevent the HAL (and therefore the Sound Manager) from calling you.
You need to find a way to do this that doesn't involve blocking the HAL's
IOThread. There are posts about this in the archives since, as you would
imagine, this has come up on this list before.
That said, one thing that has occurred to me since I wrote a lot of those
posts is that what the HAL objects to is blocking its IOThread for an
_unbounded_ amount of time which is what you do with a call like
pthread_mutex_lock.
It should be safe to block the IOThread for a bounded amount of time,
provided that this time doesn't take up more than the buffer you're being
asked to provide. In theory, this should be no different than if you spent
that time doing DSP or whatever. In practice, it could be much better since
you aren't spinning in a very high priority thread.
But, locking a mutex with a timeout will also involve scheduler overhead and
latency of, first, the timer interrupt, and then, of IOThread running again,
so be sure to account for that in your timeout values. There also may be
some problematic interactions with the scheduler I'm not aware of (I haven't
tested any of this) due to the fact that the IOThread is a time constraint
policy thread and this sleep period is not in accordance with the time
constraints the HAL has set for this thread. So use with caution.
I would be interested to hearing the results if anybody tries this out. My
gut says that it ought to work (as long as you keep the scheduler latencies
in mind), but I don9t know for sure.
--
Jeff Moore
Core Audio
Apple