Re: Question about notification delivery
Re: Question about notification delivery
- Subject: Re: Question about notification delivery
- From: Jeff Moore <email@hidden>
- Date: Fri, 21 Jan 2005 12:39:19 -0800
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