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: "Mikael Hakman" <email@hidden>
- Date: Tue, 11 Mar 2008 15:36:30 +0100
- Organization: Datakonsulten AB
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.
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, how
does HAL know about this object, where does HAL find it, how it is
instantiated? 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.
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.
TIA
_______________________________________________
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