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: Rustam Muginov <email@hidden>
- Date: Fri, 11 Nov 2005 10:49:48 +0300
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?
Does it allow user to choose from all the devices available at the
system? My particular applicartion requires such functionality.
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.
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.
--
Sincerely,
Rustam Muginov
_______________________________________________
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