will it be faster, when you read for example numSamplesPerFrame compared to use just a big buffer like 8192, will there be significant changes in speed?
Right, I was always under the impression that the call to extraction only allowed for one quicktime / mp3 frame at a time. The API says otherwise and indeed this works .
My code looks like this at the moment:
[code]
int origSize = bufferList->mBuffers[0].mDataByteSize;
int framesToDo = jmin (numSamples, (int)(origSize / inputStreamDesc.mBytesPerFrame));
bufferList->mBuffers[0].mDataByteSize = inputStreamDesc.mBytesPerFrame * framesToDo;
UInt32 outFlags = 0;
UInt32 actualNumFrames = framesToDo;
OSStatus err = MovieAudioExtractionFillBuffer (extractor, &actualNumFrames, bufferList, &outFlags);
if (err != noErr)
{
ok = false;
break;
}
bufferList->mBuffers[0].mDataByteSize = origSize;[/code]
This way the buffer doesn’t get “smaller” but allows for extraction of maximum number of samples possible in the buffer. This size can be quite big (256 KB in my case), but I get the impression that using a bigger buffer doesn’t speed it up a whole lot. But, I’m using a system of overlapping audio buffers to make reverse playback of mp3’s possible, so I’m skipping around in the file quite a lot when a new buffer is being read from file. This might slow things down a bit, but I’m not bothered by any fade-in phenomena. The buffer’s play without any glitches.
try a 50Hz sine