• 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
Re: Is it dangerous to call AudioDeviceGetProperty() from within a AudioHardwarePropertyListenerProc?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is it dangerous to call AudioDeviceGetProperty() from within a AudioHardwarePropertyListenerProc?


  • Subject: Re: Is it dangerous to call AudioDeviceGetProperty() from within a AudioHardwarePropertyListenerProc?
  • From: Jeff Moore <email@hidden>
  • Date: Tue, 18 Jan 2005 12:05:10 -0800

It's not illegal at all to call any HAL API at any time from any thread. The HAL is intended to be 100% re-entrant.

That said, there are some pretty easy ways to cause your own code to hang because the thread context on which your listener proc is called may not be what you expect it to be. If you want to send me the sample trace of the hang, I'd be happy to look at it and help you figure out what's going on.

On Jan 18, 2005, at 7:58 AM, Jesper Papmehl wrote:

Hi!

I sometimes get what appears to be a deadlock in my app when I change the sample rate of the audio device I'm using.

I change the sample rate by calling SetDevicePropertyStreamBasicDescription() from the main thread. I have previously installed a property listener that listens to various property changes (kAudioDevicePropertyStreamConfiguration and some others). In my property listener I (among other things) get the values of a bunch of properties like kAudioDevicePropertyStreams, kAudioStreamPropertyDirection and kAudioDevicePropertyDeviceIsRunning.

In some cases (but not always) when I change the sample rate, my app hangs. When I sample my hung app, I see that the UI thread hangs inside SetDevicePropertyStreamBasicDescription, in a call to semaphore_wait_signal_trap. One of the CoreAudio threads also appears to have hung inside my property listener in a call to either AudioDeviceGetPropertyInfo or AudioDeviceGetProperty (I don't see the CoreAudio function names in my backtrace) which in turn eventually calls semaphore_wait_signal_trap.

So, my question is, is it forbidden to call AudioDeviceGetProperty[Info] in a property listener callback? Or does anyone have any other idea what I might be doing wrong?


--

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
References: 
 >Is it dangerous to call AudioDeviceGetProperty() from within a AudioHardwarePropertyListenerProc? (From: Jesper Papmehl <email@hidden>)

  • Prev by Date: MusicPlayer Callback Help
  • Next by Date: Re: Using converter API for a multiple streams driver
  • Previous by thread: Is it dangerous to call AudioDeviceGetProperty() from within a AudioHardwarePropertyListenerProc?
  • Next by thread: MusicPlayer Callback Help
  • Index(es):
    • Date
    • Thread