User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:220.127.116.11) Gecko/20101027 Thunderbird/3.1.6
Thank you for the help. It makes a lot more sense now. I was initially
confused because I assumed that the range for microphone input would be
much wider than -1 to +1, since that only uses 1 of the 8 whole number
bits, but didn't think about calculations in between that may exceed the
range. It would have been nice if the -1 to +1 range was stated in some
documentation somewhere though...
On 2/8/11 1:24 AM, Brian Willoughby wrote:
Perhaps some additional comments will clarify...
8.24 numbers are interpreted as ranging from -128.000000000000 to
(or +127.99999994039535522460938, depending upon the precision of the
calculator being used).
Thus, the whole portion ranges from -128 to +127, and the fractional
portion allows for 16777216 steps from one whole number to the next.
I suppose it's obvious that since the format is binary, this means not
every decimal value is precisely possible.
The convention in iOS/CoreAudio is to treat -1.000000000000 to
+0.999969482421875 as non-clipped values that do not exceed Full Scale
for the 16-bit analog audio converters. You can exceed this range
temporarily in a graph of AudioUnits, but you really should tame the
amplitude before sending any final samples to the speaker.
On Feb 8, 2011, at 01:08, Brian Willoughby wrote:
On Feb 8, 2011, at 00:39, David Zhang wrote:
Sorry if this is a silly question as I am fairly new to this. I am
looking at the aurioTouch code, specifically the PerformThru
function where AudioUnitRender gets called. Here, the
AudioBufferList* ioData has the sound data in 8.24 fixed-point
format. My novice understanding of this format is that the most
significant 8 bits are the integer portion with range [0, 255] and
the next 24 bits are the fractional part with range [0, 1).
So what is in the most significant 8 bits and why is it always 0x00
Almost all computer binary numbers are two-complement. That's why -1
is 0xffff in 16-bit signed integer, not 0x8001. I believe that iOS
8.24 is technically Q7.24 format, where 1 bit is the sign, 7 bits are
the whole number part and 24 bits are the fractional part, in order
from highest bit to least significant bit. It's not an official
convention, but I like to say 'whole' portion rather than 'integer'
portion, because the latter can be confused with the standard C
Your description is a little odd, because you say the 8 bits range
[0, 255] and the 24 bits range [0, 1), but the latter would imply
only one bit. Maybe it would be more accurate to say that the 24
fractional bits have the range [0.00000000, 1.00000000) ... It's
certainly true that the 8 bit range is [-128, 128) or [-128, 127].
So, what you're seeing when the most significant byte only holds 0x00
or 0xff is that all of the data happens to be < 1.0000000 in absolute
value. But there is no guarantee that this will always be true.
AudioUnits in iOS will accept values larger than +/-1.0, for the most
part. This means the aurioTouch code will perform strangely when the
audio is loud enough to clip, with the distinction that the audio
won't actually be clipped until it is converted to 16-bit signed
integer for the audio hardware.
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