Google Meet Audio Not Working: Output, Input and Permission

The call is running. Six faces are on screen, mouths are moving, and the Mac is silent. Or it is the other way round: everyone else is perfectly audible, and the chat panel fills up with people typing that nothing is coming through.

Those are two different faults with two different fixes, and most advice on this problem treats them as one. There is a third fault underneath both of them, which is permission, and it behaves differently from the other two because nothing in the Meet interface tells you it is the cause. Sorting out which of the three is in play takes about fifteen seconds and saves the ten minutes usually spent clicking through settings at random while a meeting waits.

Work out which of the three faults you have

Every audio failure in Meet lands in one of three layers. The layer is identifiable from what other people in the call report, not from anything on your own screen.

What is happening	Which layer is broken	Where to look first
You cannot hear anyone else	Output	Meet's Speaker selection, then the Mac's output device
Nobody can hear you, and your mic icon shows no movement	Input	Meet's Microphone selection, then the Mac's input level
Nobody can hear you, and Meet shows no microphone at all or refuses to list one	Permission	The browser's site permission, then macOS Privacy and Security
Audio worked, then stopped in the middle of the call	Device change	A headset connecting or disconnecting, or a tab reload

The distinction that matters most is between the second and third rows. An input fault means Meet has a microphone and picked the wrong one. A permission fault means Meet was never handed a microphone to pick from. The symptom looks identical from the inside, which is why people spend time in device menus that cannot possibly help.

Google's own instruction for checking this is in the join screen rather than inside the call. On the preview tile before joining, clicking Microphone and speaking should move a level bar. If the bar moves, the input layer and the permission layer are both fine, and anything still wrong is on the output side or at the other end of the call.

Output: what the Mac is sending sound to

When other people are audible to each other but not to you, nothing about your microphone is involved.

Start inside Meet, because Meet keeps its own device selection separate from the rest of the Mac. Click the arrow next to the speaker icon, pick the output device, and use Test speakers to send a sound through it. That test is the useful part. It proves the path from Meet to that device works, independently of whether anyone in the call is talking.

Meet also has its own volume control, separate from the system volume. The volume icon in the control bar at the bottom of the call adjusts what comes out of Meet specifically, so a muted call can sit inside a Mac whose speakers are perfectly loud.

Then check the Mac. In System Settings, under Sound, the output device is listed with its own volume slider. Two things go wrong here regularly. The first is a Bluetooth headset that connected while the Mac was asleep and claimed the output without claiming the input, so sound is going to a headset sitting in a drawer. The second is an external display connected over HDMI or USB-C, which registers as an audio output device and silently becomes the default when plugged in.

If the output device is right and the test sound still does not play, the remaining candidate is the browser itself rather than Meet. Quit the browser completely, using Quit rather than closing the window, and reopen it. A browser process that has lost its audio output after the Mac woke from sleep does not always recover it while it is still running.

Input: the microphone Meet actually picked

Meet lists every input device the system reports and remembers the last one chosen, which is how a working Mac ends up sending silence.

Inside a call, click the arrow next to the microphone icon and look at what is selected. For more detail, use More options, then Settings, which opens the Audio panel. A device that was unplugged since the last call can still be the stored selection, and Meet will not warn about it.

Then confirm the Mac agrees. In System Settings, under Sound, the Input tab shows the selected device and a level meter. Speak and watch the meter. If the meter moves, the Mac is receiving audio and the fault is between the Mac and Meet. If the meter does not move on any listed device, the fault is below Meet entirely and no amount of work inside the browser will fix it.

Two hardware cases account for most of the remainder. USB microphones and interfaces that are bus powered sometimes enumerate without providing a signal after the Mac wakes; unplugging and replugging is the fix, and it is not a Meet problem. Bluetooth headsets have separate input and output profiles, and a headset connected for output only will leave the built in microphone selected, which is often fine but produces the wrong result in a shared room.

