Hmm, perhaps you can set a timer to fire after your "certain amount
of time" whenever you are notified of "OFF" and then cancel this
timer whenever you receive "ON." This way, the timer will only
trigger your failure code if the device stays OFF for a long time,
but the whole thing will just be cancelled if the dropout is a few
milliseconds.
It's been a while since I used timers, but I believe there is still a
way to set a future event and then cancel it before it fires.
Brian Willoughby
Sound Consulting
On Jan 16, 2008, at 01:49, Stéphane Letz wrote:
Le 16 janv. 08 à 10:44, Brian Willoughby a écrit :
My first reaction is that you should not need to set up a timer to
poll for an audio failure condition. It seems like you could
register a callback for a notification when the audio driver stops
running. If you're writing a custom driver, then perhaps you
should send such a notification.
The thing is that my code is listening to
kAudioDevicePropertyDeviceIsRunning so that do detect the observed
device is not running anymore. But in lot of cases I see a sequence
of kAudioDevicePropertyDeviceIsRunning OFF followed by
kAudioDevicePropertyDeviceIsRunning ON just a few millisec after (for
example when a sample rate change is done on the device that is
observed).
The result that listening to kAudioDevicePropertyDeviceIsRunning OFF
is not enough: I would need to be sure this condition stay for a
certain amount of time, thus the timer idea. But maybe there is a
better way to do that.
Thanks
Stehane Letz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/coreaudio-api/email@hidden
