Skip to main content

​
Audio requirements

The SDK handles one mono audio stream per object. Each call accepts a contiguous block of decoded float32 PCM samples. Your input must meet the following requirements:
  • One channel (mono)
  • Decoded PCM samples in float32 format
  • The same sample rate used to initialize the object
  • The configured block size, or a smaller block if variable block sizes are enabled
Multi-channel buffers are not accepted. Mix multi-channel audio down to mono before processing, or use a separate processor for each channel that represents an independent stream.
If you are upgrading from an SDK version with multi-channel processing methods, see Migrate to mono processing.

​
Audio entry points

Three objects take audio, with the same mono requirements but different roles: Make sure the VAD and collector receive the original input rather than the processor’s enhanced output. See Using VAD alongside enhancement and Real-Time Analysis.

​
Block size

The block size is the number of mono samples in one call. You set it when you initialize the object, and it defines the upper bound for every call.
  • For fixed-block mode (variable_block_size = false), every call must contain exactly the initialized block_size.
  • For variable-block mode (variable_block_size = true), every call may contain up to the initialized block_size. Larger calls are always rejected.
  • Any block size is accepted at any supported sample rate. The model’s optimal block size is the one that avoids extra buffering, and therefore gives the lowest delay.
These rules are identical for the processor, the VAD, and the collector. All three take a sample rate, a block_size, and a variable_block_size flag at initialization, and each keeps its own configuration. Objects that share an input block should be initialized for the same audio format, even when their models report different optimal configurations. Changing the sample rate or maximum block size requires reinitializing the object. Initialization allocates memory, so do not perform it on a real-time audio thread. To clear an object’s history without changing its format, reset it instead. See Streams and State.

​
Multi-channel input

How you prepare multi-channel input depends on what its channels represent.

​
One recording with multiple channels

Mix the channels down to one mono stream in your application, then pass the mono samples to the SDK. Your application is also responsible for choosing the output channel layout, if a downstream system requires multi-channel audio. For a simple average mixdown with N channels:
A simple average can reduce the level of signals that are out of phase. Use an appropriate downmix matrix or audio library when channel layout, gain, or phase relationships matter.

​
Independent streams stored as channels

If each channel contains a distinct stream, e.g. two sides of a call, do not mix them together. Create and initialize one processor per channel, and pass each channel to its processor as a mono buffer.

​
Codecs

The SDK processes decoded PCM samples, not encoded audio files or network packets. Codecs such as MP3, AAC, Opus, and G.711 are not decoded by the SDK. If the input is encoded, decode it to mono float32 PCM in your application or media stack before passing it to the SDK. After processing, encode the enhanced PCM output into the format required by your application.

​
Common pitfalls

  • Passing interleaved, sequential, or planar multi-channel data directly to a process call
  • Treating the total number of samples in a multi-channel buffer as the mono block size
  • Processing distinct channel streams with one processor
  • Using a sample count that does not match the initialized block size (AIC_ERROR_CODE_AUDIO_CONFIG_MISMATCH)
  • Reinitializing a processor on a real-time audio thread
  • Feeding the VAD or the collector the processor’s enhanced output instead of the original input
  • Initializing objects that share an input block for different sample rates or block sizes