How to Troubleshoot WebRTC Echo Cancellation That Is Not Working

WebRTC calls in browsers and web-based meeting apps rely on acoustic echo cancellation to stop the sound from a participant's speakers from being picked up by their microphone and sent back. When it fails, people hear their own voice return after a short delay. The steps below help you find where cancellation is breaking down and fix it without risky changes.

Identify the symptom and environment

Start by working out who hears the echo. Echo cancellation runs on the device that captures the sound. If you hear your own voice coming back, the device that is not cancelling it is usually the other participant's, not yours. Ask everyone on the call to describe what they hear before changing any settings.

• Who hears the echo, and whose voice is echoed.
• When it happens: from the start of the call, only at high speaker volume, only when people talk over each other, or after someone switches devices mid-call.
• Which input device and output device the echoing participant uses, such as laptop speakers with the built-in microphone, a USB speakerphone, a Bluetooth headset or an audio interface.
• Which browser or app, and which version, that participant uses.
• Whether it is a true echo (a delayed repeat of speech), a rising feedback howl, or doubled audio caused by the same person joining twice.

Isolate where the fault occurs

Echo has an acoustic path, from the speakers through the room into the microphone, and a processing path, the echo canceller that is supposed to remove it. Testing each part separately tells you which one needs attention.

• Have the participant whose audio produces the echo switch to headphones. If the echo stops, the acoustic coupling is stronger than the canceller can handle, or cancellation is not active on that side.
• Confirm that nobody has joined from two devices or two tabs in the same room. A canceller can only remove sound its own device played; audio coming from a second laptop or phone nearby is not cancelled.
• Join the same call from a different browser or from the app's own client on the same computer. If the echo disappears, look at browser settings, extensions or the app's audio options rather than the hardware.
• Try a different WebRTC app with the same devices. If the echo follows the devices across apps, focus on the acoustic setup and the operating system's audio configuration.

If you are building the app yourself, check what the browser actually applied rather than what you requested. Calling getSettings() on the local audio track reports whether echoCancellation is true. If it reports false or is missing, review the constraints passed to getUserMedia and any code that replaces or re-processes the track.

Try reversible fixes in order

Apply these on the side that produces the echo, one at a time, and retest after each so you know which change helped. Menu names differ between operating systems, browsers, drivers and app versions, so look for the equivalent option rather than an exact label.

• Lower the speaker volume and move the microphone away from the speakers. Expected: the echo becomes quieter or stops.
• Use wired or Bluetooth headphones for the call. Expected: no echo, because the speakers no longer reach the microphone.
• In the app's audio settings, switch off any mode intended for music or unprocessed audio. Such modes often disable echo cancellation along with other processing.
• Reduce the microphone input level if speech is clipping or very loud. A distorted signal is harder for the canceller to match against what was played.
• Play call audio directly through the browser or app. Routing it through virtual audio cables, loopback tools or mixing software can make playback invisible to the canceller.
• If possible, use the input and output of the same device, such as one headset or one speakerphone, instead of mixing separate devices. If you must combine them, check in the operating system's sound settings that each device uses a standard sample rate it supports.
• If the operating system or device software adds its own echo, noise or voice enhancement, toggle it once to see whether double processing helps or hurts, and keep whichever setting performs better. Noise suppression that targets background noise is a separate feature and does not replace echo cancellation.
• After changing devices, leave the call and rejoin, or restart the browser, so the app picks up the new input and output. Updating the browser to its current version is also worth trying.
• For developers: leave echoCancellation enabled in the audio constraints, and test whether the way remote audio is played back changes the result before adding custom processing.

Confirm the result

Repeat the original situation with the same people, devices and volume levels. The participant who first reported the echo should confirm it is gone, since they are the one who hears it. Test normal speech, a moment of people talking at the same time, and a rejoin after leaving the call. Developers can recheck getSettings() to confirm echoCancellation is reported as active. Avoid factory resets, drivers from unknown sources, or turning off browser and operating system security features; none of these are needed to confirm a fix.

If the problem remains

Keep a short record: who heard the echo, the devices and browser versions involved, whether headphones stopped it, whether another browser or app behaved differently, and what echoCancellation reported. This makes support requests much faster.

If the echo continues with headphones, a single device per person and no music mode enabled, contact the app's support with your notes, since the cause may lie in how the app handles audio. If it appears only with one particular speakerphone or headset across several apps, the device manufacturer's support is the better route. Persistent echo alone does not prove the hardware is faulty, so rule out the setup and settings before considering repair or replacement.