As I've said previously, the IsRunning notification is probably the
most reliable notification the HAL provides. It doesn't lie. If it
reports that it is running. The IO thread is up and running because it
is supposed to be up and running. Note that this doesn't not
necessarily mean that IOProcs will be getting called as IO could have
been started by passing NULL as the IOProcID to AudioDeviceStart()
which just starts the hardware and the device's timing services.
The HAL also will stop and restart the IO thread (yielding appropriate
IsRunning notifications) across large scale driver state changes as
well as when the driver sends pause/resume messages which normally
bracket things like format changes. This is especially true of
aggregate devices which stop and then start again when any state
change that might affect the make up of an aggregate device happens
(for example, when the sample rate changes on one of the sub-devices).
Throw in the fact that you've had numerous misunderstandings about how
things work on the very basic level and I'd say that until you fully
debug this, you don't really know what is going on. I really encourage
you to drill down and find out more about the problem. I suspect that
you have made some faulty assumption again somewhere.
On Jan 16, 2008, at 1:49 AM, 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.
Brian Willoughby
Sound Consulting
On Jan 16, 2008, at 01:33, Stéphane Letz wrote:
In my CoreAudio based application, I need to setup a timer to check
that a failure condition has been triggered (like the underlying
driver is not more running). I tried to play with
CFRunLoopTimerCreate, CFRunLoopAddTimer API without much success up
to now. Is there a recommended way to do that?
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.
--
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:
http://lists.apple.com/mailman/options/coreaudio-api/email@hidden
