Skip to main content
Measure audio alignment and application response time separately. The SDK’s delay query describes where enhanced samples belong on the input timeline; it is not a measurement of the full voice agent.

Terminology

For example, computing audio could take 2 ms while the output is delayed by 30 ms. These are illustrative figures, not model measurements.

Understanding audio delay

Use aic_processor_context_get_audio_delay in C or your binding’s equivalent, such as processor.get_context().get_audio_delay() in Python. Query after initialization so the result reflects the configured sample rate and buffering. The value is in samples at the configured host rate: delay_ms=delay_samplesconfigured_sample_rate×1000\text{delay\_ms} = \frac{\text{delay\_samples}}{\text{configured\_sample\_rate}} \times 1000 It excludes capture hardware, network transport, application queues, downstream speech-to-text and playback buffering. Do not call it the total end-to-end delay of your application.

Components of audio delay

Requery after changing the rate, block size or model.

Factors affecting delay

1. Algorithmic delay (model choice)

Model architectures differ. Use the model catalog and runtime query rather than assuming every model has a 30 ms delay. VAD prediction delay and Tyto’s analysis window are separate quantities.

2. Adapter delay (block size)

Call aic_model_get_optimal_block_size with the host sample rate, or the corresponding binding method. This gives the number of samples that matches the model’s processing window at that rate. Non-optimal blocks require adaptation and can increase delay. Choose the host block size with the capture/playback pipeline in mind: avoiding SDK buffering is only one part of the full system.

3. Buffering delay (variable block sizes)

With variable_block_size = false, each call must contain exactly the configured block size. With true, shorter calls are accepted at the cost of additional buffering. Larger calls are rejected in both modes. Collector and VAD configuration uses the same host-audio fields, but neither returns enhanced audio. Their buffering affects when analysis input or speech decisions become available. See audio format.

VAD prediction delay

A dedicated voice activity detector (VAD) exposes aic_vad_context_get_prediction_delay. It describes how far a published decision trails the VAD’s input. VAD does not shift or modify the audio samples. When enhancement and VAD run on the same original input, align enhanced audio using processor delay and align speech decisions using VAD prediction delay. Framework speech/silence thresholds and end-of-turn logic can add further decision latency. Before core SDK 0.22.0, the processor drove VAD and a shared output-delay query covered both. See dedicated VAD migration.

Align file comparisons

For file enhancement, retain the original sample count, flush the processor’s delayed tail with silence and remove the leading delay from the concatenated output. Then trim to the original duration. The Python quickstart demonstrates this procedure. Compare recordings at the same rate and on the same timeline. Do not mistake a shifted waveform for lost speech or compare differently trimmed transcripts. Use the evaluation guide for quality comparisons and performance guide for timing measurements.