Re: HAL user-land audio driver
Re: HAL user-land audio driver
- Subject: Re: HAL user-land audio driver
- From: "Mikael Hakman" <email@hidden>
- Date: Thu, 20 Mar 2008 21:36:16 +0100
- Organization: Datakonsulten AB
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? 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?
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.
TIA
_______________________________________________
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