Re: Audible glitches when changing output format flags from floats to ints
Re: Audible glitches when changing output format flags from floats to ints
- Subject: Re: Audible glitches when changing output format flags from floats to ints
- From: William Stewart <email@hidden>
- Date: Tue, 13 Nov 2007 15:08:47 -0800
On Nov 13, 2007, at 11:15 AM, Mattias Arrelid wrote:
Hi everyone,
We've successfully been converting MP3 data using these converter
properties (firstHeader is a struct, containing the properties of
the first header of the MP3 file):
static const bool producesFloat = true;
static const uint32 outputFormatFlags = (producesFloat ?
kLinearPCMFormatFlagIsFloat|kLinearPCMFormatFlagIsPacked :
kLinearPCMFormatFlagIsSignedInteger);
// Set input (compressed) format parameters
inputFormat.mSampleRate = (float)firstHeader.sampleRate;
inputFormat.mFormatID = kAudioFormatMPEGLayer3;
inputFormat.mFormatFlags = 0;
inputFormat.mBytesPerPacket = 0;
inputFormat.mFramesPerPacket = 1152;
inputFormat.mBytesPerFrame = 0;
inputFormat.mChannelsPerFrame = firstHeader.stereo ? 2 : 1;
inputFormat.mBitsPerChannel = 0;
inputFormat.mReserved = 0;
// Set output (uncompressed) format parameters
outputFormat.mSampleRate = (float)firstHeader.sampleRate;
outputFormat.mFormatID = kAudioFormatLinearPCM;
outputFormat.mFormatFlags = outputFormatFlags;
outputFormat.mBytesPerPacket = (producesFloat ? 4 : 2) *
(firstHeader.stereo ? 2 : 1);
outputFormat.mFramesPerPacket = 1;
outputFormat.mBytesPerFrame = outputFormat.mBytesPerPacket;
outputFormat.mChannelsPerFrame = firstHeader.stereo ? 2 : 1;
outputFormat.mBitsPerChannel = 16 * (producesFloat ? 2 : 1);
-> per channel, so should just be 16
(but I don't know that that would make a difference).
outputFormat.mReserved = 0;
The output device uses "outputFormat" as well;
// Set the input and output stream format
err = AudioUnitSetProperty(outputUnit,
kAudioUnitProperty_StreamFormat,
kAudioUnitScope_Input,
0,
&outputFormat,
size);
Now, when changing to signed ints, by setting the "producesFloat" to
"false", we suddenly hear audible artifacts in the output stream;
it's just like if someone took the audiostream, took a scissor, cut
off some pieces (very short ones, ~1/8 second), and then taped the
stream together again. Since we're feeding the converter data using
AudioConverterFillComplexBuffer(...), I added some debugging output
in the callback; it runs out of data very often, and hence has to
return a non-zero error code - this is the only visible difference
in the debug logs when switching format flags from ints to floats...
but is this of any help? The device shouldn't consume data faster
when its format flags are specified to produce ints instead of
floats, or am I missing something fundamental here?
Any advice is more than welcome.
Thanks in advance
Mattias
_______________________________________________
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
_______________________________________________
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