Re: HAL user-land audio driver
Re: HAL user-land audio driver
- Subject: Re: HAL user-land audio driver
- From: Jeff Moore <email@hidden>
- Date: Thu, 20 Mar 2008 14:11:13 -0700
On Mar 20, 2008, at 1:36 PM, Mikael Hakman wrote:
On March 20, 2008 7:26 PM, Jeff Moore wrote:
On Mar 20, 2008, at 6:44 AM, Mikael Hakman wrote:
I've been experimenting with ways to implement HAL user-land audio
driver, including the example driver Jeff pointed me to. By
inserting printf statements in the code I can follow what happens
during system boot in console log. I can also see the same in a
test application console. A strange thing is, that the driver
code accessed at system boot lags one version behind the code
that is accessed when using a test app.
I make a change to the driver code and build it. Then I move old
driver from /Library/Audio/PlugIns/HAL to the Trash, and copy the
new version to that directory. Then I reboot the system. In
system console I can see that the old version was still used
during the boot. Then I run a test app, it enlists available
drivers using AudioHardware calls. In application's console I can
see that now the new version is used. If I then remove the new
driver from /Library/ Audio/PlugIns/HAL and copy it again, then
after a reboot the new version is used by the system at boot
time. It looks as if the system cached the old code somewhere and
used it at boot time. I can see what version is used because the
first thing my driver does, in its factory function, is to printf
its version number which I increment for each build.
Is there any way to get rid of this lagging?
That's a pretty weird situation. I've never run into anything like
that. The HAL uses the standard CFPlugIn calls to load plug-ins.
It isn't smart enough to do any sort of caching.
Can it be that the old plugin version is still in the Trash when
system boots?
The HAL only loads plug-ins from the one directory, so just moving the
plug-in out of that directory should be sufficient to prevent the HAL
from loading it again.
Here's an experiment you can do to verify this for yourself:
0) Plug in an iSight.
1) Launch HALLab and note that the iSight is listed in the device list.
2) Quit HALLab and move the iSight plug-in out of /Library/Audio/Plug-
Ins/HAL
3) Launch HALLab and note that the iSight is not listed in the device
list
4) Quit HALLab and put the iSight plug-in back into /Library/Audio/
Plug-Ins/HAL
5) Launch HALLab and note that the iSight is back in the device list.
I have difficult to permanently delete old version because it is
being used by HAL. How do you do those things? How to replace a
plugin while it is running, or how to stop it from running?
There are lots of processes that will load your plug-in. Basically,
every one that initializes the HAL. So you need to be sure to
terminate all those processes before you can fully delete your plug-
in. The tricky ones are coreaudiod and LoginWindow. They are always
going to get auto-launched, so it's hard to get the system in a state
where they aren't running.
I'm pretty lazy, so I usually do this by replacing the plug-in I'm
working on with the new one and rebooting. This sidesteps the issues
with making sure coreaudiod and LoginWindow are not running when the
replacement happens.
You can also do this in single user mode.
Another issue, which I write here for informative purpose only,
is the following. If there is a segmentation violation in the
driver code used at boot time then OS X will not start at all.
This is a little surprising because this is user-land driver, not
IOKit driver. At boot I get the usual grey screen, then the light
blue screen but login panel never appears. A blank light blue
screen is shown without any other thing happening. I have to turn
off and boot in single user mode and remove the faulty plug-in
from /Library/ Audio/PlugIns/HAL. Then the system is able to boot
normally again.
What is happening is that you are causing coreaudiod to crash.
Every instance of the HAL talks to coreaudiod, including the
instance in LoginWindow. The crash is probably causing the code in
the HAL to block while waiting for coreaudiod to show up. It's
probably worth filing a bug about this. There are probably things
we can do to mitigate the side effects of a crashy coreaudiod.
I'll try to fill a report about this - a fix would easy the work in
these cases. But it isn't big issue for me, as long as I know how to
get the system back (which I do now). My code core dumping is my
problem, so to speak. The first issue above is much more serious.
Cool. I'd still appreciate it if you could file a bug so that we don't
forget about this issue. Thanks!
--
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