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 or 0xff?
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 integer types.
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