Google Meet has no sound: identify the missing audio path first

Why the direction of silence matters

Before changing anything, write one sentence describing who cannot hear what. Useful descriptions include that you cannot hear any participant, everyone can hear you except one person, or conversation works but a presented video has no audio. Each description narrows the path. Reinstalling a browser cannot be justified simply by the phrase no sound, especially when an input issue has been mistaken for a speaker issue.

Incoming meeting audio travels through the meeting application, browser, selected output, and physical speakers or headphones. Outgoing speech begins at your microphone and passes through capture permissions and the call. Presentation audio can be shared through a separate route. A successful check of one path does not automatically prove another. For example, a moving microphone indicator says nothing about whether your headphones are receiving the other person's voice.

MeterSee offers a local listening baseline, not a Google Meet certification. Its Speaker Test generates a short tone and asks you to confirm what you heard. It cannot enter your meeting, hear remote participants, inspect organization policy, or establish that a real call will work. Use it to distinguish local output trouble from a symptom that appears only inside Meet, then return to a consented meeting comparison.

Prepare without disrupting the meeting

1. If the meeting is already live, tell the host through chat that you are checking audio. Avoid playing test tones into an open microphone. Mute your microphone or leave briefly before local testing, and arrange another communication route if the meeting is important. Do not keep several joined devices audible in the same room, because that creates a separate echo problem.
2. Write down the intended microphone and output device. A monitor connected by HDMI, a USB dock, a Bluetooth headset, and built-in speakers may all appear in the same menus. Identify the actual device names instead of assuming the default entry points to the equipment you are wearing. Note any cable or dock connected just before sound disappeared.
3. Lower the listening volume before the first test, then use a comfortable level for ordinary speech. Check a physical headset mute switch and any amplifier power control without changing unrelated settings. Keep headphones available when possible so a successful output test does not feed back into your microphone.
4. Save work before restarting a browser, and confirm you know how to rejoin the meeting. Browser restarts can interrupt uploads, forms, and unsaved work even when tabs later reopen. On a managed work or school device, do not bypass policy controls or remove required security software to make a test proceed.
5. Plan one comparison at a time. Keep the same output while changing the application, or keep the same application while changing the output. Record what changed and what happened. Switching devices, granting permissions, rejoining, and updating all at once may restore audio but leaves you unable to identify which change mattered.

Rule out a meeting mode that intentionally has no audio

Check how you joined. Google documents that Companion mode does not provide the normal microphone and speaker path. This matters when a person joins primarily to present beside a room system and expects their laptop to behave like a second ordinary call. If you need this device to handle conversation, leave that mode and join normally, coordinating with the room so only the intended audio endpoint is active.

A muted microphone button is not the same as muted incoming sound. Clicking your microphone affects what you send, not whether you hear other participants. Similarly, a visible presentation does not prove you have joined with ordinary conversation audio. Look at the meeting's current mode and controls before treating an unavailable microphone or speaker as a hardware failure.

Ask whether at least one other participant can hear the current speaker. If everyone except you hears them, investigate your receiving path. If nobody hears them but they can hear everyone else, they should investigate their microphone. If only one pair of people reports trouble, compare another consenting participant before concluding that either person's device has failed. Keep the test short and avoid recording anyone without permission.

Test local output outside Meet

Open MeterSee Speaker Test outside the live conversation and play one channel at low volume. The expected result is an audible tone from the intended device and side. Write down that first observation, then play the other channel. The page exposes its stereo confirmation after both left and right have been played and playback has stopped; one audible tone alone does not complete it. If the browser reports that audio could not start, check browser audio availability separately from output routing.

If the tone is silent, play a familiar local audio item in another application through the same selected output. Silence in both places makes a broader output, volume, cable, or device issue more plausible. Sound in the other application but not the browser directs attention toward browser or per-application routing. Neither result requires immediate microphone permission changes, because listening and capturing speech are separate operations.

If MeterSee is audible and Meet is silent, reopen Meet's audio settings and inspect its speaker selection. A device connected after the meeting began may not be the same device the meeting is using. Where the interface offers a speaker test, use it at the same comfortable level. If the speaker selector is unavailable in your browser or device, verify the operating-system output and consult the current client-specific controls.

Inspect whether the Meet tab or site is muted through the browser's normal tab menu. Also inspect any per-application mixer that exists on your operating system. An application can be quiet even when the system's main volume is not. Do not maximize every slider; establish a sensible listening level and verify that the specific browser is neither muted nor routed to an unused output.

Operating-system checks for the receiving path

On Windows 11, start in Settings, System, Sound. Check the selected Output device and, if needed, Volume mixer for the browser's volume and destination. The exact controls depend on the Windows build and audio driver. Older Windows installations can expose legacy dialogs instead. Treat menu differences as a reason to consult the installed version's help, not as evidence that an audio device is missing.

On current macOS versions, System Settings, Sound, Output shows available destinations. Older versions use System Preferences. Select the device deliberately and check its available volume controls; some external outputs leave volume adjustment to the hardware. A monitor that accepts audio can appear even when you do not intend to listen through it. Recheck Meet after choosing the output because application-specific selection can still differ.

On phones and tablets, use the meeting's available audio-route control and the operating system's connected-device controls. Labels differ by mobile app, platform, and release. Check whether sound is going to Bluetooth equipment elsewhere or to the earpiece rather than a loudspeaker. This guide does not assume that desktop browser menus exist inside the mobile Meet app. Use the corresponding platform tab in Google's help when the interface differs.

If Bluetooth output disappears or changes when the microphone activates, compare a wired or built-in output for the same meeting. Record whether the problem is total silence, reduced listening quality, or a source switch. These are different symptoms. Keep a stable alternate output for the meeting if needed, then investigate the headset path afterward rather than repeatedly reconnecting during a presentation.

