Re: Device unplugged, how application should handle the situation?
Re: Device unplugged, how application should handle the situation?
- Subject: Re: Device unplugged, how application should handle the situation?
- From: Jeff Moore <email@hidden>
- Date: Fri, 11 Nov 2005 11:45:24 -0800
On Nov 10, 2005, at 11:49 PM, Rustam Muginov wrote:
Thank you for your reply
On Nov 10, 2005, at 10:34 PM, Jeff Moore wrote:
I'll preface these comments with a general note that most
applications should be using AUHAL to do their audio IO. AUHAL
handles all the heavy lifting with regards to being a proper HAL
client. In other words, if you were using AUHAL, you wouldn't have
to worry about any of this stuff.
Looks like i still know too few about CA.
Does AUHAL works on 10.2?
Yes.
Does it allow user to choose from all the devices available at the
system? My particular applicartion requires such functionality.
Absolutely.
On Nov 10, 2005, at 1:34 AM, Rustam Muginov wrote:
When the HAL sends the kAudioDevicePropertyDeviceIsAlive
notification, the actual AudioDevice object is still around and
you should feel free to remove any IOProcs or property listeners
you have installed. It's always good practice to do so.
Does this mean such "clean-up" is not necessary, and after device
is gone it is guaranteed then IOProc attached to that device
never would be called?
As part of tearing down it's internal representation, the HAL
stops all the IOProcs, and discards all it's internal buffers and
stops tracking any registered IOProcs or property listeners. So
strictly speaking, you don't have to worry to much about
unregistering IOProcs or property listeners; it happens as a
matter of course.
However, it is still good practice for your app to always
unregister stuff, provided you are prepared for errors (which you
can safely ignore).
So inside the kAudioDevicePropertyDeviceIsAlive notification its
perfecly legal to stop IOProc (even if HAL already stopped it, it
would not return error, right?) and remove IOProc.
Only after the return from this notification handler the DeviceID
is invalidated.
Yes, but as I said, you should be checking for errors and not
necessarily failing if you see them.
Are where any leaks in such situation, or CoreAudio correctly
handle it?
As far as I know, the HAL doesn't leak any of it's own data
structures. If it did, that would be a bug that should be filed in
Radar.
What would be better strategy to the application which does allow
user to choose from sound devices for input and output. track the
"device gone" situation, track the "default system sound input/
output changed" e.t.c.?
I need the application to switch to other devices "on the fly" then
current i/o device is gone.
I'd use AUHAL, which has support for all of 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:
This email sent to email@hidden