Input Capture

MZAP can capture live audio from input devices and route it through the matrix router like any other player.

Input Types

• WASAPI input — Microphones, line-in, and other recording devices
• ASIO input — Individual channels on ASIO audio interfaces, or an adjacent pair captured as true stereo
• Loopback — Capture the output of another audio device (what-you-hear). Requires the Device Loopback license feature.
• Process loopback — Capture audio from a specific running application (e.g. Spotify, Chrome). Requires the Process Loopback license feature.
• AirPlay input — Receive audio from an iPhone, iPad, or Mac. Requires the AirPlay license feature.

Microphone and line-in capture is available on every license.

How It Works

Each input source is a dedicated player in MZAP that can be routed to any combination of output zones using the standard matrix routing.

Creating an Input Player

Input players are created on demand from the Players view Create dropdown (microphone, line-in, and ASIO inputs are no longer auto-created one-per-channel at startup):

• Add input… — opens a dialog with two dropdowns: the input device, then the channel (All channels, or a specific channel index for multi-channel/ASIO hardware). The name auto-fills from the device and channel when left blank.
• Capture system audio… — picks a loopback (system-audio) device/channel. Requires the Device Loopback license feature.
• Capture app… — per-application capture (see below). Requires the Process Loopback license feature.

Loopback players are also created automatically for the system-audio devices present when you create a demo workspace on first run — but only when the Device Loopback feature is licensed.

Capturing system audio in stereo

The Channel dropdown in the Capture system audio dialog offers All channels on any multichannel loopback endpoint, alongside the per-channel entries. Picking it captures the whole endpoint interleaved, so a single player carries true stereo.

All channels is preselected, since stereo capture is the common case. Previously the only choices were Channel 1 or Channel 2, and capturing both halves meant creating two mono players and routing each to the correct side — doubling the volume, EQ, and DSP state to keep in sync.

• The per-channel entries remain for mono captures.
• Mono loopback endpoints are unaffected — they show their single channel with no redundant "All channels" entry.
• A player created from All channels is named after the bare device (e.g. Speakers (Pebble V3)) rather than … - Channel 1.
• The Edit input source dialog can re-point an existing loopback player to, or away from, All channels.

Not a selectable pair

A loopback endpoint with more than two channels captures all of them, not a selectable stereo pair. Explicit pair selection (1-2, 3-4, …) is available for ASIO inputs but not yet for loopback.

To re-point an existing input or loopback player to a different device/channel, use the pencil (edit) button in its detail header — see Zones and Players. You don't need to delete and recreate the player.

Stereo Input Pairs (ASIO)

An input player on an ASIO device can capture an adjacent channel pair as a single true-stereo player — for example a Focusrite Scarlett's Analogue 1-2 pair, or its Loopback 1-2 pair.

In the Add/Edit Input Player dialog, multi-channel ASIO devices offer a Layout toggle:

• Mono — captures one channel. Because every player outputs stereo, that single channel is duplicated equally to left and right.
• Stereo — captures two adjacent channels as discrete left and right. This is a genuine stereo image, not duplication.

Channel dropdowns show the driver's own channel names (e.g. "Analogue 1", "Loopback 1"), so virtual and physical channels are easy to tell apart.

Stereo pairs must start on an even-aligned channel (1-2, 3-4, 5-6, …) and the whole pair must fit within the device's channel count. A stereo input player shows a Stereo badge on its card and gets dual-lane level meters.

Note

A mono input player and a stereo pair may share a physical channel at the same time — capturing channel 1 as mono and channels 1-2 as a stereo pair simultaneously is allowed.

Stereo pairs are ASIO-only; WASAPI input devices do not expose the required channel layout.

Use Cases

• Route a microphone to specific announcement zones
• Capture a DJ mixer output and distribute to multiple rooms
• Re-route audio from one device to another via loopback capture
• Pull audio from a single app while leaving other system sounds untouched

Per-application Loopback Capture

Process loopback captures audio from one specific application instead of the whole system. Only the chosen app's audio is picked up; everything else stays silent.

