1

This question is not about AU plugins, but about integrating audio units as building blocks of standalone application programs. After much trying I can't figure out what would be the simplest "graphless" connection of two AudioUnits, which would function as a "playthrough".

I understand how powerful and sufficient a single audio unit of subtype kAudioUnitSubType_HALOutput can be in capturing, rendering, live-processing and forwarding of any audio input data. However, play through seems functional as long as working with either full-duplex audio hardware or creating aggregate i/o device from built-in devices on user level. However, built-in devices are not full duplex and "aggregating" them also has certain disadvantage. Therefore I've decided to study a hard-coded two-unit connection possibility (without plunging into Graph API), and test its behavior with non-full-duplex hardware.

Unfortunately, I have found neither comprehensive documentation nor example code for creating a simplest two-unit play through using only the straightforward connecting paradigm, as suggested in Apple Technical Note 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)
                      );

My task is to keep off involving Graphs if possible, or even worse, CARingBuffers from so-called PublicUtility, which used to be plagued by bugs and latency issues for years and involve some ambitious assumptions, such as:

#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

Thanks in advance for any hint which may point me in the right direction.

user3078414
  • 1,942
  • 2
  • 16
  • 24
  • Did You Find answer to this? – user2801184 Mar 22 '16 at 21:26
  • Can you please answer this question?http://stackoverflow.com/questions/36165768/issues-with-caplaythrough-example – user2801184 Mar 22 '16 at 22:31
  • not yet, unfortunately, thanks for your interest… I am learning to reach better understanding of what has been done in TN2091 and subsequently undone in TN2223. Seems also to depend on some device-dependent properties I still do not fully understand. Still working with a number of problems. – user3078414 Mar 22 '16 at 22:35
  • Thank you for the reply. Goodluck! – user2801184 Mar 22 '16 at 22:37
  • I hope I have been clear about trying to keep off of the CARingBuffer. IMHO, this C++ code is too complicated for my requirements, although some other authors have been praising it. On Apple Discussion Forums I have been advised against relying on it. For my work I'm using M.Tyson's TPCircularBuffer, [link](https://github.com/michaeltyson/TPCircularBuffer), although I find async i/o not a trivial matter. I don't think discussing the CA book would really be on-topic. Thanks for your understanding. – user3078414 Mar 22 '16 at 22:57

0 Answers0