Re: Enable system volume when driver doesn't
Re: Enable system volume when driver doesn't
- Subject: Re: Enable system volume when driver doesn't
- From: Jeff Moore <email@hidden>
- Date: Tue, 11 Mar 2008 12:29:32 -0700
On Mar 11, 2008, at 7:36 AM, Mikael Hakman wrote:
On March 10, 2008 11:43 PM, Jeff Moore wrote:
You'd be dealing with the HAL's user-land driver API. The sample
code for such a driver is in /Developer/Examples/CoreAudio/HAL/
SampleHardwarePlugIn.
No. You still have to implement all the HAL semantics. There isn't
anything you can do to get rid of that work in a user-land driver.
Fortunately, our SDK has a C++ class library that can help you out
with this. You can see it in the sample project I mentioned.
I looked into the sample. I have no problems with technology used
there, I know this from other programming areas, but I wish there
would be a description in the form of guide or tutorial of HAL user-
land driver implementation describing the semantics, functions and
roles of the various pieces in a sample project. You know: "In order
to implement a HAL user-land driver you have to implement the
following N software pieces. Piece number 1 should implement
following M calls. Call number 1 in piece number 1 should do this
and return that.". Unfortunately I'm unable to find such a
description. Perhaps I don't know where to look.
You didn't find it because the really isn't anything like that for the
various flavors of HAL plug-in there are. This forum is a fine place
to pose questions. The easiest way to understand how things work is to
just see how they work for other devices using HALLab. Plus, there is
a lot of good info in the various HAL headers.
That said, what you propose is easier said than done. There are a
lot of behaviors and semantics you'd have to implement to make
this as transparent as you would like. Basically, you have to
implement a repeater for all the properties and what not. The
sample code won't really help you with this, but will show you the
basics of writing such a driver.
You are quite right here, even more right without guidance on the
very principles of such an implementation available. Here are some
simple questions. What is the very first software object
instantiated by HAL
That would be your plug-in object. Any further objects need to be
instantiated by your plug-in using the functions defined in <CoreAudio/
AudioHardwarePlugIn.h>.
, how does HAL know about this object
It created it itself as part of the plug-in loading process.
, where does HAL find it
HAL plug-ins live in /Library/Audio/Plug-Ins/HAL. The HAL scans this
directory when it is initialized and loads all the plug-ins it finds.
, how it is instantiated?
Using standard CFPlugIn calls.
What externally visible calls and interfaces should this object
implement? What is the meaning and semantics of the calls,
interfaces, and objects implemented, provided or returned by this
object? And then, recursively, the same questions for every object
and/or interface. Given such a description, an implementation needs
not to be that overwhelming as it may appear, IMHO.
An object, in the sense the HAL's API uses the term, is basically just
collection of properties. The various properties implemented by the
various classes of objects are all described in the HAL's headers.
Are you writing the driver for this device, too? If so, there are
easier ways to integrate software volume with your driver than
writing a whole new user-land driver.
Unfortunately (or fortunately depending on viewpoint) I don't. We
are rather system integrators than software or hardware vendors. We
do write application and system software when required, possible,
and feasible in our projects. The audio hardware interfaces I'm
talking here about are from very well known vendors including but
not limited to such devices as RME Fireface , Lynx Aurora (with FW
card), Apogee Rosetta (with FW card) etc. We are in a process of
building a high quality multichannel audio/video output only path
starting with a computer and ending with digital audio and video
monitors. The system will be used as a model for other setups and
installations. Remote control of volume and other pertinent
properties is required in target environments. I could however use
information on these easier ways to integrate volume control with
existing drivers as a hint (or an argument) when discussing the
subject with audio hardware vendors.
I don't mean to poke holes, but I can't imagine an audio professional
who would buy the gear you list would want to mangle their audio with
a digital volume control. There are reasons why these high end
hardware developers didn't build volume controls into their gear. You
are taking on a huge job with a steep investment in implementation and
maintenance just to enable the volume slider in the menu bar. I'm not
sure this makes a lot of sense, but we're here to help =)
--
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