Re: Setting the volumes for a headphone data source
Re: Setting the volumes for a headphone data source
- Subject: Re: Setting the volumes for a headphone data source
- From: Brian Willoughby <email@hidden>
- Date: Wed, 13 Mar 2013 19:29:22 -0700
On Mar 13, 2013, at 17:31, Tim Hewett wrote:
Jeff,
On 13 Mar 2013, at 19:00, email@hidden wrote:
On Mar 12, 2013, at 6:15 PM, Tim Hewett <email@hidden> wrote:
Is there a way to set the volumes for a headphone data source
(and even discover that such a data source exists
programmatically) for the headphone port on a Mac's built-in
audio device, when the headphones are not connected?
No.
In the absence of being able to do this I figured a workaround,
which is to set the headphone device volumes quite low and to
compensate the software gains applied to the samples with a
reciprocal value. Then if the user unplugs the headphones and then
uses them again later at least they won't get a loud blast.
Unfortunately this doesn't seem to be so simple, in particular the
built-in device in the MacBook mentioned previously seems to
operate the relationship between scalar and dBs differently to
other devices, at 0.25 it is at about -29dBs whereas others are at
-16dB. All use the same transfer function, i.e. kPow2Over1Curve as
defined in CAVolumeCurve.h. Setting the volume to 0.25 scalar and
multiplying the samples by 4.0 doesn't achieve full volume. Is it
possible to discover what multiplier is applied to the samples in
the device drivers at the point of conversion from float to integer?
Tim,
Two things:
1) Although you can't set the headphone volume when headphones are
not connected, you should be able to register for notifications that
will alert your code when the output type changes. Your code should
be able to save the most recent volume level for each output type,
and restore that whenever the notification reports that the type is
changing. It might be tough, since the notifications will be
asynchronous to the audio callbacks, but if you err on the side of
minimum volume during the transition, then it might work. I cannot
remember the notifications, but look for that and see what's
available. CoreAudio seems to have callback notifications for just
about everything.
2) I totally understand what you're asking about in your last
paragraph, but I think you're looking in slightly the wrong place.
The conversion from float to integer is surely always applied with
what is effectively a unity factor after any volume changes have been
calculated in float. In other words, it's always 2^23 for 24-bit
integer.
I think what's unknown is the mapping from the units for the volume
value to the scaling factor for volume. e.g. -6.0 in dB units would
translate to a scaling factor of 0.5x, and -12 in dB units would
translate to a scaling factor of 0.25x. I'm not sure why you would
expect a literal scaling factor of 0.25 to be the same as -16 dB (or
-29 dB), since it's expected to be -12 dB. In any case, I think
what's happening here is that the units are effectively unknown for
the output device volume, and thus you can't predict the actual
scaling factor without gathering heuristics for each type of output
device. It certainly seems to be the case that literal dB is not the
units being used, otherwise the results would be predictable
regardless of the output type. At the moment, I can't quite figure
out what the transfer function would be for dB ... would it be 2.718
for the natural logarithm? Wouldn't kPow2Over1Curve be at least
slightly different from a dB scale?
Brian Willoughby
Sound Consulting
_______________________________________________
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