Skip to main content
Start with a working SDK, LiveKit or Pipecat integration and pin its dependencies. This guide covers the native SDK. Use the WebAssembly guide for browser-specific package and authentication requirements.

​
Prepare the release

  1. Pin the version set. Record the language binding, core SDK, framework plugin and model ID in your release. Keep the lockfile and check the compatibility matrix.
  2. Match the platform. Select the package or native library for the target OS and CPU architecture. Test library loading inside the deployment image or host environment.
  3. Provision model files. Download compatible .aicmodel files before deployment. Verify the service can read and load them, and retain the exact files with the release.
  4. Inject credentials at runtime. Follow the authentication guide with your secret manager. Keep keys out of images, build arguments, source control and logs.
  5. Retain a rollback bundle. Keep the previous application, dependencies, models and configuration together so rollback restores a compatible combination.

​
Configure network access

Audio inference runs locally through AirTen. Review each network activity separately: Solid arrows show local processing; dotted arrows show downloads or metadata traffic. SDK inference does not upload input audio. Your application and downstream services may have separate audio flows. Entitlements and telemetry settings determine which network paths apply. See telemetry for data categories and controls. For restricted egress, obtain the current destination requirements from ai-coustics. Disconnected deployment requires a suitable offline license and provisioned models. Test a cold start and the required operating period under your network restrictions, including entitlement expiry or renewal. An online session tolerating a network failure does not establish offline support.

​
Separate startup from audio processing

Create and initialize models, processors and voice activity detection (VAD) instances before accepting live audio. Keep downloads, credential retrieval, initialization and teardown outside real-time audio callbacks. Allocate an independent processor and VAD state for each independent stream. Process frames in order and follow the streams and state guidance for reset, reconnect and concurrency. Match the sample rate, mono format and block size to the actual incoming stream using the audio format reference. Check readiness before accepting traffic:
  • Load the deployed model. Verify the file path and compatibility with the installed core SDK.
  • Check a controlled audio fixture. Process a non-silent recording with valid authorization, inspect errors and verify output length, format and expected processing behavior.
  • Check framework activation. Confirm the filter is active and not silently passing audio through.
  • Measure under load. Exercise the expected stream count under the deployed CPU and memory limits.
Use controlled fixtures for readiness tests and keep production audio out of diagnostics and CI artifacts.

​
Set a capacity and failure policy

A 160-sample frame at 16 kHz represents 10 ms of audio. Sustained processing above 10 ms cannot keep pace on a serial path. Compare frame processing time against this budget. Record high-percentile processing time, queue depth, memory and CPU use at the intended concurrency. Include resampling and framework overhead. Use the performance guide and OpenTelemetry metrics to track regressions. Bound queues and choose an overload policy: reject new sessions, stop the failing session or report a fallback. Test CPU throttling, credential rejection and token-refresh failure. Surface background-task errors. Report bypass and degraded processing separately from active enhancement, VAD or analysis.

​
Shut down and upgrade

Stop new streams and audio submissions, finish or cancel pending work and release SDK instances outside the audio callback. Stop token-refresh tasks too. Where exposed, terminate_session() requests termination and can block during cleanup. Processing may be disabled after it returns; submit no further frames and create a new instance for a new session. Before upgrading, compare the same fixtures, failure cases and settings on both versions. Check the changelog, compatibility matrix and applicable migrations, then roll out gradually.

​
Verify the deployment

Record these results with the release: Use troubleshooting for failed checks. See your agreement and pricing and support information for commercial terms.