• 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: Hardware Plugins
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hardware Plugins


  • Subject: Re: Hardware Plugins
  • From: Jeff Moore <email@hidden>
  • Date: Thu, 23 Feb 2006 17:15:27 -0800

Before I answer your questions, I'll plug the AudioUnits, AUNetSend and AUNetReceive. They are Audio Units that you can use to bus audio from one machine to another over the network. They may or may not be suitable for what you have in mind.

On Feb 23, 2006, at 1:27 PM, Stefan Fisk wrote:

Although it took me far longer than it should have, I finally remembered how plugins work :)

That'll certainly help =)

But when it comes to implementing a driver as user-land instead of in-kernel, when exactly would you want to choose user-land?

The choice depends on the nature of the hardware involved. Some hardware just doesn't lend itself well to being in the kernel. Sometimes, a user-land driver is used to connect to a proprietary driver model.


What I'm trying to do is a network audio device, where the sound is sent compressed to another machine. The reason for wanting to do it in user-land is that i can use audio units for compression, openssl for encryption etc.

All fine reasons to do things in user-land.

My first idea was to use the AudioReflectorDriver and then just hook that up to a HAL audio input unit. But Then I (from what I could tell) wouldn't be able to tell the audio system how much latency there was.

There are IOAudioEngine methods called setInputSampleLatency() and setOutputSampleLatency() for doing that. The reflector has no hardware latency so the default value of 0 is correct, so the code doesn't call these methods.


Also I wanted to be able to add audio devices dynamically as they became available on the network, but I can not figure out how to do this from a kernel driver.

You just instantiate more of your IOAudioEngine subclasses.

Still, if you really think I should go the IOAudio-based route, I'll probably try that first.

Given that a lot of the network code you'll want to use is out in user-land anyway, I'd say that you have a good reason to be out there.s


23 feb 2006 kl. 20.48 skrev Jeff Moore:


On Feb 23, 2006, at 1:18 AM, Stefan Fisk wrote:

I'm interested in writing a hardware plugin for the HAL, but I can't find any complete documentation or example on how it's supposed to be done.

That's because there is none. User-land drivers are there as a last resort for devices that don't make any sense in the kernel as an IOAudio-based driver. It has been my experience that there are very few situations where this is the case. As such, there are very few of these drivers out there.


Writing a user-land driver is not easy as the plug-in is on it's own for implementing pretty much all of the semantics and behaviors of the HAL's API. As such, it is much easier to write an IOAudio-based driver if it is at all possible. I would very much encourage you to look at IOAudio first.

Reading the header docs over and over again isn't really helping me, since i still can't understand how the plugin would actually be implemented. Primarily, I don't see how AudioHardwarePlugIn.h and AudioHardware.h relate to one another.

The plug-in is a CFPlugIn-based API. The HAL loads the plug-ins and uses them to provide the API support. The plug-in methods correspond exactly with the API calls they resemble in AudioHardware.h. The API calls in AudioHardwarePlugIn.h are there for the plug-in to communicate with the HAL for the purposes of object management and for sending property change notifications.


--

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
References: 
 >Hardware Plugins (From: Stefan Fisk <email@hidden>)
 >Re: Hardware Plugins (From: Jeff Moore <email@hidden>)

  • Prev by Date: Recognizing iSight as audio input device?
  • Next by Date: Re: Recognizing iSight as audio input device?
  • Previous by thread: Re: Hardware Plugins
  • Next by thread: Re: Hardware Plugins
  • Index(es):
    • Date
    • Thread