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: Mon, 10 Mar 2008 15:43:32 -0700
On Mar 10, 2008, at 2:58 PM, Mikael Hakman wrote:
On March 10, 2008 10:11 PM, Jeff Moore wrote:
On Mar 10, 2008, at 8:54 AM, Mikael Hakman wrote:
I need to control volume level when using standard system media
applications and (external) audio interfaces that don't enable OS
X master system volume control. I need to enable system volume so
that the user could use Apple IR remote to control it. I don't
know what is available and/or possible to accomplish so I would
like you to comment on conceivable approaches.
There is no direct way to do this.
One way to do it would be a kind of virtual audio device driver.
There are a few hack-ish ways to do it, of which this is one.
Many thanks Jeff for taking the time to answer. What would be the
other hack-ish ways to do it?
One way would be to do what you are proposing, but do it as a kernel
driver. This method would be even harder to pull off, IMHO.
Another way would be to use the dyld library interposing mechanism and
supply your own implementation of the HAL. Last I checked (which was a
while ago, so take this with a grain of salt) this was how Rogue
Amoeba's Audio Hijack program works. I've never tried doing anything
in this style, but I can't imagine that it is particularly easy. The
down side is that you have to have some control over each process you
want to interpose for which mostly means you have to control the
fork() or exec() that launches the applications.
Still another way is to build a complex client/server system like Jack.
Such a driver would take name of real audio interface as a
parameter. The driver would be chosen as default audio output by
the user. It would present itself to the operating system in such
a way that the system volume would be enabled. It would intercept
the outgoing audio stream(s), rescale the volume, and pass
modified stream(s) to the real device driver.
I don't know whether it is possible to implement such driver at
all and what technology (API) would you use. If it is then
perhaps there is such driver already available? If it isn't
available then I would appreciate pointers to relevant API and
example documents.
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.
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.
Yes, I understand this, which is the reason I was hoping that
someone did already such a driver, commercial or not.
To my knowledge the closest things to what you are looking for that
exist now are Audio Hijack and Jack, neither of which really take the
approach you are thinking about (well, Jack sort of does but it does a
whole lot more too).
I only need to control the volume. I hope the other properties could
be controlled in MIDI control panel on the real driver. Would this
make the amount of work less?
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.
The best solution would of course be a virtual system volume control
implemented in the OS, to be used at user's or programmer's
discretion when dealing with interfaces not exposing this to OS. But
this may be to hope for too much.
Well, the simpler way to look at it is that the system has no such
support currently. So whether you hope for it in the future or
whatever, it doesn't help you out very much today.
I understand that doing volume control in digital domain is not
always advisable (you loose some dynamic range and add some
quantization distortion). In our environment, because of remote
control requirement, the only alternative is to put an analogue
remote controlled preamp in otherwise pure, all the way to digital
studio monitors, digital path. This in turn means first a D/A
conversion and then A/D again, both of which aren't needed
otherwise. So I figure out that using 24 bits audio, there would be
a plenty headroom to attenuate from and the results using digital
volume control would be better than the 2 unnecessary conversions.
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.
--
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