Why do AudioUnits only work at the hardware sample rate?

After opening an audio unit (IAA) using an AUGraph or directly with AudioComponentInstanceNew on an iPhone with a fixed hardware sample rate of 48000Hz, AudioUnitInitialize() will fail when either or both of the input and output AudioStreamBasicDescription's set for the audio unit contain a different sample rate (like 44100Hz). Setting the formats themselves return no error.


The question is why is this behavior? It doesn't seem to be IAA specific, since I tested many. One could also use the IAA in an offline setting, with a generic output AU for example, totally unrelated to the actual audio hardware.

Replies

I am running into this, too.


We have set our app's internal AudioUnit to be called at 44100. So, that's the behavior where it calls with uneven buffersizes because it's resampling. This is working fine. But we got past that only to find that it breaks InterApp audio if the AVAudioSession sampleRate and IAA's sampling rate don't match! Do I have this correct?


Is there a way of making this configuration work (running internally at 44100 on a 48000 system), or do we have to truly support 48000 if we want to also host IAA on newer phones? I didn't see it documented anywhere... what's the official word?


Thanks!

-Louis

It appears that iPhone device models from the 6s onwards (currently?) have hardware that can only sample at 48000. You need an older iOS device to run at 44100, or do resampling as needed in the Audio Unit or the app to get a rate other than 48000.

Right, but the issue is stranger- AudioUnitInitialize returns kAudioComponentErr_InvalidFormat if you attempt to instantiate an IAA at 44.1khz from an instance (our app) that's already running at 44.1khz on a 48khz device. So, the OS appears to be disallowing instantiating the IAA at 44.1 even though the rest of the application is already fine at 44.1 on this 48khz-native device... AU v3 instances do appear to work fine.

I think I figured it out. It's not an OS limitation, just an easy oversight to make. In our case, we were setting the output stream format but not the input's, so the rates suddenly didn't match. Re-reading the OP's original question, maybe that's what they meant. In that case, you may be able to use a kAudioUnitType_FormatConverter and do the resampling within the host program. Hope this helps someone! 🙂

Post not yet marked as solved Up vote reply of _LC Down vote reply of _LC