Re: Identification of IOAudioDevice from HAL client app
Re: Identification of IOAudioDevice from HAL client app
- Subject: Re: Identification of IOAudioDevice from HAL client app
- From: Jeff Moore <email@hidden>
- Date: Mon, 11 Nov 2002 13:21:53 -0800
On Monday, November 11, 2002, at 12:43 PM, Shaun Wexler wrote:
My thoughts for augmenting the transport type would be to provide a
transport-specific value, which would either A) assist in locating the
actual hardware device in the IORegistry, or B) provide a port number,
such
as with USB/FireWire to locate the device, or with PCI, the host
bus/slot
number and possibly another enumerator for individual devices on said
card.
Network might return an IP address, or pointer to Rendezvous name. It
could
be nil; it would just be a convenience property that, if it existed,
would
allow hardware device enumeration.
I don't like this. This means that we need to define more data
structures and more infrastructure to support what I consider a pretty
sketchy situation.
Like I said, you can sniff the registry yourself if it matters that
much. Given that the GUID string is also in the registry, it makes it
trivial to map the registry entry back to the AudioDeviceID.
One flaw with the HAL that I see (with respect to user convenience and
developer coding effort) is that it returns a new AudioDeviceID when a
device dies and is subsequently reinstalled, ie if a USB cable is
unplugged
and quickly reinserted. I agree with the current implementation of
this
behavior, of couse. You couldn't do it any other way. But if you add
some
of my features, it would be easier to hide the reconfiguration from the
user, and allow them to continue working. Right now, I added quite a
bit of
code to support ConfigDict's and AudioChannel objects, so this couldn't
happen, and any client of a stream would automatically resume
operations
when a newly added device with suitable properties became available
again.
AudioDeviceIDs are meant to be transient. Device GUIDs are the things
you should be using to represent a device persistently. In my own apps
(and indeed in the HAL itself) as long as I match GUIDs, I never have
trouble with matching up devices with what I was using previously.
That's what they are there for.
One could argue that if you are trying to reconcile a new device's
capabilities with the capabilities of another device that is no longer
there for the purposes of remapping IO, you need to look at a lot more
info then just how it was attached to the system and what other devices
it might be physically attached to. This would seem to mean absolutely
nothing if I were trying to do what you are doing.
I have to admit I really have trouble with visualizing what you are
talking about and what sort of advantage it has for your users.
Personally, I would hate using a piece of software that thought it knew
more than I did about how I want to route audio in my system when I
move it from studio to studio.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.