Re: Out-of-range samples
Re: Out-of-range samples
- Subject: Re: Out-of-range samples
- From: Jeff Moore <email@hidden>
- Date: Mon, 30 Jan 2006 10:39:19 -0800
On Jan 30, 2006, at 8:47 AM, B.J. Buchalter wrote:
on 1/30/06 10:01 AM, Erik Rose at email@hidden wrote:
It is odd that the driver for the built-in mic is producing such
high sample values. The driver must have a built-in gain control
that is set very high. You should be able to access the gain
control in AMS.
Unless I have a profoundly mistaken view of the universe, CoreAudio
should stay within its amplitude limits no matter how high the gain
is cranked up. If the gain is too high, it should, at worst, clip,
yielding ones and negative ones. I take it you haven't encountered
these out-of-range values?
For some devices/drivers the gain control exported to CoreAudio
(and AMS) is
a digital domain gain control in the driver (not an analog gain
control
before the conversion step). AFAIK, there is no way to discover
which type
it is with the current API (although I am sure Jeff will correct me
if I am
wrong about that).
That is correct.
For the built-in audio (at least on current machines) the input
gain is a
digital domain control that applies a floating point scalar to the
converted
samples. As a result, the samples coming from the hardware are
clipped to
+/- 1, but the samples coming from the driver will have a clipping
point
that is scaled by the gain that you set (so if the gain is > 0dB, the
samples you receive from the driver can have a magnitude > +/-1).
I can't remember whether the input volume control on the built-in
hardware is before or after the ADCs, but presuming it is after,
you're analysis is correct.
That said, while the nominal range of a floating point sample is
defined to be between -1 and 1, there are never any guarantees that
any stage in the pipeline involved will not produce out-of-range
samples. Hardware can do it. Software can do it. It's a natural
consequence of math and for a most cases is not harmful in the least
(exceptions: NaN and +/-inf, a calculation that results in those is a
bug, generally speaking).
If it is important to your processing that all the samples be in
range, it is best to ensure that by clipping the buffer yourself
before using it.
--
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