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: Shaun Wexler <email@hidden>
- Date: Mon, 11 Nov 2002 12:43:42 -0800
On 11/11/02 12:05 PM, "Jeff Moore" <email@hidden> wrote:
>
This is along the direction for the API I'd been mulling over. It's not
>
on the list of "things to do next" (or even soon), however.
>
>
> As an example, 'Apple Built-in'
>
> would return two AudioDeviceID: one for input and one for output.
>
>
Wouldn't work this way. The Built-In Driver presents it's input and
>
output together, so there is only one AudioDeviceID for it.
Yes, I caught my mistake just after I posted the message. I meant to write:
the 'Apple Built-in' would return one AudioDeviceID, as it only returns one
AudioDevice for both input and output , but a USBAudio device with separate
ID's for each AudioDevice would each return the same array of two matching
ID, for self and sibling(s).
>
The only time devices are split up are if the driver is doing something
>
very strange, against recommended practice (like the M-Audio Delta
>
10/10 driver's multiple devices), or the hardware is clocked separately
>
for each section like USB.
Such as happens with the Sound Devices USBPre, which is the interface of
choice for the majority of my user base.
>
In 10.2, we added kAudioDevicePropertyTransportType which returns an
>
enum that says how a device is attached to the system. What would you
>
augment this with?
I already use that (thanks!) to provide a transport ICON in the device list,
which helps pick out the different interfaces attached. For development,
I'll use a combination of one or two USBPre, a MOTU 896 (FireWire), built-in
audio, and (soon) a MH Mobile I/O. The majority of users of my app will be
running it on a laptop.
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.
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.
--
Shaun K. Wexler
http://www.hellsgate-sound.com
http://www.macfoh.com
http://www.aapls.com
_______________________________________________
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.