Google Meet sound not working when presenting: what the tab shares

The slides are up, the video plays, the picture reaches everyone, and then the chat fills with the same message from four people at once. No sound. The presenter can hear it perfectly, which is the detail that makes the problem so hard to diagnose live: nothing on this side of the call indicates that the audio never left.

Almost every instance of this comes down to one decision made seconds earlier, in a dialog that most people click through. Google Meet treats a browser tab and a window as two different kinds of share, and they do not carry audio the same way.

The rule that explains most of these calls

Google states it plainly in the instructions for presenting. To share audio from a presentation, present a tab and have the option to also share that tab's audio turned on. Presenting a Chrome tab shares the tab's audio by default, so a video played inside the shared tab is heard by everyone without any further action.

Presenting a window or the entire screen is a different path. Audio is possible, but it is not on by default: the option to also share system audio has to be enabled in the selection dialog before the share starts. Turning it on after the fact is not offered, which is why the usual sequence is to stop the share, start again, and tick the box this time.

A tab carries its own audio. A window carries the whole system's audio, and only if that is switched on before sharing begins. That single sentence resolves the majority of these incidents.

There is a second consequence of the same rule, and it is the reason experienced presenters share tabs. A video played in a media player on the desktop, or a slide deck running in a desktop application, is not inside any tab, so its audio has to travel as system audio. Opening the same file in a browser tab and sharing that tab moves the audio onto the reliable path.

The macOS version requirement almost nobody mentions

Here is the fact that turns a five-minute problem into a thirty-minute one. Google's screen-sharing troubleshooting notes that sharing audio for a window or desktop share requires macOS 14.2, Windows 11, or newer.

On an older macOS release, the toggle for system audio either does not appear or does nothing, and the presentation goes out silently while everything on screen looks correct. No error is shown to the presenter. The version can be checked from the Apple menu, under the item that reports what the Mac is, and the answer decides the strategy: on macOS 14.2 or later a window share can carry audio, and on anything earlier the only supported route for audio is a tab.

This also explains why the same person can present with sound from one machine and without sound from another, and why advice found in forums contradicts itself depending on when it was written. The capability is tied to what the operating system exposes to the browser, not to the meeting.

What a tab share gives up in exchange

Presenting a tab is the reliable route for audio, and Google recommends it for full functionality, but the two kinds of share are not otherwise equal. Google publishes a feature comparison, and it is worth knowing before choosing.

Capability	Chrome tab	Window or entire screen
Sharing audio	Yes	Yes, with system audio enabled and macOS 14.2 or newer
Viewers can scroll the shared content	Yes	No
Annotation	Yes	Yes
Controlling Google Slides from inside the meeting	Yes	No
Viewers can zoom in and out	Yes	No
Full screen for viewers	Yes	Yes
Viewers can pop the share out into its own window	Yes	Yes

The pattern is that everything interactive belongs to the tab share. Scrolling, zooming and Slides navigation are all tab features, which makes the tab the right default for a document review and the wrong one for demonstrating an application that is not a website.

Google adds one limit that matters for large sessions: a meeting can carry a maximum of ten simultaneous presentations.

Companion mode, where the microphone was never there

A separate failure looks like a presenting audio problem and is not one. Google documents that clicking the present control in the green room, before joining the meeting, joins in Companion mode, and that in Companion mode the microphone and speaker are unavailable.

Someone who joined that way can present perfectly well and cannot be heard, and cannot hear anyone either. The audio troubleshooting article gives the remedy: leave the meeting and rejoin it normally. Because the symptom is silence in both directions rather than only on the shared content, it is easy to separate from a tab audio problem once the possibility is in mind.

The green room is also where the wrong device gets selected. Google's audio checklist covers the rest: pick the correct microphone or speaker, and if an external monitor is connected, make sure it is not the selected audio output, because a monitor with no speakers will happily accept the audio and play nothing.

The permission layer on recent macOS releases

On newer macOS versions the operating system stands between the browser and both the screen and the system audio, and it asks once.

