AirPlay Input

An AirPlay input turns MZAP into an AirPlay-compatible receiver. While the player is started it appears in the AirPlay picker on nearby Apple devices under a name you choose — "MZAP – Bar", say — and whatever the phone plays flows through that player into its zones, with MZAP's volume, EQ, ducking, and scheduling applied like any other source.

Create several AirPlay inputs to offer several named endpoints.

AirPlay input requires the AirPlay license feature. Personal licenses allow 2 AirPlay inputs; Business licenses are unlimited. Creation is blocked once you reach the cap.

Which AirPlay

MZAP implements classic AirPlay (RAOP) audio. AirPlay 2 multi-room grouping and AirPlay video are not supported.

Creating an AirPlay input

In the Players view, Create → AirPlay input… (admin only). Set:

• Advertised name — what Apple devices show in their AirPlay picker. Defaults to the player name.
• Follow sender volume — off by default, so the venue keeps control of levels. Turn it on if you want the phone's volume buttons to move the MZAP player's fader.

Start the player to begin advertising. Stopping the player removes the endpoint from the network.

What the player card shows

• The AirPlay badge turns green while a device is streaming to the player, and stays neutral grey while nothing is connected.
• The source line under the track title names the connected device, truncating with an ellipsis when long — hover for the full name. When the AirPlay endpoint name differs from the player name, it is appended in a dimmer style after the device name; if the two match it is omitted rather than repeating the card title.
• Hovering the AirPlay badge shows "<device> → <endpoint name>", so the name a phone sees in its picker is reachable from the card.
• The playback state badge (Playing / Stopped) is unchanged.
• The sender's title, artist, and artwork are shown when the sending app provides them.

The player detail screen shows the connected device and the endpoint name on separate lines, with the same green/grey badge.

Session state is reported as Idle, Advertising, Connected, or Error (with the reason).

Behavior

• Audio arrives about 2 seconds behind the sender. This is inherent to AirPlay's buffering, not a fault.
• One sender at a time. A second device attempting to connect while one is streaming is refused as busy.
• If the sender leaves Wi-Fi range, the session ends after 10 seconds and the endpoint is advertised again.

Endpoint password

Each AirPlay input can require a password before a device may connect. Set it in the player's AirPlay panel; leave it blank for an open endpoint, which is the default. Existing AirPlay players are unaffected.

• With a password set, the endpoint shows a lock in the iPhone/iPad/Mac AirPlay picker, and iOS prompts before connecting.
• Saving an empty password field removes the password.
• Changing or clearing a password re-registers the endpoint, which disconnects whoever is currently streaming. MZAP warns first and names the sender.

What the password does and does not do

A password prevents someone connecting by accident or curiosity. It is not strong security: AirPlay's password scheme is dated, it is one shared secret per endpoint, and the audio stream itself is not encrypted by it.

To keep guests off the venue's endpoints entirely, put guest Wi-Fi on a separate network — an endpoint is only visible to devices that can reach it.

Renaming

Renaming an AirPlay player while a device is actively streaming to it re-registers the endpoint on the network, so the current session ends: playback stops and the sending device has to reconnect. MZAP asks for confirmation first and names the connected sender.

Network requirements

AirPlay needs inbound network access. The installer's "Allow access from other devices on your network (LAN)" option — ticked by default — adds the required rules:

Protocol	Ports	Purpose
TCP	5100–5115	AirPlay RTSP control
UDP	6100–6195	AirPlay RTP audio
UDP	5353	mDNS service discovery

If AirPlay is not accepting connections, re-run the installer and make sure that option is ticked.

The failure looks like a broken device

Without the firewall rules, the endpoint is still announced and still appears in the AirPlay list on an iPhone or Mac — but every connection attempt is blocked by Windows Firewall. From the sender it looks like a device that simply refuses to connect, and nothing appears in the MZAP logs to explain it.

If these ports conflict with something else on the machine, contact support — the ranges are configurable.

API

Endpoint	Purpose
POST /api/players	type: "AirPlay" with optional airPlayName (defaults to name), airPlayFollowSenderVolume (default false), and an optional password. Returns 403 without the AirPlay feature, 409 when the license cap is reached.
PUT /api/players/{id}/airplay-name	{ "airPlayName": string|null }
PUT /api/players/{id}/airplay-follow-sender-volume	{ "airPlayFollowSenderVolume": bool }
PUT /api/players/{id}/airplay-password	{ "airPlayPassword": string|null } — null or empty clears it.
GET /api/players/{id}/artwork	The sender's artwork bytes, or 404.

The player DTO gains airPlayName, airPlayFollowSenderVolume, airPlaySessionState, airPlaySenderName, airPlayError, hasArtwork, and airPlayHasPassword. The password itself is never returned by any endpoint.

The SSE stream emits AirPlaySessionChangedEvent as a session's state changes. The MCP tool create_airplay_player creates an AirPlay input, and accepts an optional password.