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.

Implementing Hybrid processing

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.

• The plug-in may pass output from the low-latency ProcessProc to the Hybrid render method using additional audio buffers that are added at the end of the ProcessProc context's normal output buffer array. The ProcessProc may perform any pre-processing that is desired before passing audio to the Hybrid render context via these buffers.
• Similarly, the plug-in may pass samples from the Hybrid processing callback to the low-latency ProcessProc using additional audio buffers that are added at the end of the ProcessProc context's normal input buffer array. These samples will be delayed by a fixed amount relative to the normal input samples that are sent directly from the signal net.

Implementation Subtleties

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.)

Todo:

Add information about Hybrid compatibility with AudioSuite or offline processing (PTSW-185422)

Document what exactly the fixed delay is between samples from the Hybrid context and samples from the signal net

Document whether the hybrid render method will always be invoked with the same buffer size (1024 samples)

Document use of AAX_IController::GetHybridSignalLatency

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...

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

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

Function Documentation

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.

virtual AAX_Result AAX_IController::GetHybridSignalLatency ( int32_t *  oSamples ) 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]

oSamples

The number of samples of hybrid signal delay

Implemented in AAX_VController.

Collaboration diagram for Hybrid Processing architecture: