• 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: Question about notification delivery
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about notification delivery


  • Subject: Re: Question about notification delivery
  • From: Jeff Moore <email@hidden>
  • Date: Fri, 21 Jan 2005 12:49:18 -0800

Also note that these things are contained within a single process. In other words, if you change a property where the notification of the change is sent synchronously, your call to SetProperty won't block while other processes are calling listeners.

On Jan 21, 2005, at 12:39 PM, Jeff Moore wrote:

There is no "time out" mechanism in the situation you describe. If your listener blocks, the call to AudioDeviceSetProperty will block until the listener unblocks.

On Jan 21, 2005, at 1:02 AM, Stéphane Letz wrote:

I have a question about the way notifications are delivered to listener threads in CoreAudio applications. From a previous mail (14 dec 2004), Jeff Moore said:

>When an app calls AudioDeviceSetProperty() to change the IO buffer size
>on an IOAudio device, unless the call is being made from the actual IO
>thread, the entire operation happens on the thread on which the
>AudioDeviceSetProperty() call was made and completes in it's entirety
>before AudioDeviceSetProperty() even returns. If the call is made on
>the IO thread, it returns immediately and the HAL defers performing the
>operation until after it has finished calling all the IOProcs for the
>current cycle.


When the AudioDeviceSetProperty is *not* called form the IO thread, I understand that notifications are delivered in a synchronous manner since the AudioDeviceSetProperty function "waits" for the notification to be handled. I guess this is the case also for notifications that are waited by different processes.

What happens if a notification listener blocks for some reason, thus is not able to handle the notification properly? Is there any "time out" mechanism implemented so that the AudioDeviceSetProperty call does does wait forever and proceed with the next listener thread?

--

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: 
 >Question about notification delivery (From: Stéphane Letz <email@hidden>)
 >Re: Question about notification delivery (From: Jeff Moore <email@hidden>)

  • Prev by Date: Re: AirTunes API and DTS (Modified by Stephen Davis)
  • Next by Date: Re: Direct Monitoring
  • Previous by thread: Re: Question about notification delivery
  • Next by thread: Sample rates and AUGraphs
  • Index(es):
    • Date
    • Thread