Re: HAL user-land audio driver
Re: HAL user-land audio driver
- Subject: Re: HAL user-land audio driver
- From: Jeff Moore <email@hidden>
- Date: Wed, 2 Apr 2008 12:04:11 -0700
On Apr 2, 2008, at 4:13 AM, Mikael Hakman wrote:
Many thanks Jeff! I can confirm that the entity which handles the
volume up/down bumping divides 0.0 - 1.0 range into 16 steps (number
of dots shown on volume popup when using remote control). It then
increases/decreases the volume level by one step for each press on
+/- button on remote control. If actual device dB range is e.g. -96
- 0.0 (16 bit range) and scalar values map linearly to dB then each
step corresponds to 6 dB, i.e. 1 bit - a device using 32 bit integer
format internally could simply bit-shift the values.
I wouldn't count on that always being true. I'd treat it as a happy
coincidence for now but be prepared to see things change in the future
=)
You mentioned before that there are routines in Core Audio that can
provide various mappings from scalar value to dB. What are their
names?
In the PublicUtility directory of our SDK is a C++ class called
CAVolumeCurve. It is basically the guts of a volume control and is
what I use to handle my mapping between the various domains the volume
control value lives in. You can see it in action in the
SHP_LevelControl class in the SampleHardwarePlugIn sample code.
I would need a mapping that better corresponds to human perception
of loudness than linear dB mapping does. My own experience tells me
that the steps at low volume should be larger and the steps at high
volume should be smaller. What mapping is used by built-in analog
audio output? Its step at low end is almost twice that of at high end.
What you are perceiving is actually the result of using the X^2 curve
in CAVolumeCurve. This is actually the default we use in the HAL for
IOAudio devices.
BTW, HALLab has a neat window called the "Volume Curve" window that
can show the effect of the various volume curves supported by
CAVolumeCurve.
Is it possible to request larger number of steps than 16 to be used
by remote control of volume?
You can file a bug and ask, but otherwise I don't know of any way to
do it programmatically.
I'm returning to the subject of multiple client processes with a new
instance of plug-in each. Is AudioObjectID returned by
AudioObjectCreate valid only within a process, or could the other
processes (and instances) use it without another call to
AudioObjectCreate?
AudioObjectIDs are only valid in the process they are issued in. They
cannot be passed between processes.
Furthermore, should every process (and instance) call
AudioObjectPublishedAndDied for all of objects (created by the
above), or is it enough if master process does it once?
AudioObjectPublishedAndDied has to be called in each process to
publish/unpublish AudioObjects to that process.
--
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