A remote guest,
on their own track.

The Mac podcast question is always the same: how do I record my own microphone and a guest who is on Zoom, as two separate tracks, without turning my audio setup into a science project?

For twenty years the honest answer involved a virtual audio driver and a diagram. In 2026 the common case does not. Here is what the setup actually looks like, and — importantly — which tool does which job, because conflating them is where most setups go wrong.

The one decision that matters: separate tracks

Record your microphone and your guest as two separate files. Never as one mixed recording.

This is not perfectionism. A mixed file cannot be un-mixed, and every problem you will actually hit — the guest is 6 dB too quiet, the guest coughs while you are talking, the guest has a fan you need to gate, you talked over each other and need to nudge one of you — is trivially fixable with separate tracks and impossible without them.

Everything below exists to serve that one decision.

The driverless capture path

Historically, getting Zoom's audio into a recorder on a Mac meant installing a virtual audio device: create a fake output, point macOS at it, capture what came out. It worked, and it cost you an admin password, a restart, a changed default output device and something left behind afterwards.

Apple shipped Core Audio process taps as a public API in macOS 14.2, and recorders adopted it. On macOS 13 and later, OBS can add a source that captures a single application's audio; dedicated recording tools do the same thing. That means:

• Track 1: your microphone, captured from the interface directly.
• Track 2: the call application — Zoom, Riverside, whatever — captured as an application, not as a device.
• No virtual device anywhere, and your default output stays your actual headphones.

Virtual devices have not become useless. They are still the right answer for genuinely complex routing — feeding audio between applications, or building a mix-minus so your guest does not hear themselves delayed. They are simply no longer the entry fee for a basic two-track remote recording.

A quality note worth knowing about

macOS was applying a strong low-pass filter to all audio captured this way, quietly dulling anything recorded through a system capture. Rogue Amoeba reported that macOS 26 Tahoe applies it far less aggressively — which for podcast use is one of the more consequential audio changes in years.

Tahoe 26.0 also broke capture in several situations before 26.1 repaired them, including captures failing when a secondary output device ran at a different sample rate from the system default. If you own an interface as well as built-in speakers, that is exactly your setup. The full accounting is in the Tahoe article. The practical advice: be on the current point release, not an x.0, and always check your test recording.

Where a per-app mixer fits — and where it does not

Be clear about this, because it is a common misunderstanding: MixPill does not record. It controls playback. Recording is a recorder's job.

What a per-app mixer is genuinely good for during a session:

• Your monitoring balance. Guest audio at a level you can respond to naturally, your own recorder's playback down, notifications from everything else muted. macOS gives you one volume for all of that; a mixer gives you one per app.
• Making a difficult guest easier to listen to live. A 5-band EQ and a noise gate on the call application alone — a little presence, less rumble, the gate closing on room hiss between sentences — makes a three-hour session much less tiring. It affects what you hear, not what the far end sends, so it cannot damage the recording.
• Silence, on purpose. Mute every app that is not part of the session, and save it as a preset you recall before each record.

What it is not for: fixing a guest's level in the recording. Do that in post, on their separate track, where it is a non-destructive edit rather than a decision you are stuck with.

If you record into a DAW

Anyone recording into Logic, Ableton, Pro Tools, Reaper or Studio One should be suspicious of any utility that sits between applications and the audio hardware. Buffer sizes and monitoring latency are set deliberately in a session, and a tool that taps your DAW is a tool that can change them at the worst moment.

MixPill handles this with DAW Direct: a switch on every row that keeps an application entirely out of the signal path. Not turned down, not processed at unity — never tapped at all. The major DAWs are covered by default and you can turn it on for anything else. It is free in both tiers, on purpose. The reasoning.

A working setup, start to finish

1. Microphone into an interface, headphones out of it. Never speakers — a guest hearing themselves back is the fastest way to ruin a recording.
2. Recorder capturing two tracks: your interface input, and the call application as an application capture.
3. In the call app: turn its own noise suppression down or off if audio quality matters more than convenience, and ask your guest to record locally as a backup — the single best insurance in remote podcasting.
4. In a per-app mixer: guest up, everything unrelated muted, EQ on the call channel if it helps you listen. Save as a preset.
5. Record 30 seconds and listen back before the real thing. Every time. This catches the wrong input, a sample rate mismatch and a muted track, which between them account for most lost recordings.

The unglamorous step 5 is the one that saves episodes.

Common questions