Question about notification delivery
Question about notification delivery
- Subject: Question about notification delivery
- From: Stéphane Letz <email@hidden>
- Date: Fri, 21 Jan 2005 10:02:19 +0100
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?
Thanks
Stephane Letz
_______________________________________________
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