Route Mac app audio to different outputs, then prove it

A selected route is configuration evidence. Play a known sound and verify the physical speakers or headphones before trusting that route after a dock, display, Bluetooth, or AirPlay change.

Published May 13, 2026 Updated September 5, 2026 By John Sciacchitano

Use macOS Sound settings when every app should use one output. Use an app's own device picker when only that app needs a special destination. Use Apple's Multi-Output Device when the same system mix should play through several devices. Use a per-app router when different apps need different outputs.

TeenySound is my narrow per-app mixer and router. Its current source saves selected device identifiers by app, creates a separate Core Audio route for every selected device, and uses the current default output when a saved custom device is unavailable. That last behavior makes an audible acceptance test necessary.

The Mac display and audio acceptance guide covers the whole desk. This page stays focused on app routing.

Choose the narrowest routing layer

Need Use first Proof
Every app uses one device System Settings, Sound, Output & Input A known sound is audible only from the named device.
One app has its own output picker That app's settings The app plays on its chosen device while other apps follow the system output.
The same system mix on several devices Audio MIDI Setup, Multi-Output Device The same test sound reaches every included output.
Different apps use different devices Per-app router Each active app is heard only where intended.
System switching, effects, AirPlay groups, or preferred-device order A broader audio utility The tool reports and produces the required system-wide state.

Set and prove the system output first

Apple's Sound settings let you choose an output device, adjust supported output volume, change balance, and mute. Select the intended device and play a short, recognizable sound. Listen at the MacBook, display, speakers, and headphones so you know which physical output produced it.

If an external display keeps taking over, use the monitor-speaker output checklist before building a custom app route. Per-app routing cannot make a disconnected headset available or prove that macOS still sees it.

Apple's Audio MIDI Setup can create a Multi-Output Device for the same system audio on several devices. That is useful for duplication. It does not assign different apps to different destinations.

What the current TeenySound route means

TeenySound detects apps that are producing audio, groups helper processes with their parent app, and stores selected output device UIDs by bundle ID. An empty selection means the current default output. A custom selection creates one tap, aggregate device, and playthrough process for each app-and-device pair.

Selecting two outputs duplicates the same app stream to both devices. It does not split left and right channels or send different content to each destination. Each route can use its stored per-device volume.

If a requested custom UID cannot be resolved, the playthrough engine assigns the current real default device instead. The saved route can therefore name a headset that is no longer connected while the app is heard from current default speakers. This is a fallback, not confirmation that the intended route survived.

Run the per-app routing acceptance test

  1. Connect every intended output and confirm each appears in macOS Sound settings.
  2. Set the system output and prove it with a known sound.
  3. Start the exact app you want to route and play a recognizable loop or spoken sentence.
  4. Open TeenySound, find the active app, and select one target device.
  5. Listen at the target and every unselected device. Record what is audible, not just what the menu shows.
  6. Add a second device only if you want the same app stream duplicated. Verify both outputs.
  7. Return the app to the default route and confirm normal playback.

Apps appear when they produce audio. A silent or closed app is not a useful test source. TeenySound keeps a recently active app briefly to avoid UI flicker, so use the sound you can hear as the final evidence.

Test disconnect and reconnect behavior

After the first route passes, stop the app, disconnect the target device, and start the app again. If audio comes from the current default output, that matches the source fallback. It does not prove the missing device route worked.

Reconnect the device, confirm macOS sees it, and reselect or reapply the intended route. Play the known sound again. This test matters after moving between a dock, display speakers, a USB interface, Bluetooth headphones, or another desk.

For a route that should follow the default output but keep a different volume at each desk, use the separate per-output-device volume guide.

Diagnose the failed layer

Symptom Check and acceptance result
The app does not appear. Play audio in that app and confirm System Audio Recording permission is granted.
A device is missing. Open Sound settings. If macOS does not list the device, no saved app route can target it.
The intended device is selected but another device plays. Check whether the saved target disconnected. The current source can fall back to the default output.
Two selected devices play the same app. That is expected duplication. Deselect one device if you wanted a single destination.
A route remains silent. Return the app to default output, prove basic playback, then rebuild one custom route.

Know when another option is better

Use an app's own output picker when it solves the whole need. It avoids another audio layer. Use Apple's Multi-Output Device when one system mix should reach multiple outputs.

TeenySound is a narrow fit for per-app volume and selected output routes. Rogue Amoeba's SoundSource is the broader choice when you also need system-device switching, AirPlay routing, audio effects, output groups, or preferred-device order. Its official product page and manual document those features.

Use monitor controls or a KVM when the real problem is a display input, then rerun the audio test after the picture returns. The related Mac monitor input switching guide explains why a sent DDC command is not a verified display result.

Permission and privacy boundary

Per-app routing needs access to outgoing app audio. TeenySound uses Apple's Core Audio process-tap APIs on macOS 14.2 or later. Its current tap configuration mutes the captured app on the original path and plays it through the selected aggregate-device route.

The permission label refers to System Audio Recording. TeenySound's public privacy claim is that it processes audio locally and does not record or transmit audio. The permission guide explains the system prompt and the local source path before you approve it.

Common questions

Does a saved TeenySound route guarantee the app is using that device?

No. A saved route records the intended device UID. Prove the result while the app is playing by listening at the selected output and checking that unselected outputs stay silent.

What happens if a saved output device is unavailable?

In the current local source, TeenySound's playthrough engine uses the current default output when a requested custom device UID cannot be resolved. Reconnect the intended device and test the route again.

Does selecting two outputs split an app's audio?

No. The current source creates one route for each selected device, duplicating the same app stream to both. It does not split channels or send different content to each output.

Sources checked

Save the route, then prove the sound.

teenysound is a $9.99 Mac menu bar app for per-app volume, mute, and output routing. Its 3-day trial lets you run the device and reconnect tests before buying.