Does the ExtAudioFile API ever use hardware to decode audio?

Question

I am using the ExtAudioFile interface to decode audio, and would like to know whether it ever makes use of hardware-assisted audio decoding.

The docs for the kExtAudioFileProperty_CodecManufacturer property say:

Use this property in iOS to choose between a hardware or software encoder, by specifying kAppleHardwareAudioCodecManufacturer or kAppleSoftwareAudioCodecManufacturer.

This seems to indicate that ExtAudioFile can indeed make use of decoding hardware.

Elsewhere, in the Audio Format Services docs, I find:

Hardware-based codecs can be used only when playing or recording using Audio Queue Services or using interfaces, such as AV Foundation, which use Audio Queue Services. In particular, you cannot use hardware-based audio codecs with OpenAL or when using the I/O audio unit.

... which is not completely clear; if ExtAudioFile uses Audio Queue Services in its implementation, then maybe it can make use of hardware, but we don't actually know how it is implemented.

I tried to test at runtime whether the hardware was being used, but this itself proved difficult. One method, given in the Audio Format Services reference, is to use AudioFormatGetProperty to test the kAudioFormatProperty_HardwareCodecCapabilities property. But the sample code does not work, always returning kAudioFormatUnsupportedPropertyError. (After searching online, I found a few other questions from people who have this problem, but no reports of ever using it successfully.)

So... I'm wondering if anyone knows of any way to test for certain whether the hardware decoder is currently active (in which case I could test for myself whether ExtAudioFile is using it). Or alternatively if anyone has any definitive knowledge of whether ExtAudioFile does use hardware (not based solely on the vague mentions in the Apple docs).

Answer 1

Specifying kAppleHardwareAudioCodecManufacturer with ExtAudioFileSetProperty() appears to enable hardware decoding, because it fails with kAudioConverterErr_HardwareInUse when there is already one audio file open with that codec set, and with kAudioQueueErr_InvalidCodecAccess when the audio category is set to one that does not (according to the documentation) enable hardware decoding.

However, after profiling with Instruments, I found that performance was slightly worse with hardware decoding enabled, which I still can't explain...