Apple

Since I don't provide the encoded data to this function, and instead have to provide it via the MyConverterCallback function, I basically store off the encoded data in my _converterSettings object, and then use the callback to simply hand back that data. This is prior to the AudioConverterFillComplexBuffer() call, of course:

_converterSettings.sourceData = (void*) data;

_converterSettings.sourceNumBytes = numBytes;

_converterSettings.sourceNumPackets = numPackets;

_converterSettings.sourcePacketDescriptions = packetDescriptions;

So, in the callback, I can just return that info that I saved off:

OSStatus MyConverterCallback(AudioConverterRef inAudioConverter,

UInt32 *ioDataPacketCount,

AudioBufferList *ioData,

AudioStreamPacketDescription **outDataPacketDescription,

void *inUserData) {

MyAudioConverterSettings *userDataConverterSettings = (MyAudioConverterSettings*) inUserData;

ioData->mBuffers[0].mData = userDataConverterSettings->sourceData;

ioData->mBuffers[0].mNumberChannels = userDataConverterSettings->sourceFormat.mChannelsPerFrame;
ioData->mBuffers[0].mDataByteSize = userDataConverterSettings->sourceNumBytes;

*ioDataPacketCount = userDataConverterSettings->sourceNumPackets;

if (outDataPacketDescription) {

*outDataPacketDescription = userDataConverterSettings->sourcePacketDescriptions;

}

But here's the thing. It's possible that the input data, when decoded, could be larger than the convertedData output buffer that receives the result of the AudioConverterFillComplexBuffer() call. In my own testing, when I have a fairly small (64 KB) convertedData output buffer, I get lots of glitching as packets are apparently skipped, but with a big buffer (512 KB), it sounds great.

However, there's no apparent limit on how much data the callback can provide. If the using a smaller convertedData buffer means I only want to return enough input packets to fill the output buffer, I could buffer the rest of my input packets for the next callback (perhaps requiring some rewriting of offsets in the packet descriptions array, ugh). But the ioDataPacketCount only sets a minimum number of packets that must be returned, not a maximum that won't overflow the receiving buffer.

Is the converter doing its own buffering of extra input if it gets more than it needs (maybe just skipping the next callback), or just dropping it on the floor?

If the converter has an upper limit to how much data it can take at once, is there a strategy for signaling to my callback how much data it can return without overflowing AudioConverterFillComplexBuffer()'s output buffer? Perhaps get the kAudioConverterPropertyCalculateInputBufferSize property prior to the converter call and only return that much data from the callback? Or is there away to allocate an appropriately-sized convertedData output buffer on each call, based on how much input the converter will be receiving from the callback?

Thanks in advance…

--Chris