AAX SDK  2.4.1
Avid Audio Extensions Development Kit
Classes
Hybrid Processing architecture

An architecture combining low-latency and high-latency audio processing.

Overview of Hybrid

Hybrid processing is an optional feature that allows a single plug-in to simultaneously render data on the host's low- and high-latency signal networks. In many large plug-ins this can be very useful. For example, consider a reverb algorithm with both early reflection and tail processing. With AAX Hybrid, this plug-in can process the early reflections at low latency while allowing the tail algorithm to be handled at higher latency (and thus higher efficiency.) Other kinds of algorithms that could benefit from Hybrid processing are noise reductions, analyzers, multi-effect suites, and instruments.

Because the low-latency AAX signal network may be run on DSP hardware, AAX DSP plug-ins that incorporate Hybrid processing can split audio processing between the DSP and the host. This provides the benefits of low latency, highly deterministic DSP-based processing while also allowing the plug-in to leverage the high-latency power of the Intel core where appropriate.

AAX Hybrid is an internal feature and is not exposed to users, except in terms of better plug-in performance and more efficient DSP usage.

Note
AAX Hybrid may be protected by one or more U.S. and non-U.S. patents. Details are available at www.avid.com/patents.

Implementing Hybrid processing

For an example of Hybrid processing, see the DemoDelay_Hybrid example plug-in

To register for Hybrid processing, a plug-in should add values for AAX_eProperty_HybridInputStemFormat and AAX_eProperty_HybridOutputStemFormat to the associated ProcessProc property map. Once these values have been registered, both the ProcessProc callback and the Hybrid render function in the plug-in's data model will be invoked during processing.

Hybrid processing context information is provided via a dedicated Hybrid processing context structure. It is not possible to register additional fields on this context. However, unlike a normal algorithm ProcessProc, the Hybrid render method is implemented directly within the plug-in's effect parameters object and has direct access to the data model memory. This is possible since the render method will always run on the host, and makes it easier to implement algorithms that require access to the data model, e.g. for direct access to impulse responses, etc.

The AAX host provides dedicated audio buffers in both the ProcessProc context and the Hybrid processing context. These buffers can be used to pass audio data between the low-latency ProcesProc and the Hybrid render contexts.

Samples which are sent from the ProcessProc to the Hybrid processing callback and back to the ProcessProc are delayed by a fixed amount relative to the normal input samples that are processed directly by the ProcessProc to its output buffers. The number of samples of delay that are added in this round-trip is available to the plug-in via AAX_IController::GetHybridSignalLatency() .

Additional information

Parameter update timing

Because updates are not passed to the Hybrid processing context using the normal AAX port infrastructure, any parameter updates from automation will be reflected in this context a little bit ahead of time (~21 ms at 44.1 kHz.) See the Parameter update timing page for a discussion of parameter timing accuracy and some suggestions of how you can maintain accurate parameter update timing.

Host support and alternatives

Not all AAX hosts support AAX Hybrid processing. See the Host Support page for additional information.

See also
Direct data access interface for another approach for transferring non-audio data between the algorithm callback and the plug-in's data model.

Classes

struct  AAX_SHybridRenderInfo
 Hybrid render processing context. More...
 

Hybrid audio methods

virtual AAX_Result AAX_IACFEffectParameters_V2::RenderAudio_Hybrid (AAX_SHybridRenderInfo *ioRenderInfo)=0
 Hybrid audio render function. More...
 

MIDI methods

Methods to access the plug-in's host-managed MIDI information.

virtual AAX_Result AAX_IController::GetHybridSignalLatency (int32_t *outSamples) const =0
 CALL: Returns the latency between the algorithm normal input samples and the inputs returning from the hyrbid component. More...
 

Function Documentation

◆ RenderAudio_Hybrid()

virtual AAX_Result AAX_IACFEffectParameters_V2::RenderAudio_Hybrid ( AAX_SHybridRenderInfo ioRenderInfo)
pure virtual

Hybrid audio render function.

This method is called from the host to render audio for the hybrid piece of the algorithm.

Note
To use this method plug-in should register some hybrid inputs and ouputs in "Describe"

Implemented in AAX_CEffectParameters.

◆ GetHybridSignalLatency()

virtual AAX_Result AAX_IController::GetHybridSignalLatency ( int32_t *  outSamples) const
pure virtual

CALL: Returns the latency between the algorithm normal input samples and the inputs returning from the hyrbid component.

This method provides the number of samples that the AAX host expects the plug-in to delay a signal. The host will use this value when accounting for latency across the system.

Note
This value will generally scale up with sample rate, although it's not a simple multiple due to some fixed overhead. This value will be fixed for any given sample rate regardless of other buffer size settings in the host app.
Parameters
[out]outSamplesThe number of samples of hybrid signal delay

Implemented in AAX_VController.

Collaboration diagram for Hybrid Processing architecture: