Re: User-land CoreAudio driver and Leopard
Re: User-land CoreAudio driver and Leopard
- Subject: Re: User-land CoreAudio driver and Leopard
- From: Stéphane Letz <email@hidden>
- Date: Tue, 13 Nov 2007 09:38:21 +0100
Coreaudiod's purpose in life prior to Leopard was to save/restore
device settings at shutdown/boot and to provide a home for the System
Sound Server, which is what plays interface sounds, alert sounds, and
what not (see <AudioToolbox/AudioServices.h> for more info).
In Leopard, we expanded some of cordaudiod's duties. First and
foremost, we created the new AudioHardwareServices API (found in
<AudioToolbox/AudioServices.h>). This API allows you to query audio
hardware without having to incur the overhead of the HAL. For example,
you can enumerate all the devices, check their physical formats, and
change the volume with this API without directly calling into the HAL.
This API is implemented by having the client API calls message
coreaudiod for the requested information. As part of this, the
management of the default device setting for each user has also passed
to coreaudiod.
Where is coreaudiod launched ?
In order to make this work for all audio devices, regardless of what
driver mechanism they use, we had to change coreaudiod so that it
would now load user-land drivers in addition to supporting the
IOAudio-
based drivers. The environment that coreaudiod operates in is outside
of any user's login session or any user's bootstrap session.
Please feel free to ask questions here. I'm happy to help you use that
code.
Having our driver (called JackRouter) as default in/out now works: the
"CanBeDefaultDevice" method had to be implemented.
- If we choose our user-land drive as the default input/output driver,
then stopping the server has some weird consequences: since the server
is no more available, then the JackRouter driver appears as
"unavailable" for applications (the wanted behaviour), but AMS or
HALLAb still trying to access JackRouter then displays empty items in
their device list, and the list of items is somewhat incorrect. In
some sense our "hardware" has disappeared, but if seems this "event"
is not correctly reflected in the system.... what should be done to
improve that?
- we started to use the SDK by hacking the SHP_XXX classes. Is this
the recommended way?
- the "SampleHardwarePluin" given as an example is quite complex with
the use of this mIOThread. We don't need to have a thread in our case
since our "hardware (the server) already provides a callback mechanism
to drive audio in/out. But since this mIOThread objet is used
everywhere it seems that just removing it has some bad consequences...
What is the recommended way?
Will a driver developed with the SDK still load under Tiger or is it
a Leopard only thing?
Yes. It should work OK on Tiger. File bugs about anything that
doesn't. It's possible I missed some bit of compatibility support.
It works if compiled with 10.4 support.
I compiled the SampleHardwarePlugIn, put it in /Library/Audio/Plug-
Ins/HAL/. The driver is correctly seen by HALLab and AMS, but it
seems it can not be used as the default input/output device (in
AMS). What has to be done for that?
The HAL doesn't dynamically load plug-ins, so you have to re-launch a
process for it to notice new ones. My guess is that you need to kill
coreaudiod so that it relaunches and loads the new plug-in or just
reboot.
It seems that Aggregate devices is still buggy in 10.5. Sometimes when
accessing/changing devices settings, (sample rate ...), the Aggregate
devices completely disappear form the device lists, and we have to
toggle setting until it appear again.
Stephane Letz
_______________________________________________
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