Clean input audio makes every downstream stage better: turn detection fires on real speech instead of HVAC hum, ASR word error rate drops, and the agent stops talking over a caller who never actually spoke. This page tells you where that cleanup happens on a TeleQuick Voice call, how to control it, and — just as important — what is not built so you don’t design against a feature that doesn’t exist yet. The short version: audio cleanup lives at the edge where audio is captured, not in the server media plane. Browser and app callers get full echo cancellation, automatic gain, and noise suppression for free from the capture device. Telephony callers rely on carrier- and handset-side processing, because the server-side media plane is deliberately a codec-and-timing layer, not a signal-processing (APM) stage.

​
Two capture edges, two cleanup stories

When you capture a mic with the SDK’s captureMicrophone(), the browser’s own audio pipeline runs a full AEC + AGC + noise-suppression chain ahead of the Opus encoder. The SDK drives that pipeline through a loopback capture graph purely to run the browser’s encoder, then diverts the encoded Opus frames onto the media-over-QUIC track — so you inherit the device’s processing without paying for a WebRTC media transport.The defaults enable all three. Override them per capture when you have a reason to (for example, a studio caller on a headset who wants raw audio):
import { captureMicrophone } from "@telequick/sdk/moqt";

// Defaults: AEC + AGC + noise suppression all ON.
const cap = await captureMicrophone(publication);

// Opt out — e.g. an external hardware processor already cleaned the signal.
const raw = await captureMicrophone(publication, {
  audioConstraints: {
    echoCancellation: false,
    autoGainControl: false,
    noiseSuppression: false,
  },
});

// Or bring your own already-processed track.
const custom = await captureMicrophone(publication, { track: myTrack });
captureMicrophone() refuses to run unless the browser exposes the standard encoded-frame transform, so cleanup and the encoded path are consistent for the whole session. See /modalities/voice/transport-web/browser-audio-capture and /modalities/voice/transport-web/rtcrtpscripttransform.

​
Why the media plane has no APM

The server media plane is a shard-per-core, zero-copy path built for throughput and low, predictable latency — it decodes/encodes codecs, resamples between clock rates, paces RTP, and bridges legs. It is intentionally not a DSP stage. Putting a per-frame audio-processing module (AEC/AGC/denoise) inline would add per-hop latency and CPU to a plane that pushes north of a million packets per second per NIC, and it would duplicate work the capture edge already does for free on the browser/app path. The one place this shows up in behavior is barge-in on telephony:
On a leg with no echo cancellation (raw SIP/PSTN), the agent’s own spoken response can bleed into the inbound audio. To stop that from self-triggering a false interruption, the barge-in gate is not lowered while the agent is speaking on telephony (the browser AEC path can afford to lower it because the device already removed the echo). If you route a non-AEC transport, keep that gate conservative. Details in /modalities/voice/concepts/turn-detection.

​
”Who is speaking?” — channel separation vs. voice printing

There are two different questions hiding under speaker identity, and TeleQuick Voice answers only the first one today.

​
Channel separation (built in, structural)

You almost never need acoustic diarization to tell the caller from the agent, because the two legs are already separate streams end to end: they arrive as distinct RTP sessions / distinct media-over-QUIC tracks, and call recordings are written stereo — caller on the left channel, agent on the right. So per-speaker transcription, per-side talk-time, and turn attribution fall out of the transport, not out of a voice model. If your goal is “transcribe each party separately” or “measure agent vs. caller talk ratio,” you already have it — see /modalities/voice/observability/call-traces and /modalities/voice/transport-telephony/codecs.

​
Voice printing / speaker ID (not built)

Aspirational, not shipped. TeleQuick Voice has no speaker-ID, voiceprint/biometric, or acoustic-diarization feature in the media path today. There is no enrollment step, no per-speaker embedding, and no “verify the caller by their voice” API. Voiceprint appears only as a possible future authentication factor on the contact-center roadmap — not a shipped capability.
If you need speaker verification or diarization now, do it at the runtime layer: point the call audio at a third-party ASR/biometrics provider that offers it, or run diarization on the separated channels of the finished recording. The runtime’s bring-your-own-provider model is the supported seam — see /modalities/voice/runtime/byo-asr-llm-tts.

​
What you can rely on today

CapabilityStatusWhere it runs
AEC / AGC / noise suppression on browser & app captureAvailableCapture device (browser audio pipeline)
Codec decode/encode + resampling on the media planeAvailableServer media plane
Stereo caller/agent channel separation in recordingsAvailableMedia plane recording tap
Server-side AEC / AGC / denoise (APM) on telephony legsNot built— (rely on carrier/handset)
Speaker ID / voiceprint / acoustic diarizationNot built (roadmap)— (use a BYO provider)

Turn detection & barge-in

How the no-echo-cancellation media plane shapes the barge-in gate.

Browser audio capture

Where AEC/AGC/NS actually run for browser and app callers.

Codecs

G.711 on the wire, PCM16 in the runtime, and the resampling in between.

Troubleshooting: isolation

Noisy input, echo, and self-triggered barge-in — how to diagnose.