Re: Hardware Plugins
Re: Hardware Plugins
- Subject: Re: Hardware Plugins
- From: Jeff Moore <email@hidden>
- Date: Mon, 27 Feb 2006 11:54:51 -0800
On Feb 27, 2006, at 9:06 AM, Stefan Fisk wrote:
Ah, I had just miss-capitalized an entry in my Info.plist.
One thing that I don't really get with the user-land drivers is why
they're loaded into every application that uses core audio.
It's that way because the HAL is loaded into every application. It
follows that plug-ins loaded by the HAL will also be loaded into each
process.
When several applications want to use the same device, how is this
supposed to be handled?
That's entirely up to you. You have the entire arsenal of the OS at
your disposal.
The server that I want to send the audio only accepts one
connection at a time, so mixing has do be done on the client's
side. Would this be possible to implement using only the HAL plug-
in, or do I need to write a separate server that the plug-in
connects to?
You can solve the problem any way you like including only allowing
one app at a time use your driver. Be aware that there are many apps
that don't work too well with devices that don't support access by
multiple processes. Granted, it is the apps' fault that they don't
work properly, but it's really up to you how compatible you want to
make your device. There is a good discussion of this topic in this
lists archives.
That said, the usual way that folks have tackled this problem is to
use a client/server model where the server manages dealing with the
actual IO.
24 feb 2006 kl. 20.35 skrev Jeff Moore:
First, the HAL requires that the plug-in bundle's name end
with .plugin. If that is the case, the HAL creates a CFPlugInRef
for the plug-in bundle. Then it loads all the COM factories for
the type kAudioHardwarePlugInTypeID in the plug-in with a call to
CFPlugInFindFactoriesForPlugInTypeInPlugIn().
From there, the HAL does a lot of the usual COM stuff. It iterates
through the factories, instantiates an IUnknown interface for each
one with call to CFPlugInInstanceCreate(), still using the type
kAudioHardwarePlugInTypeID. The HAL then queries that IUnknown
interface for the various versions of the HAL plug-in interface,
starting with kAudioHardwarePlugInInterface3ID (which is the
current and preferred interface that is defined by
AudioHardwarePlugInInterface).
Once the HAL finds an interface to work with, it releases the
IUnknown interface and initializes the interface it is going to
use by calling the interface's Initialize() method.
On Feb 24, 2006, at 5:27 AM, Stefan Fisk wrote:
BTW, what exactly is required for the HAL to load the driver?
I've placed my plug-in in /Library/Audio/Plug-Ins/Hal, where
iSightAudio.plugin currently resides as well. But even after
rebooting it doesn't seem to load. I've change the owner to
root:admin as well. coreaudiod doesn't seem to log any of its
activities, so I'm not sure if it's trying to load my driver, or
if it fails because I've done something wrong.
24 feb 2006 kl. 02.15 skrev Jeff Moore:
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
--
Jeff Moore
Core Audio
Apple
--
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