Requesting Echo Cancellation Does Not Promise a Quiet Transcript

The agent reads a reply aloud, and its own next transcript contains part of that reply. A developer sees echoCancellation: true in the microphone request and assumes the browser broke its promise. The request is a preference, while the transcript reflects sound captured through a particular microphone and playback route.

The echoCancellation constraint accepts a boolean and, where supported, the modes "all" and "remote-only". A plain true asks the browser to perform cancellation; the browser decides which audio to remove. "remote-only" targets audio from remote tracks represented by RTCPeerConnection, so it is a poor assumption for locally played agent speech. "all" asks to remove system-generated audio more broadly, but availability depends on browser support. Those mode names describe requested behavior, not a measured promise about transcription quality.

Three API views answer different questions. navigator.mediaDevices.getSupportedConstraints().echoCancellation says whether the browser recognizes that constrainable property. It does not say the chosen microphone and output path will suppress playback. A track’s getConstraints() reports requests; getSettings().echoCancellation reports the setting actually selected for that track. The MDN constraints guide explicitly distinguishes the requested constraints from current settings.

const supported = navigator.mediaDevices.getSupportedConstraints();
const stream = await navigator.mediaDevices.getUserMedia({
  audio: { echoCancellation: { ideal: true } }
});
const track = stream.getAudioTracks()[0];
console.log(supported.echoCancellation, track.getSettings().echoCancellation);

ideal: true favors cancellation without making capture fail solely because that preference cannot be met. If cancellation is a hard prerequisite, check support and request { exact: true }, then handle rejection. An unsatisfied mandatory constraint can yield OverconstrainedError, whose constraint field identifies an impossible requirement; permission and device failures have other error paths in getUserMedia. An unknown constraint can be ignored, so a support check still matters before relying on exact.

Even a reported enabled setting is not an acoustic test. Play the agent’s real output through the routes users take, such as built-in speakers, a headset, and a changed Bluetooth device. Capture the resulting microphone audio and inspect whether the agent’s speech appears in the transcript, especially during simultaneous user speech. Record the browser, input, output, selected setting, and observed failure together. Treat cancellation as one negotiated input condition; make the voice interaction resilient when audible playback still reaches recognition.