Re: audioconverter and unpacked source
Re: audioconverter and unpacked source
- Subject: Re: audioconverter and unpacked source
- From: Doug Wyatt <email@hidden>
- Date: Mon, 4 Dec 2006 11:33:40 -0800
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?
_______________________________________________
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