Re: HAL Devices and Streams (with QuickTime)
Re: HAL Devices and Streams (with QuickTime)
- Subject: Re: HAL Devices and Streams (with QuickTime)
- From: Jeff Moore <email@hidden>
- Date: Tue, 15 Jan 2002 14:24:19 -0800
on 1/14/02 11:05 PM, email@hidden <email@hidden> wrote:
>
>> Audio devices come and go at will under OS 9 too. USB audio for example...
>
>
>
> Actually this is not true. 9 sucks particularly bad in this regard. With USB
>
> audio on 9 you are allowed to connect exactly 1 USB audio device. Connect a
>
> second and you won't be able to access it through the Sound Manager. Plus,
>
> you won't be able to use the built-in hardware as soon as you plug in your
>
> first USB Audio device.
>
>
>
Not true. Boot into OS 9. Plug-in two Griffin USB iMics (iMics are outputs
>
too). Check the Outputs tab in the Sound control panel. You will see two
>
USB Audio options, in addition to Built-in. My software (via QT) allows
>
independent and simultaneous output via both Griffin iMics under OS 9, or
>
even Built-In and USB.
Hmm, that's odd since I have two USB Audio output devices (two pairs of
speakers) plugged in and I can only see the one I plugged in first, and the
built-in hardware isn't available.
>
Next as a non-USB example, try the same with the DigiGram VXPocket PC-Card
>
for PowerBooks. QuickTime can access both the VXPocket and Built-In outputs
>
simultaneously, sending different audio to each.
In this case, the Digigram card has installed it's own sdev. So of course it
will be able to be addressed separately.
>
> The reason why is that there is only one sdev that handles both the built-in
>
> audio and USB audio. It makes up for a lot of the Sound Manager's short
>
> comings at the driver level. To a certain extent, this is what we've done
>
> with the HAL sdev component on X. But there is still only one component on 9
>
> and on X.
>
>
>
This can't always be true (for OS 9 at least), since the USB iMic doesn't
>
take over the Built-In output, and allows both to be used. I know there are
>
other USB devices that *do* take over the built-in output (for example
>
Apple's USB Speakers)... But I think that is by design -- since it doesn't
>
have to be that way (proven by the iMic's output).
I'll buy that (I was testing specifically with speaker devices). It's just
another example of what's bad about OS 9's support for audio.
>
> There is no abstraction point to do this for the output side of the Sound
>
> Manager. The Sound Input Manager does have the necessary abstractions and
>
> does indeed allow you full access to all the devices on the system through
>
> SPBGetIndexedDevice.
>
>
>
Aren't the QT calls FindNextComponent, GetComponentInfo, and
>
MediaSetSoundOutputComponent the necessary abstractions? They abstract the
>
output hardware just the same, or am I missing something here?
Yeah, what if you unplug a device while you are in the middle of the
discovery loop? You'd end up with an invalid component and dangling pointers
all over the place.
Nit to pick: the Component Manager is part of CoreServices not QuickTime.
The point you are missing is that there is not a reasonable and reliable way
to make the list of available sdevs match the list of devices in the HAL. I
know because I tried. It didn't work out and ended up with all sorts of
interesting crashes. There are all sorts of little architectural details in
the Sound Manager that make this sort of thing very hard to pull off in a
reliable fashion.
I suppose the short answer to this is that if this were at all possible to
do in a fashion that was robust, it would have been done by now.
--
Jeff Moore
Core Audio
Apple