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:24:52 -0800
On 11/11/02 5:48 AM, "Bill Stewart" <email@hidden> wrote:
>
The 2 devices that AMS presents as one are the USB drivers where in and
>
out are separate drivers...
>
>
It does this simply by checking the name of the device and if they are
>
the same (and one has input the other output streams ONLY) it presents
>
this to the user as a single device - this was only done to make this a
>
simpler and more understandable presentation of the devices for a user
>
>
I don't know that I'd call this the "Apple way" but this works (and we
>
use it:)
I had thought of that originally, but then realized that the likely
situation would arise where the user had two or more of the same interface.
The device I'm using for this example is Sound Devices USBPre. It uses its
own kext, based closely on Apple sample USBAudio driver code. The HAL
returns a separate AudioDeviceID for input and output, because they have
different clock rate and bit sizes. Using the above DeviceName matching
method, and two identical hardware devices, it would be possible to
incorrectly match the input from Device_A with the output of Device_B. How
does AMS handle this situation? Then what if there are more than one
IOAudioEngine for a device's input or output, and there are more than two
AudioDeviceID? Would it then revert to displaying them individually? That
is counter-intuitive, IMO.
There are also a couple possibly unimplemented features, which may or may
not be unique to USBAudio: device hardware serial number, and device short
name. Short names are simple to generate by parsing to the first space, but
may be less than accurate for different manufacturers: "MOTU 828" and "MOTO
896" come to mind.
I'd hate to have to ship my >$1k app (rather significant user base) with a
GUID parsing hook that could break in the future.
I guess that brings my additional HAL feature request to 5. Four read-only
hardware properties, and one r/w property for assigning a user CString as a
refCon for drivers/hardware which support it, and/or store it in firmware.
--
Shaun Wexler
http://www.macfoh.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.