Re: User-land CoreAudio driver and Leopard
Re: User-land CoreAudio driver and Leopard
- Subject: Re: User-land CoreAudio driver and Leopard
- From: Jeff Moore <email@hidden>
- Date: Tue, 13 Nov 2007 12:22:11 -0800
On Nov 13, 2007, at 12:38 AM, Stéphane Letz wrote:
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 ?
Coreaudiod is an on-demand launchd daemon. It's plist can be found
here: /System/Library/LaunchDaemons/com.apple.audio.coreaudiod.plist
It turns out that the first client of coreaudiod is LoginWindow, so it
launches fairly soon after booting.
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.
Excellent.
- 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?
You need to have you plug-in code in client processes watching for
coreaudiod to disappear. This can be done a variety of ways, but the
easiest is to have your plug-in in the server create a mach port that
clients can sign up for port death notifications on.
- we started to use the SDK by hacking the SHP_XXX classes. Is this
the recommended way?
It is certainly a way to do it. It's probably the best way to learn
about what's going on and how the classes fit together. Ultimately,
this SDK is a lot like what AUBase provides to the AudioUnit world.
So, you should feel free to approach it as best suits your work-flow.
- 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?
To remove it and replace it with a more suitable mechanism. This will
likely involve creating your own subclass of HP_Device directly and
implementing the IO methods to talk to your server. You will probably
also want to tweak how the IOProc buffers are handled if your IO
mechanism allocates the buffers you want to pass to an IOProc. This is
done by configuring the HP_IOProc instance, mIOProcList.
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.
Thanks for the confirmation.
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.
Please file bugs about things like this. With aggregate device bugs,
it helps immensely to include information about exactly what devices
are involved and how the aggregates are being configured.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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