Apple

christopher skogen

gizmolabs, inc.

office: (404) 687-0008

fax: (404) 687-1010

On Dec 4, 2006, at 2:33 PM, Doug Wyatt wrote:

In attempt to be somewhat exhaustive, AudioConverter on Tiger and previous tries to support these low-aligned formats. This may be the first time anyone's tried to use low-aligned conversions, because I discovered during the Intel port that they never quite worked properly. Rather than fix something that was never bug-free, which no one appeared to be using, and was complicating the "normal" code paths, on Leopard you can't create such a converter.

But:
Another way of looking at your source stream is as interleaved stereo 16-bit where you want to ignore one of the channels.

Doug

On Nov 30, 2006, at 8:49 PM, Christopher Skogen wrote:

hi all,

i've been using the audioconverter for a while now and have had no trouble with it til now. i'm trying to convert from an unpacked integer format to 32-bit float.

here's the source asbd. i'm trying to describe a 16 bit signed integer sample, low aligned, stored in a 4 byte signed integer.

fmt.mSampleRate = 44100;
fmt.mFramesPerPacket = 1;
fmt.mChannelsPerFrame = 1;
fmt.mBitsPerChannel = 16;
fmt.mBytesPerFrame = 4;
fmt.mBytesPerPacket = 4;
fmt.mFormatID = audioFormatLinearPCM;
fmt.mFormatFlags = kAudioFormatFlagsNativeEndian | kAudioFormatFlagIsSignedInteger;
fmt.mReserved = 0;

here's the dest asbd. i'm trying to describe a 32 bit float sample.

fmt.mSampleRate = 44100;
fmt.mFramesPerPacket = 1;
fmt.mChannelsPerFrame = 1;
fmt.mBitsPerChannel = 32;
fmt.mBytesPerFrame = 4;
fmt.mBytesPerPacket = 4;
fmt.mFormatID = audioFormatLinearPCM;
fmt.mFormatFlags = kAudioFormatFlagsNativeFloatPacked;
fmt.mReserved = 0;

the converter is created and runs, but the problem is in the float values created. it works fine on a ppc mac, but on my intel mac i get a strange result.

my first sample in is -32768 or 0x0080FFFF. after conversion, i should get -1 or 0x000080BF. instead, on the intel mac i get 0x000080B7.

my understanding of unpacked, low-aligned leads me to believe that the FFFF of the input sample would be ignored by the audio converter. i then tried modifying all four bytes of the input and found that any change to the four input bytes was changing the output of the converter. what am i missing? or... how am i misunderstanding this?