Specifying number of frames to process in audiounit render callback on iOS

Question

I setup the audio unit render callback:

    AURenderCallbackStruct input;
    input.inputProc = RenderAudioBuffer;
    input.inputProcRefCon = self;
    err = AudioUnitSetProperty(audioPlaybackUnit,
                               kAudioUnitProperty_SetRenderCallback,
                               kAudioUnitScope_Input,
                               0,
                               &input,
                               sizeof(input));

Here is the callback method:

OSStatus RenderAudioBuffer( void                         *inRefCon,
                                   AudioUnitRenderActionFlags   *ioActionFlags,
                                   const AudioTimeStamp         *inTimeStamp,
                                   UInt32                       inBusNumber,
                                   UInt32                       inNumberFrames,
                                   AudioBufferList              *ioData)

{
}

In the callback method, inNumberFrames is always 1024. How do I change it? I have more than 1024 frames at a time instant to render (64K).

Answer 1

You can't specify an exact buffersize in iOS, but you can request one similar to a given size. The code looks something like this:

Float32 bufferSizeInSec = 0.02f;
if(AudioSessionSetProperty(kAudioSessionProperty_PreferredHardwareIOBufferDuration,
  sizeof(Float32), &bufferSizeInSec) != noErr) {
  return 1;
}

So basically you need to calculate the preferred buffer size in seconds (not samples, weirdly enough), and then hope that the system gives you a buffer size more to your liking.

However, you are probably looking at this problem the wrong way. AudioUnits are meant for realtime processing, so small buffersizes are preferred. A buffersize of 64K is absurdly large, and 1024 frames is actually quite large for a modern iPhone/iPad to process comfortably. Your aglorithm needs to be "block-based", meaning that you should break up the logic so that it can process 64K of samples in 64 calls, each with 1024 frames. This will lead to the most robust code.