OSX CoreAudio播放,没有Graph API,没有CAPublicUtility

fearum 发布于 2019-08-14 audiounit 最后更新 2019-08-14 08:39 1 浏览

这个问题不是关于AU插件,而是关于将音频单元集成为独立应用程序的构建块。经过大量尝试后,我无法弄清楚两个AudioUnit的最简单的“无图”连接是什么,它将作为“playthrough”发挥作用。 我明白,kAudioUnitSubType_HALOutput子类型的单个音频单元可以捕捉,渲染,实时处理和转发任何音频输入数据。但是,只要使用全双工音频硬件或在用户级别从内置设备创建聚合I / O设备,播放似乎就可以正常工作。 但是,内置设备不是全双工的,“聚合”它们也有一定的缺点。因此,我决定研究一个硬编码的两单元连接可能性(不要陷入Graph API),并用非全双工硬件测试它的行为。 不幸的是,我没有找到全面的文档,也没有找到示例代码来创建最简单的两单元游戏,只需使用直接连接范例,如Apple技术说明TN2091中所建议的:

AudioUnitElement halUnitOutputBus    = 1; //1 suggested by TN2091 (else 0)
AudioUnitElement outUnitInputElement = 1; //1 suggested by TN2091 (else 0)
AudioUnitConnection halOutToOutUnitIn;
halOutToOutUnitIn.sourceAudioUnit    = halAudioUnit;
halOutToOutUnitIn.sourceOutputNumber = halUnitOutputBus;
halOutToOutUnitIn.destInputNumber    = outUnitInputElement;
AudioUnitSetProperty (outAudioUnit,                       // connection destination
                      kAudioUnitProperty_MakeConnection,  // property key
                      kAudioUnitScope_Input,              // destination scope
                      outUnitInputElement,                // destination element
                      &halOutToOutUnitIn,                 // connection definition
                      sizeof (halOutToOutUnitIn)
                      );
如果可能的话,我的任务是避免涉及Graphs,或者更糟糕的是,CARingBuffers来自所谓的PublicUtility,过去多年来它一直受到bug和延迟问题的困扰,并涉及一些雄心勃勃的假设,例如:
#if TARGET_OS_WIN32
#include <windows.h>
#include <intrin.h>
#pragma intrinsic(_InterlockedOr)
#pragma intrinsic(_InterlockedAnd)
#else
#include <CoreFoundation/CFBase.h>
#include <libkern/OSAtomic.h>
#endif
预先感谢任何可能使我指向正确方向的暗示。
已邀请: