能否开发类型为'aufc'(kAudioUnitType_FormatConverter)的AUv3扩展？

aufc类型AUv3扩展可行性结论 #

官方文档明确仅支持四类AUv3扩展类型，kAudioUnitType_FormatConverter（即aufc）不在支持列表内，手动修改componentDescription.componentType虽然可以完成本地实例化，但该方案完全不适合生产环境使用：

• 系统对AUv3扩展的生命周期、沙箱权限、渲染线程调度逻辑仅针对官方指定的四类扩展做适配，aufc类型扩展会出现大量隐性问题，包括但不限于后台音频中断、渲染线程crash、参数同步失效
• iOS 15及以上系统会主动回收非允许类型的AUv3扩展进程，该类应用无法通过App Store审核

基于现有AVAudioEngine代码的替代方案 #

你已经基于AVAudioEngine实现的逻辑几乎不需要做大改，可以选择以下任意一种落地路径：

• 方案1（改造成本最低）：将你的时间拉伸算法封装为自定义AVAudioNode子类，可选择继承AVAudioSourceNode或者AVAudioEffectNode，内部实现拉伸渲染逻辑后直接插入到现有AVAudioEngine音频链中，直接替换原有AVAudioUnitTimePitch节点即可，不需要走AUv3扩展逻辑，完全兼容你现有的代码结构
• 方案2（需要跨App使用算法时选择）：将AUv3扩展的类型修改为官方允许的kAudioUnitType_Effect（效果类），不需要调整内部的时间拉伸算法逻辑，仅修改扩展plist中的类型配置即可，系统完全支持该类扩展的调度，也可以正常通过审核，宿主端（包括你自己的App）可以像调用普通效果节点一样调用该扩展实现变速变调功能
• 方案3（非实时场景适用）：如果你的使用场景不需要实时调节拉伸参数，可以将拉伸逻辑单独抽离为离线音频处理模块，先对音频文件做预处理完成时间拉伸，再交给AVAudioEngine执行播放逻辑，性能开销更低

内容的提问来源于stack exchange，提问作者Steve M