Dear core-audio list team member,
I am currently evaluating Audio Unit Extension support on OS X from a plugin vendor perspective.
According to Sierra AudioToolbox's AudioComponent.h header file:
Most component instances are loaded into the calling process.
A version 3 audio unit, however, can be loaded into a separate extension service process,
and this is the default behavior for these components. To be able to load one in-process
requires that the developer package the audio unit in a bundle separate from the application
extension, since an extension's main binary cannot be dynamically loaded into another
process.
An OS X host may request in-process loading of such audio units using
kAudioComponentInstantiation_LoadInProcess.
Moreover:
@constant kAudioComponentFlag_CanLoadInProcess
The system sets this flag automatically when registering components which can be loaded into
the current process. This is always true for V2 audio units; it depends on the packaging
in the case of a V3 audio unit.
So I started to tweak
AudioUnitV3Demo OS X host in order to run FilterDemo app extension within OSX AUv3Host process:
I verified AUv3 FilterDemo app extension reports CanLoadInProcess flag from its description.
I passed
loadInProcess option accordingly when AU v3 host calls
AVAudioUnit.instantiate to instantiate the AUv3 component.
But I can see that AudioUnit Extension is still running in a dedicated process...
Hence my question is:
What else should I do to be able to run FilterDemo AU extension within OS X AUv3 host ?
Is the default packing of FilterDemo App extension compatible with LoadInProcess instantiation ?
Thank you for your help,
Best regards,
Joris GIGNOUX