Re: Some more questions about sample rate notifications
Re: Some more questions about sample rate notifications
- Subject: Re: Some more questions about sample rate notifications
- From: Jeff Moore <email@hidden>
- Date: Tue, 15 Jan 2008 09:07:51 -0800
kAudioDevicePropertyDeviceIsRunning is only ever sent from the devices
IO thread. It gets sent when the IO thread finishes initializing
itself to indicate that things are running as well as when the thread
is exiting to indicate that things have stopped. There are no other
ways to get this notification (BTW, you can see this for yourself in
the HAL plug-in SDK in the class HP_IOThread). If you are indeed
seeing this notification, it means that somebody is starting IO in
your process. If it isn't you, then it is some API you depend on like
QT or something else.
That said, are you sure you didn't sign up for
kAudioDevicePropertyDeviceIsRunningSomewhere? When used in conjunction
with our built-in hardware you will see the behavior you describe
where this notification fires off after the sample rate is changed.
This is due to a bug in the built-in driver.
On Jan 15, 2008, at 7:39 AM, Stéphane Letz wrote:
O
>Either you have to fail outright and put up an alert to tell the
user what happened or you need to implement some kind of fail-over
to another device. This is exactly what an application >should be
doing anyway. It's part of the app's job description to re-evaluate
the state of a device when said state changes dynamically and handle
the changes in a sensible way, whatever >they may be.
>It would seem that the root cause of your problem are that your app
fails to account for the rather radical state changes that can come
about when using aggregate devices. I think if you >address this,
not only will your app work better under these circumstances but I
imagine that it will be much more robust to changes in hardware
state in general. Which is a good thing.
OK.
Before implementing a more complex fail-over mecanism I'm just
trying to do a simple "warn the user if something bad happened on
the driver". Basically my application is now also listening to
"kAudioDevicePropertyDeviceIsRunning" property, so that having
kAudioDevicePropertyDeviceIsRunning OFF would be notified to the user.
The bad thing is that that are some strange sequence of
kAudioDevicePropertyDeviceIsRunning notfication occur in some
situations, for example:
- start our program
- start Ableton Live: it seems Live restores it's saved SR event if
the saved SR equal the current SR for the device...
- our program gets kAudioDevicePropertyDeviceIsRunning OFF then
kAudioDevicePropertyDeviceIsRunning ON after some millisec..
So relying on kAudioDevicePropertyDeviceIsRunning seems not be
reliable. I could probably check for the
kAudioDevicePropertyDeviceIsRunning OFF state to stay a bit of time,
but this start again to be complex.
Is the any other property to be listened to that could say in a more
reliable way that the device is no running anymore? (or any other
"sensible" strategy??)
--
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