• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: HAL user-land audio driver
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HAL user-land audio driver


  • Subject: Re: HAL user-land audio driver
  • From: Jeff Moore <email@hidden>
  • Date: Thu, 20 Mar 2008 11:26:00 -0700


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.


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.



--

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
  • Follow-Ups:
    • Re: HAL user-land audio driver
      • From: "Mikael Hakman" <email@hidden>
References: 
 >HAL user-land audio driver (From: "Mikael Hakman" <email@hidden>)

  • Prev by Date: Re: offline effect failing auval on render test
  • Next by Date: Re: Enable system volume when driver doesn't
  • Previous by thread: HAL user-land audio driver
  • Next by thread: Re: HAL user-land audio driver
  • Index(es):
    • Date
    • Thread