Google's stated requirements are relevant when everything looks correct and audio is still breaking up rather than absent. A dual core processor and 2GB of memory are the stated minimum, with 10th generation Intel i3, i5 or i7 class chips, or AMD 3000 series Ryzen, given as the minimum recommendation for high quality video alongside other work. A Mac at the floor of that range can drop audio under load without any setting being wrong.

Permission: the layer with no symptom of its own

This is the fault that wastes the most time, because the Meet interface presents it as an absent microphone rather than as a denied request.

Permission has two levels on a Mac and both have to be granted. The browser needs permission from macOS, and the Meet site needs permission from the browser. Denying either produces the same empty device list.

For the site level in Chrome, the path is Settings, then Privacy and security, then Site settings, then Microphone. Sites that were allowed and sites that were blocked are both listed there. Selecting the site name lets the setting be changed back to Allow, and Delete next to a site clears the stored answer so the prompt appears again on the next visit. The same page has a down arrow for choosing the default device. When a site is asked afresh, the prompt offers choices along the lines of allowing while visiting the site, allowing this time, or never allowing, and the third of those is the one that quietly creates this problem months later.

For the system level, the path is the Apple menu, then System Settings, then Privacy and Security in the sidebar, then Microphone, where access is turned on or off per app. Apple's note about this list is worth knowing: if no apps are listed, nothing installed has asked for the microphone yet. An app that has never asked does not appear, so an empty row for a browser is a sign that the request never reached macOS.

Changing a system permission for an app that is already running is where people conclude the setting did not take. Quit the app fully and open it again. The permission is read when the app starts using the device, and a running browser can hold the earlier answer for the rest of its session.

What changes mid call, and why

Audio that worked for twenty minutes and then stopped is a different investigation from audio that never worked. Something changed, and there are only a few candidates.

A headset connecting is the most common. Bluetooth devices announce themselves when they come into range or come out of a case, and the Mac can switch the default input, the default output, or both. Meet follows the system default for a device it has not been given an explicit selection for.

A tab reload is the second. Chrome's Memory Saver deactivates tabs that are not in use, and an inactive tab reloads automatically when it is opened again. Google's documentation lists the exemptions, and tabs with active audio or video, an active screen share, or a connected device are not deactivated. A Meet tab in a call is therefore protected. A Meet tab sitting open in the join screen, waiting for a meeting that starts in twenty minutes, is not. The setting lives under Settings, then Performance, and the list named Always keep these sites active takes sites that should never be deactivated. Energy Saver, in the same place, turns itself on when the Mac is unplugged or the battery is low and reduces background tab activity, with video conferencing and audio playing tabs excluded.

The third is a second application taking the device. Anything that opens the microphone can hold it, and a recording app or a second meeting left running in another window is a frequent cause of a Meet tab that lists the right device and receives nothing from it.

The browser shape that makes this recur

There is a structural reason this problem comes back for people who run several web applications in one browser.

Site permissions are stored per browser profile. A Meet tab opened in a different profile, or in a guest window, starts with no stored answer and asks again, and an answer given in a hurry while a call is starting is the one that has to be undone later. Extensions that manage tabs, mute backgrounded pages, or route audio add another layer that behaves differently between profiles.

Keeping a meeting application in its own window with its own container changes the failure mode. The permission answered once for that container stays answered, the page is not competing with thirty other tabs for the browser's attention, and the application is a separate entry in the macOS privacy lists rather than sharing one with everything else the browser does. A browser designed around one isolated space per web app treats a call the way a native meeting app is treated, and the feature list covers the parts that matter here: a container per application, one notification bell instead of a badge buried in a tab strip, and a side rail that keeps the call reachable with a keystroke. Meet is on the list of applications it is set up for.

What to change first

Use the join screen, not the call: click Microphone, speak, and watch whether the level bar moves. A bar that moves means the fault is on the output side, so go to Test speakers next. A bar that does not move, with no device listed, means permission, so check Site settings then Privacy and Security, and quit and reopen the browser after changing anything there.

If the meeting tab keeps getting lost or reloaded in a window holding a dozen other services, the call is not the thing to fix, and SpaceDeck exists for the other half of that problem.