Re: AudioDeviceStop and ioProc
Re: AudioDeviceStop and ioProc
- Subject: Re: AudioDeviceStop and ioProc
- From: Jeff Moore <email@hidden>
- Date: Fri, 12 May 2006 17:41:11 -0700
On May 12, 2006, at 5:21 PM, Steve Checkoway wrote:
On May 12, 2006, at 11:40 AM, Jeff Moore wrote:
On May 11, 2006, at 6:18 PM, Tim Dorcey wrote:
Let me say this clearly so that there is no misconception: The only
way to get guaranteed behavior from AudioDeviceStop() is to call it
on the IO thread. The guarantee that is given is twofold. First,
the
IOProc being stopped will never get called until Start() is called
again. Second, any output data supplied in that final call to the
IOProc will get sent to the hardware.
As a followup to this, does the same hold true for
AudioHardwareUnload() or will this not return until the HAL is in
its "essentially...uninitialized state"?
AudioHardareUnload() won't return until the HAL has torn itself down,
including all it's knowledge of the registered call backs.
So, it sounds like the best way to terminate audio capture is to
just have
my ioProc call AudioDeviceStop for itself. Easy enough. For
some reason, I
was under the impression that it would not be safe to call
AudioDeviceStop
from within the ioProc.
This is indeed the best way to stop. In fact, this is exactly how
AUHAL deals with stopping.
How about removing property listeners? Can the property listener
still be called after AudioDeviceRemovePropertyListener() has
returned?
Yes. The specific case it comes up in is if one thread is removing a
listener at the same time the HAL is calling it on another thread.
Depending on the relative timing of the events, it can be the case
that RemoviePropertyListener() will return before the other thread
makes the call to your listener proc that was removed.
If so, what is the recommended way of handling that?
Be defensive in your listener proc. For instance, always check to be
sure that the user data is valid before dereferencing it.
That's good advice for dealing with any callback from a multi-
threaded OS like X. For example, the HAL runs into the very same
issue when fielding notifications from the audio drivers. The HAL
protects itself by using a unique, non-reusable token as the user
data with these notifications. The token maps to the actual object
that is going to act on the notification. This allows the HAL to
validate the token and only proceed if it maps to an actual object
rather than crash while de-referencing a stale pointer.
--
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