Re: AudioDeviceStop and ioProc
Re: AudioDeviceStop and ioProc
- Subject: Re: AudioDeviceStop and ioProc
- From: Jeff Moore <email@hidden>
- Date: Mon, 22 May 2006 12:19:14 -0700
On May 21, 2006, at 4:07 PM, Steve Checkoway wrote:
On May 11, 2006, at 4:01 PM, Jeff Moore wrote:
The answer to the re-posed question is no. You cannot make the
assumption that if you call AudioDeviceStop() from some thread
context other than the IO thread that the IOProc won't be called
any more when AudioDeviceStop() returns. Off hand, I can think of
a few very exceptional/coincidental MP situations where this just
isn't going to be true and you will get at least one more call.
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.
If you call AudioDeviceStop() from any thread other than the IO
thread, there are _no_ guarantees about how many more times the
IOProc will get called while AudioDeviceStop() is executing and
after it completes. It won't be a lot of calls, but the exact
number of them is not knowable ahead of time.
Coming back to this topic since I'm now getting very strange
behavior from AudioDeviceStop(). It seems to be deadlocking if I
AudioDeviceStart()
AudioDeviceStop()
AudioDeviceStart()
AudioDeviceStop().
But I'm also getting a very strange crash in what I believe is one
of the HAL's threads in pthread_body() if I just have one pair of
AudioDevice{Start,Stop}(). I suspect I'm just doing something
horribly wrong but I googled for "AudioDeviceStop deadlock" which
lead me to
http://developer.apple.com/technotes/tn/tn2029.html
Do you have a sample trace of the hang? It's hard to diagnose a hang
without one. Sometimes it's hard even when you have one =)
and in particular,
AudioDeviceStop has been changed so it no longer returns until its
IOThread is in the stopped state (r. 2726766).
That seems to contradict what you wrote above unless it's meant to
apply only when calling from the IO thread.
No, it actually doesn't since that comment is specifically referring
to the "stopped state" of the IO thread's logic which is different
than the thread actually stopping.
The point I'm trying to get across here is that it does not matter if
the current implementation of the HAL does or does not call the
IOProc after AudioDeviceStop() returns. What matters is that the
behavior is not guaranteed and should not be relied on. Knowing this,
you should take appropriate precautions against re-entrancy in your
code.
--
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