• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
atexit and kAudioDevicePropertyDeviceIsRunning problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

atexit and kAudioDevicePropertyDeviceIsRunning problem


  • Subject: atexit and kAudioDevicePropertyDeviceIsRunning problem
  • From: Michael Guntsche <email@hidden>
  • Date: Thu, 27 Apr 2006 23:27:41 +0200

Hello,

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.



Kind regards,
Michael _______________________________________________
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
  • Follow-Ups:
    • Re: atexit and kAudioDevicePropertyDeviceIsRunning problem
      • From: Jeff Moore <email@hidden>
  • Prev by Date: How to decode mData in AudioBuffer?
  • Next by Date: Re: atexit and kAudioDevicePropertyDeviceIsRunning problem
  • Previous by thread: Re: How to decode mData in AudioBuffer?
  • Next by thread: Re: atexit and kAudioDevicePropertyDeviceIsRunning problem
  • Index(es):
    • Date
    • Thread