Re: atexit and kAudioDevicePropertyDeviceIsRunning problem
Re: atexit and kAudioDevicePropertyDeviceIsRunning problem
- Subject: Re: atexit and kAudioDevicePropertyDeviceIsRunning problem
- From: Jeff Moore <email@hidden>
- Date: Thu, 27 Apr 2006 15:33:03 -0700
kAudioDevicePropertyDeviceIsRunning has never indicated whether or
not the HAL is calling IOProcs. It is there to say whether or not the
IO thread itself is running in the process. It is a common and legal
case that the IO thread is running even though no IOProcs are being
called.
Note that this can conceivably come about quite easily at process
exit because about the only thing the HAL does to tear itself down is
stop any running IOProcs. The IO thread itself may not get torn down
before the process exits, so it is conceivable that the
kAudioDevicePropertyDeviceIsRunning will thus still be true even
though the IO thread is not calling IOProcs.
Finally, I'd be a bit worried about using an atexit handler for this
job. The reason why is that the HAL is also using an atexit handler
to clean itself up. This means that the order of execution of your
handler and the HAL's is going to depend on the order in which the
handlers are registered. Conceivably an application might initialize
the two libraries in any order, so the atexit handlers may not always
fire in the right order. As such, I would be careful about what you
do in your atexit handler. It is quite conceivable that the HAL has
already unloaded itself by the time yours runs.
On Apr 27, 2006, at 2:27 PM, Michael Guntsche wrote:
Today I played with libao again and noticed that the problem I had
fixed a few months ago had reappeared, namely the hang on shutdown
if a program teared down audio with an atexit. In this special case
(libao) would hang waiting for the remaining data to be read be the
audioCallback which never happened.
I am pretty sure it worked with 10.4.4 and 10.4.5 but something
must have changed with 10.4.6.
Back then I changed the code in the macosx libao driver to check if
the audiodevice was still running.
<snip>
sizeof_running = sizeof(UInt32);
AudioUnitGetProperty(internal->outputAudioUnit, 0, false,
kAudioDevicePropertyDeviceIsRunning, &sizeof_running, &running);
if (!running) {
return 1;
}
</snip>
If it was not running, I just returned never dealing with flushing
the rest of the audio buffer.
If it was running the code continued and waited for the remaining
data to be flushed and would then tear down the AU.
// Wait for any pending data to get flushed
pthread_mutex_lock(&internal->mutex);
while (internal->validByteCount)
pthread_cond_wait(&internal->condition, &internal->mutex);
pthread_mutex_unlock(&internal->mutex);
If I stop the application now it hangs at pthread_cond_wait which
means the audioCallback responsible to signal the internal-
>condition is no longer getting called.
For testing purposes I replaced pthread_cond_wait with
pthread_cond_time and also added the DeviceIsRunning in the while
loop. The result was suprising. I got the result that the
audiodevice was still running but apparently the audioCallback was
not executed at all.
Does this mean that checking DeviceIsRunning does not neccessarily
mean that the callback is getting called, or is there really
something wrong here? If the first is true, what is the correct way
to check if the AU is still running?
Any help is very much appreciated.
--
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