Requirements

• Windows 10 build 19041 (version 2004, May 2020) or later
• The Process Loopback license feature

Creating a capture player

In the create-player form, click Capture app audio… to open the picker. The list shows currently audible apps first (those with an active audio session), followed by other running apps with visible windows.

Capture always covers the selected application and its child processes — that is what every capture setup needs, and there is no option to change it.

If the target app isn't running yet, the player sits in an Attaching state and auto-attaches within about two seconds of the process appearing. To rebind an existing capture player to a different app, click the target-app chip next to the state badge in the player detail view.

Multi-process apps attach correctly

Apps that run several processes — Spotify, Chrome, Electron-based players — are captured from the top-level process of the application, preferring the instance that currently owns an audio session. Track metadata is read from that same process, so the name shown always belongs to the audio you hear.

This matters because Windows' process-tree capture covers a process and its children, never its parent. A capture rooted at a short-lived renderer child therefore carried no audio at all, while the track name still looked correct because it was read by executable name rather than from the captured process. The symptom was a player showing the right track and playing nothing — or, in a shared zone, seeming to play another player's audio because its own capture was silent.

• Existing capture players are repaired automatically on the next attach; no reconfiguration is needed.
• The stored process ID is refreshed to the top-level process on each attach, so capture keeps working after the target app restarts.

Recovery when the app restarts

Windows binds a capture to a specific process and does not follow the application across a restart. MZAP notices when the captured application exits, releases the dead capture, and re-attaches by itself as soon as the application comes back — normally within a few seconds.

• While the application is closed, the player shows the Attaching state and its track name clears, instead of appearing to play a track that has stopped.
• Players you stopped yourself are unaffected: restarting the target application will not start them again.
• This applies to every capture player and needs no configuration.

What the player tile shows

When a process loopback player is attached, its tile in the Players view shows the captured app's process name (e.g. Spotify.exe) on the top line and that app's main window title on the Now Playing line. Many media apps put the current track into their window title, so for Spotify, Chrome / YouTube, VLC, foobar2000, and similar players you'll see the track name appear automatically — no per-app integration required.

The window title is polled about once a second on the same tick that updates other player state. Titles that just echo the app name (e.g. a bare Spotify or Spotify Premium between songs) are suppressed so the line stays empty until a real track plays. The same behavior applies in the player detail view.

Limitations

• Only the default render endpoint is captured (per-endpoint selection is a future enhancement).
• DRM-protected streams (Netflix, Spotify PlayReady content) produce silence — Windows marks the capture buffer silent, and this cannot be bypassed.
• Attaching to an elevated target from an unelevated MZAP fails. Run MZAP elevated if you need to capture elevated apps.

Licensing for capture players

Both loopback capture types are license-gated, and the gate is checked when a player starts, not only when it is created.

Capture type	Feature	Included in
Microphone / line-in / ASIO input	—	Every license
Capture system audio (device loopback)	Device Loopback	Business, Subscription, Trial
Capture app (process loopback)	Process Loopback	See your license tier

What happens without the feature

• The corresponding item is shown but inactive in the Players Create menu, with a short line saying the feature is not included in your license.
• POST /api/players for that type returns 403 Forbidden, as do PUT /api/players/{id}/input-source and POST /api/players/{id}/play on such a player.
• Existing players are kept, not deleted. They simply refuse to start, and the player list shows the stop reason as a licensing refusal — distinguishable from a target application having closed.
• Loopback devices are skipped during automatic player creation — on first-run demo setup, on audio engine initialization, and when a device is hot-plugged — so you no longer get players that appear in the list but cannot start.
• Upgrading the license makes them work again with no reconfiguration, and takes effect immediately without restarting MZAP.

Personal licenses and device loopback

Device Loopback is not included in Personal licenses. If you created "capture system audio" players on a Personal license before this feature was gated, they will no longer start after upgrading. The players and their settings are preserved.

The licence is checked whenever a capture player starts, however playback was triggered — including by the scheduler, a workspace restore, resuming from sleep, or an AI client.