Mac presentation audio: local vs shared sound

The room and remote audience can hear different things. Set the Mac output, choose whether to share computer audio, then test both paths.

Updated Jul 29, 2026 7 min read By John Sciacchitano

Start with two separate questions. What should the room hear through the Mac's speakers or headphones? What should remote viewers receive through the meeting app's shared-audio control? Set and test both. Changing the local output alone does not prove that remote viewers can hear the source.

TeenySound is built for that app layer. It gives apps that are producing audio their own sliders, mute buttons, a mute-all shortcut, restore-all behavior, and per-app output routing. Use it when system audio is too broad, not as a replacement for the first macOS check.

This is the TeenySound spoke for the Mac presentation setup for display and audio. Pair it with Mac presentation display setup: mirror or extend? when the same presentation also depends on an external monitor. If the deliverable is a saved tutorial, use Mac screen recording audio levels: capture vs playback to separate the recorder's captured tracks from local monitoring and prove the saved file.

Quick audio decision table

Control What it changes How to test it
macOS Sound settings The Mac's local speakers, headphones, display audio, USB audio, or AirPlay output. Play the exact source in the room before joining.
Meeting app shared audio What remote viewers receive from the shared tab, window, or computer. Listen from a second device or ask another person to confirm.
Per-app volume The level of one audio-producing app without changing every other app. Keep the source audible and silence one unrelated app.
Alert volume Mac alert and interface sounds, separately from output volume. Trigger a harmless alert before the live session.
System audio permission Whether an app such as TeenySound can use Core Audio process taps. Confirm audio-producing apps appear before relying on the mixer.

01Choose the output before the app

Apple's Sound settings list the output devices available to the Mac: internal speakers, display speakers, wired audio, USB speakers, headphones, and AirPlay devices. Pick the real target before you open the meeting or recording flow.

Do this before joining. Meeting apps, browsers, and recording tools may cache device choices or need a restart of the share session after an output change.

If a connected monitor keeps taking over output, use the Mac audio switches to monitor speakers checklist before adjusting app levels for the presentation.

If you use display speakers, confirm the display is still selected after reconnecting the cable or waking the Mac. If you use headphones, confirm the Mac did not switch back to a monitor, dock, or AirPlay device.

02Choose what remote viewers should hear

The meeting app controls shared computer audio. Microsoft Teams uses an Include sound option and warns that notifications can be sent too. Google Meet's official help recommends presenting a Chrome tab for the broadest feature support; window and desktop audio on Mac require supported browser and macOS versions.

Do not infer the remote mix from the room. A clip can play through your headphones while remote viewers hear nothing, or the meeting can share alerts you did not notice. Verify the actual share from another device or with another person.

03Separate output volume from alert volume

A presentation can sound correct while alert sounds are still wrong. Apple separates output volume from alert volume in Sound settings. Use that separation.

For a demo, lower alerts or route sound effects away from the room speakers. For a recorded walkthrough, consider muting alerts entirely. For a live class, keep the source material audible but stop chat pings from becoming part of the lesson. The narrower live-teaching version is Mac workshop audio checklist.

This is where system mute is too blunt. It protects you from noise, but it can also silence the thing you are trying to present.

04Check the apps that can make noise

Presentation audio rarely comes from one clean source. A browser tab can autoplay, a music app can keep playing, a message app can ping, a video app can stay paused at a loud point, and the meeting app can have its own volume behavior.

TeenySound shows apps when they are producing audio. Its per-app manager tracks volume and mute state by bundle ID, and its mixer view exposes app sliders, app mute, output-device controls, and a system volume row.

The practical rule is simple: make the source app audible, then lower or mute every app that is not part of the presentation. If nothing else should make sound, use mute-all before you start and restore afterward.

TeenySound's per-app controls require Screen & System Audio Recording permission. The app uses Core Audio process taps, and its source blocks tap creation until macOS reports that permission as authorized. Confirm apps appear in the mixer before the presentation.

05Route only when routing solves a real problem

Per-app routing is powerful, but it is not the first fix. Use it when you need a call in headphones while a browser demo plays through speakers, or when a recorder should capture one app without room-notification noise.

The TeenySound source stores selected output device UIDs per app and remembers per-device volumes. That makes sense for repeatable presentation stacks. It is overkill if all audio should go to one headset.

For the deeper routing workflow, use route Mac app audio to different outputs. The presentation version is narrower: route only the apps the audience or recording needs.

06Run one room and remote audio test

Do not trust the slider position. Test sound.

Play the exact browser tab, video, audio clip, app demo, or recording source. Start the screen share and turn its shared-audio option on or off as intended. Listen in the room and from a second device. Watch which apps appear in the mixer, then lower what does not belong.

One minute is enough. If the test fails, you still have time to change the output, mute an app, switch devices, or use a simpler fallback.

Presentation audio checklist

  1. Open System Settings, Sound, then choose the output device.
  2. Set output volume and alert volume separately.
  3. Play the exact audio source in the room.
  4. Turn shared computer audio on or off inside the meeting app.
  5. Verify the remote path from another device or with another person.
  6. Open TeenySound if multiple apps can make noise.
  7. Confirm system audio recording permission if apps do not appear.
  8. Lower or mute apps that are not part of the presentation.
  9. Use per-app routing only if two apps need different output devices.
  10. Use mute-all as a temporary quiet state, then restore when the presentation is over.
  11. Repeat the test inside the meeting, recording, or screen-share mode you will actually use.

Sources checked

Common questions

What Mac audio settings should I check before a presentation?

Check the Mac's local output, output volume, alert volume, the meeting app's shared-audio control, app-specific levels, system audio recording permission, and the exact source inside the live presentation mode.

Does Mac output volume control what remote viewers hear?

Not by itself. Mac Sound settings control the local output. The meeting app decides whether computer audio reaches remote viewers, so test the shared-audio option from another device or with another person.

Why does TeenySound need system audio recording permission?

TeenySound uses Core Audio process taps to detect and control audio-producing apps. macOS protects that path with Screen & System Audio Recording permission, so per-app controls cannot work until access is granted.

Keep the presentation audio under control.

teenysound gives every audio app its own volume slider, mute control, output route, and quick mute-all shortcut. Native Mac app, $9.99 once, 3-day trial.