iOS: Bug in the simulator using AudioUnitRender

Question

I have hit yet another iOS simulator bug. My question is, is there some workaround?

Bug is this:

Load apple's AurioTouch sample Project.

and simply print out the number of frames getting received by the render callback (in aurioTouchAppDelegate.mm)

static OSStatus PerformThru(
                            void                        *inRefCon, 
                            AudioUnitRenderActionFlags  *ioActionFlags, 
                            const AudioTimeStamp        *inTimeStamp, 
                            UInt32                      inBusNumber, 
                            UInt32                      inNumberFrames, 
                            AudioBufferList             *ioData)
{
    printf( "%u, ", (unsigned int)inNumberFrames );

I get the following output:

471, 1, 1, 2, 1, 1, 1, 1, 2, 1, 1, 1, 1, 2, 1, 1, ...

However, if you comment out the call to AudioUnitRender on the next line:

{
    printf( "%u, ", (unsigned int)inNumberFrames );

    aurioTouchAppDelegate *THIS = (aurioTouchAppDelegate *)inRefCon;
    OSStatus err = 0; // AudioUnitRender(THIS->rioUnit, ioActionFlags, inTimeStamp, 1, inNumberFrames, ioData);

It now sends an appropriate number of floats each time.

471, 470, 471, 470, 470, 471, 470, 471, 470, 470, 471, 470, 471, 470, 470, 471, 470,

Another question I have is: why such a random number as 470, 471? I read somewhere that you specify the buffer length implicitly by specifying its time duration, and it sets the buffer length to the power of two that yields the best approximation to this duration. But empirical evidence suggests this is not so.

Anyway, pretty sure this is a bug. I'm going to go on file it. If anyone can shed some light, please do!

Answer 1

If you want to get the audio working with your simulator, you need to make sure your samplerate is set to 44.1k in OS X's audio/midi setup tool. AVAudioSession/Audio Services will report your samplerate as 44.1k no matter what it actually is when using the simulator.

By setting your mac's samplerate to 44.1k, you'll get a consistent inNumberFrames (default is 1024) per callback, although this can still allegedly be changed by the system (ex. app goes to background).

Answer 2

Generally the workaround to Simulator bugs is to test the app on the device. The iOS Simulators is just a simulator, not an emulator.

The iOS Simulator has some odd bugs. It may have to do with buffer sizes according to this post by Christopher Penrose:

The simulator will act wildly different setup to setup as it relies on your host audio gear, which may in your case be a third-party interface. I have seen the simulator refuse a reasonable power of 2 size because of the device. I have not been able to use audio in the simulator reliably.
James is telling me that I am being foolish but in practice I have been able to rely on the original configured buffer size without having it change on me.

Link with possibly more helpful info: http://osdir.com/ml/coreaudio-api/2010-04/msg00150.html