Identify what you are hearing
Echo and missing audio need different investigations. Use this table to choose a first check; it is a diagnostic hypothesis, not a diagnosis of your device.
| Symptom | First comparison |
|---|---|
| Your voice returns after a delay | Locate which participant’s microphone is sending the return sound |
| Everyone sounds doubled | Check a second meeting tab, phone or computer playing the same call |
| A loud whistle, ring or howl grows | Lower speaker volume and break the speaker-to-microphone loop immediately |
| You hear yourself even outside Jitsi | Check headset sidetone, OS microphone monitoring or an audio mixer separately |
| Nobody can hear one direction of the call | Use one-way audio diagnostics |
Multiple active audio devices and nearby speakers/microphones are established causes of meeting echo. The acoustic principle applies across meeting software; the cited Zoom reference is used for that principle, not for instructions about Jitsi menus. [S1]
First remove duplicate meeting audio
Choose one device to provide the microphone and speaker for each physical room. During the comparison, leave the meeting on other devices in that room or remove their meeting audio input and output. Keep any needed presentation visible on the chosen device. [S1]
A muted microphone does not silence that device’s speakers. For example, a muted phone can still play a remote person’s voice into a nearby laptop microphone. Simply muting the phone may therefore leave the return path active. [S1]
Try headphones on the chosen audio device and lower external speaker volume. Use a short, ordinary spoken phrase at a comfortable level; do not deliberately sustain a loud feedback loop. If the echo disappears, restore the original setup one change at a time to identify which route brought it back. This is a recommended comparison, not a guarantee that every headset or room will work. [S1]
Find the microphone returning the sound
With everyone’s agreement, ask attendees to mute their microphones one at a time while a remote participant speaks. Note when the repeated sound stops. The useful clue is the returning path, which may be on another attendee’s device rather than the person hearing their own voice.
For an organizer, muting a participant is a way to isolate a path, not permission to turn their microphone back on remotely. Jitsi’s FAQ distinguishes muting others from unmuting them; ask the participant to unmute when the comparison is ready, subject to the meeting’s moderation rules. [S2]
When one path is identified, check the selected microphone and output device on that attendee’s machine. A headset can be connected while the meeting still uses a laptop microphone or external display’s speakers. Use the device and permission guide if the intended device is missing. Recheck the route after reconnecting a headset or changing devices.
Check audio processing only after the physical route
WebRTC exposes echo cancellation and noise suppression as separate audio constraints; supporting a constraint is not a promise that it removes every echo. Browser/device behavior must be checked on the actual call. [S3]
For a self-hosted or embedded Jitsi installation, ask the operator whether speech-processing settings were deliberately changed for music or stereo. The reviewed Meet 11248 configuration documents disableAEC for disabling echo cancellation and disableAP for disabling audio processing. It also warns about the processing tradeoff when configuring HD/stereo audio. These are reasons to inspect the existing settings, not instructions to paste new values into every server. [S4]
Docker and Debian/Ubuntu users should inspect the configuration actually served by their deployment. The custom-config guide explains why a host-side file is not always the browser’s runtime configuration. An ordinary meeting participant should not need to edit a server to carry out the device comparisons above.
If the symptom appears specifically after screen-audio sharing or when toggling extra noise suppression in an embed, use the separate IFrame diagnostics. Do not treat that source-specific report as a universal echo fix.
Verify and prevent the return
Repeat the same short conversation with the same participants after each change. Check both directions of speech, then add the intended speaker, screen share or extra viewing device one at a time. Record which change recreates the symptom. A local microphone meter alone cannot prove what another participant hears.
For recurring room setups, keep a known audio-device arrangement and repeat the check after changing a dock, display, headset or mixer. If the problem remains, share a sanitized report containing browser/app version, OS, selected input/output, number of devices in the physical room, when the echo occurs and what stopped it. Keep private invitations and participant names out of public reports.
If the failure instead begins when a third person joins, follow bridge-path diagnostics. That pattern deserves its own network investigation rather than assuming every sound problem is acoustic feedback.
Sources and testing limits
- [S1] Zoom’s primary acoustic-echo guidance, checked 26 October 2026. Used for duplicate devices, speaker/microphone proximity and microphone-mute versus speaker-output distinction; Zoom-specific controls are not presented as Jitsi controls.
- [S2] Jitsi FAQ on muting participants, checked 26 October. Actual moderation policy still applies.
- [S3] W3C Media Capture and Streams, published draft dated 9 October 2025, checked 26 October 2026; echo cancellation and noise suppression are distinct properties.
- [S4] Immutable Meet 11248 configuration, reviewed 26 October 2026 for audio-processing option meanings. Commented examples are not proof of your deployed values.
This is an evergreen diagnostic guide. We did not record audio, run a meeting, test a headset/phone, change a server or reproduce a specific browser regression. The comparisons above still need to be verified on the affected setup. Recheck configuration advice when upgrading the client.