When others cannot hear you

If incoming speech works but your voice does not reach others, open Meet's microphone selection and choose the intended input. Speak normally and look for the local activity indication where the current interface provides one. A silent indicator supports checking capture and mute state; an active indicator means some signal is reaching that stage, not that the far end received intelligible speech. Ask for a brief verbal confirmation from another participant.

Check the physical microphone mute control, the meeting mute control, and browser permission for the Meet site. In Chrome, the address-bar site controls expose permissions, though the icon's appearance changes over time. Grant access only to the meeting site you intend to use. A permission denial concerns access, not the health of the microphone capsule, so do not treat it as a reason to purchase replacement hardware.

Operating-system privacy is another layer. Windows 11 places microphone permission under Settings, Privacy and security, Microphone, including controls relevant to desktop apps. macOS uses System Settings, Privacy and Security, Microphone for application access. Wording varies with release and management policy. If an administrator controls the setting, contact them instead of attempting to override organization restrictions.

Use MeterSee Microphone Test as a separate capture comparison if needed. Select the intended microphone, allow access to that site, speak briefly, and stop. The current tool analyzes browser-delivered samples locally; it is not a recorder or a Meet transmission test. A moving level there supports that capture works in that browser context. It does not transfer permission to Meet or prove which device Meet selected.

When only a presentation is silent

First confirm that ordinary conversation works in both directions. If it does, leave those working devices alone and examine the presentation route. Sharing a visual window does not by itself establish that its sound is being shared. In the sharing picker, inspect the actual audio option associated with the selected tab, window, or screen. Confirm the intended source before starting playback of a short nonprivate sample.

Google's current desktop presentation instructions describe tab audio sharing and, where supported, an option to include system audio with a window or entire screen. Availability depends on the browser, operating system, meeting context, and rollout. Do not rely on older blanket advice that every desktop presentation must be tab-only, or assume that every device exposes system-audio sharing. If the system option is absent, a supported tab-audio workflow may still be available.

System-audio sharing can expose notification sounds and audio from unrelated applications. Close private media and silence unnecessary notifications before enabling it. Prefer the narrowest source that meets the presentation's needs. Ask one participant to confirm the short sample, then stop it. Their confirmation establishes that the selected presentation route worked at that moment, not that every application on your computer will be shared identically.

If the host or organization disables sharing, changing headphone or microphone settings will not remove that restriction. Likewise, a mobile app can have different sharing capabilities from the desktop browser. Consult the current platform-specific presentation help and use the controls actually displayed. Preserve a working conversation path while resolving the presentation issue instead of restarting every audio device.

Use restarts and comparisons deliberately

When routing and permission appear correct, leave the meeting, close unnecessary microphone-using applications normally, and rejoin once. If that fails, save work and restart the browser through its documented procedure. Record whether the device list or permission prompt changed after restart. A recovered session is useful, but the restart alone does not identify the original cause; note it as a temporary recovery if the symptom later returns.

Compare a second supported browser only if you can sign in and join appropriately without bypassing policy. Keep the same devices and meeting so the browser context is the main change. A successful second browser points toward a browser-specific configuration or compatibility difference, not proof that the first browser is inherently unsuitable. Private browsing is not a guarantee of an unmanaged or extension-free environment.

Do not run terminal commands copied from a generic audio checklist during an important call. Audio-service restarts and driver changes can interrupt other applications and require administrator privileges. If ordinary selection, permissions, and a planned restart do not resolve the issue, collect the evidence for your administrator or support team. More invasive changes deserve device-specific instructions and a suitable maintenance window.

Hypothetical cases: three meanings of no sound

Hypothetical case one: a laptop is connected to a meeting-room display. MeterSee's tone comes from the display rather than the user's headset, and Meet is also inaudible at the headset. Selecting the intended headset restores both. The evidence supports an output-routing mistake in that setup. It does not suggest that microphone permissions needed changing, and no claim about network quality follows from the result.

Hypothetical case two: a participant hears the meeting clearly, but their own activity indicator remains still. A separate microphone check succeeds after site permission is allowed, while Meet still shows a blocked microphone. Granting permission specifically to Meet and rejoining restores speech. The important distinction is that permission belonged to each site; success on the diagnostic page had not authorized the meeting page.

Hypothetical case three: everyone hears the presenter speak, but a video in the shared window is silent. The presenter checks the sharing picker and finds that audio was not included. They choose a supported audio-sharing route and a participant confirms a short sample. The successful conversation path was never broken. Reinstalling an audio driver would have added risk without addressing the missing sharing selection.

Frequently asked questions and a support handoff

Does a green local test mean my meeting is ready? It means only that the measured or manually confirmed local checks met their stated conditions. Meet has its own device selections, permissions, call path, and participants. Finish with a real two-way confirmation in the meeting you intend to use, especially after switching docks or headsets. Do not equate a generated tone with successful remote communication.

Should I allow every website to use the microphone? No. Grant access to the specific trusted sites and applications you need, and preserve unrelated privacy choices. If a page cannot request capture because the environment is unsupported or policy blocks it, investigate that limitation. Broadly opening permissions is neither necessary nor a diagnostic proof that the microphone works.

What if I have no second device or willing test partner? Complete the local checks you can and label the missing comparisons explicitly. You can establish that a tone is audible or a browser receives microphone samples, but remote reception remains unverified. Use meeting chat to arrange a brief confirmation later rather than representing an unperformed call test as passed.

Send support the platform, browser version, device names, meeting mode, direction of the missing sound, and the last change before it began. Include which local and Meet tests worked, whether another participant confirmed the result, and whether the issue affects conversation or presentation only. Remove meeting links, participant names, and private screen content from screenshots. A concise path-specific report is more actionable than a list of unrelated attempted fixes.