audioLatencyMs, the hidden macOS AirPlay latency setting

Updated 2026-10-06

Ask AI ChatGPT Claude Perplexity AI Mode Grok

audioLatencyMs is an undocumented integer preference in the com.apple.airplay domain that overrides the 2000 ms buffer macOS uses for AirPlay system audio. It's read by the root process AirPlayXPCHelper, so it must be written as root, and it only applies after that process restarts. Values below 350 ms are not safe.

Where macOS reads it

AirPlayXPCHelper runs as root and reads the preference from root's preferences (/var/root/Library/Preferences/com.apple.airplay.plist), then from /Library/Preferences. Your own user preferences are never consulted, which is why defaults write without sudo does nothing. Its log confirms the override: Overriding audio latency: 350 ms. Both findings come from the Preroll research notes and match our own logs.

Setting it by hand

sudo defaults write com.apple.airplay audioLatencyMs -int 350
sudo killall -9 AirPlayXPCHelper

The engine is built once per process, so the second line restarts it; launchd starts it again on demand. Your AirPlay speaker disconnects, so choose it again from Control Center. Preroll notes that a plain killall sometimes leaves the process running, hence -9.

Checking it

sudo defaults read com.apple.airplay audioLatencyMs

Removing it

sudo defaults delete com.apple.airplay audioLatencyMs
sudo killall -9 AirPlayXPCHelper

Things to watch

Lagless wraps exactly these steps in a menu bar app: one approval instead of sudo each time, a range check, the speaker's live delay, and an undo.

Questions

Is it safe to use?

It's a preference macOS already supports, and removing it restores the default. The risk is choosing a value too low, which mutes AirPlay until you raise it.

Does it work for AirPlay from inside apps?

It changes the system-wide AirPlay audio path. Apps that send AirPlay themselves manage their own timing.

Sources