Re: Hardware Plugins
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