Google's instructions are explicit for macOS Sequoia: choose to allow when Chrome asks for permission, and expect a cautionary prompt the first time a meeting is recorded or a screen is shared. Missing that prompt, or dismissing it during a meeting that had already started, means going into system settings afterwards to give the browser access to screen and system audio recording by hand.

Two habits help here. Grant the permission outside a real meeting, in a test call, so the prompt is not competing with an audience. And when a permission has been changed, restart the browser fully: Google's screen-sharing article notes that closing Chrome is not enough to reset permissions and points at the restart entered in the address bar as chrome://restart, which reopens tabs and windows afterwards.

Echo, doubled audio, and the output device

Sharing system audio introduces a problem that sharing a tab mostly avoids. The meeting's own audio is part of the system audio, so a careless setup sends the meeting back into itself.

Google's guidance is to enable the system default audio output device to avoid echoes when sharing system audio in a meeting. In practice that means letting the browser and the meeting agree on one output rather than routing one of them to a virtual device or a second interface. Presenters who use audio routing software for recording are the group most likely to hit this, because the loopback device that captures the audio is also the device the meeting plays into.

The related advice from the same article is about the picture rather than the sound, and it prevents a familiar hall-of-mirrors effect: share a new window or a specific tab rather than the meeting window itself.

One more case belongs here. Google notes that members of an adaptive audio group cannot share a window or the desktop at all, and that system audio sharing is unavailable in that situation, while sharing audio from a tab still works. For a meeting held in a room with several laptops joined together, the tab share is again the answer.

A rehearsal that catches this in ninety seconds

The reason this problem keeps recurring is that it cannot be seen from the presenter's seat. Nothing on the sharing side reports that the audio was dropped, so the first feedback arrives from the audience. A short solo rehearsal removes that blind spot, and it is worth making it a habit before any session where sound matters.

Start a meeting alone from the meeting homepage and join it normally rather than through the present control in the green room, which would put the session into Companion mode. Share whatever will be shared on the day, in exactly the form it will take: the same tab, or the same application window. If a window share is planned, enable system audio in the dialog and watch whether the option is available at all, which is the fastest way to find out what the operating system on that particular Mac supports.

Then join the same meeting from a phone, on cellular data rather than the same network, with its speaker on and the laptop's microphone muted. The phone is the audience. If the video plays and the phone stays silent, the audio path is broken and there are minutes rather than seconds to fix it. Two minutes spent this way replaces the conversation that otherwise happens in the chat window in front of everyone.

When it is not the share at all

A few checks sit outside the presenting path and are worth a glance before the meeting is abandoned.

Sharing can be switched off above the presenter's head. Google notes that screen sharing may be disabled by administrator settings in a Workspace organisation or by the host controls of the meeting, in which case the control itself is unavailable rather than silent.

Audio cannot be shared from a phone or tablet. Google states that mobile devices cannot share audio, and that sharing audio from a presentation on a computer requires sharing a tab. A presenter who has switched to a phone because the laptop was misbehaving has therefore changed the problem rather than solved it.

Finally, the speaking indicator gives a fast read on who has the problem. Google points at the indicator on the video tiles: if it lights up when someone speaks and nothing is heard, the fault is on the listening side, and if it never lights up, the fault is on the sending side. The same logic applies to a shared tab, where the audio meter moving while the room stays quiet means the share is fine and the output device is not.

Meetings that live in a tab among thirty other tabs make all of this harder than it needs to be, because the tab being shared, the tab making noise and the tab holding the meeting keep changing places. Keeping the meeting service in a window of its own makes the tab-versus-window question trivial to answer, and keeping the documents and players that get presented in separate app workspaces means the thing being shared is always a recognisable window rather than the twelfth tab from the left.

What to change first

Before the next presentation, check the macOS version from the Apple menu. On macOS 14.2 or later, a window share can carry audio once system audio is enabled in the dialog; on anything earlier, plan to present a tab every time audio is involved. Then run a one-person test meeting, grant the screen and system audio permission there rather than in front of an audience, and give the meeting service its own window, which is the arrangement SpaceDeck is built around.