Skip to main content
This guide explains the factors that influence audio latency (output delay) in the ai-coustics SDK and provides best practices for optimization.

​
Terminology

It is important to distinguish between Inference Latency and Audio Latency when optimizing your application: These are independent values. For example, a model might calculate a result in 2 ms (inference latency), but the audio output will be shifted by 30 ms (audio latency) relative to the input due to the model’s architecture. To avoid confusion we call the audio latency the audio delay of the processor.

​
Understanding Audio Delay

In real-time audio applications, audio delay is the time offset between the input signal and the processed output. The primary function to determine the total end-to-end delay is aic_processor_context_get_audio_delay.
  • Output: The function returns the delay in samples.
  • Conversion: To convert the delay to milliseconds, use the following formula:
delay_ms=(delay_framesconfigured_sample_rate)×1000\text{delay\_ms} = \left( \frac{\text{delay\_frames}}{\text{configured\_sample\_rate}} \right) \times 1000

​
Components of Audio Delay

The total returned value includes three potential sources of delay:
Sample Rate Impact: Sample rate has no effect on the output delay. Neither the model’s native sample rate nor the processor’s configured sample rate changes the delay duration.

​
Factors Affecting Delay

Several factors affect the overall delay of the SDK:

​
1. Algorithmic Delay (Model Choice)

This is the minimum output delay inherent to the model’s architecture. Currently, all of our models have an algorithmic delay of 30 ms. See the model documentation for exact values per model.

​
2. Adapter Delay (Block Size)

The SDK uses an internal adapter to handle differences between your application’s buffer size and the model’s internal processing window (typically 10 ms).
  • Optimal Block Size: Each model was trained to process a buffer of audio of fixed length at a given sample rate on each forward pass. This is what is referred to as the model’s native window size and sample rate. The optimal block size is the number of mono samples required to produce the model’s native window size at a given sample rate. You can get this value by calling aic_model_get_optimal_block_size with your target sample rate.
  • Non-Optimal Block Size: If you initialize the SDK with a block size different from the optimal one, the adapter introduces buffering to match the model’s window, which increases delay.

​
3. Buffering Delay (Variable Block Sizes)

The aic_processor_initialize function has a boolean parameter variable_block_size.
  • false (Default): The SDK expects a fixed block size for every process call. This is the lowest latency mode.
  • true: The SDK allows you to send blocks shorter than the one specified at initialization. This flexibility comes at the cost of increased delay due to additional buffering.
Blocks longer than the configured block_size are rejected with AIC_ERROR_CODE_AUDIO_CONFIG_MISMATCH in both modes.
aic_vad_initialize and aic_collector_initialize take the same three arguments with the same meaning, so block size and the variable-block flag affect the VAD’s prediction delay and the analyzer’s buffering the same way they affect the processor. See Audio Format.

​
VAD Prediction Delay

A dedicated VAD reports a prediction delay rather than an audio delay, through aic_vad_context_get_prediction_delay. The distinction matters because the VAD does not modify or delay your audio. The prediction delay tells you how far behind its own input the published speech decision is, so you can line speech decisions up with the audio timeline. If you run enhancement and VAD side by side on the same input block, the two delays are independent of each other. Use the processor’s audio delay to align audio, and the VAD’s prediction delay to align speech decisions.
Before SDK 0.22.0, a single output delay query covered both, because the VAD was driven by the processor. See Migrate to the dedicated VAD.