Terms as AudioHub uses them. Where a word has a looser meaning elsewhere, the definition here is the one the interface and this wiki mean.

The first section is words you can read off the screen. The rest are concepts the measurement pages depend on.

The three operating modes. They are mutually exclusive and machine-wide — not per peer. The picker is in Settings and labels them Share, A · Driverless and B · Virtual.

"Provider" and "consumer" are this wiki's shorthand for the two roles. Neither word ships in the interface — search for Share, Mode A or Mode B instead.

Full detail: Operating Modes.

Two different things that both concern how audio travels, and the interface keeps them apart on purpose.

• Connection method is what you choose on a peer's details page: Auto, Direct (UDP), TCP relay, or Single-link mux.
• Current path is what the service reports is happening right now, using the same three names.

They can disagree — you can select Auto and be told the current path is TCP relay. A greyed — for Current path means undecided or offline; it never means Direct.

This wiki's page for the subject is still called Transport Tiers, and internal names like tier1 exist in the code, but the words on screen are the ones above.

A third-party virtual audio cable — VB-Cable, BlackHole, Voicemeeter, Soundflower and similar — that AudioHub writes a peer's audio into, so other applications on this machine can select it as an input. AudioHub does not install one, and detection is not limited to any particular brand.

The label in Mode A is Audio bridge. Do not confuse it with the AudioHub virtual devices of Mode B, which are AudioHub's own driver.

See Operating Modes.

Which system-audio capture implementation is used when the sharing Source is System audio rather than Microphone. The row is labelled Backend and defaults to Auto.

The Settings switch that makes this machine discoverable by other AudioHub machines. It does not affect whether this machine can accept a connection, and it is separate from the AirPlay receiver's own Bonjour advertisement.

The 0 ms entry on the Latency setting — the first stop after AUTO, ahead of the numeric targets 10 through 1000 ms. It asks for the smallest buffer the link will hold; it is a target, not a guarantee. See Latency.

Two Mode B device options in Settings.

• Remove on disconnect — take a peer's virtual devices out of the system device list while it is offline, instead of leaving them present but silent.
• Mark names offline — append an offline marker to the device name while the peer is down, so the system list explains itself.

See Virtual device options.

A peer's virtual devices are confirmed present. The criterion is stricter than it looks: every requested direction must be acknowledged by the driver and observed in the system list, with no leftover extra. A peer that only has a speaker is Published once that one device is confirmed.

An acknowledgement without a visible device, or a visible device without an acknowledgement, each fail silently on their own — which is why both are required.

The tab holding the diagnostic views. Its cards are Latency (the per-stage waterfall), Fallbacks (degraded-link counters), Transport (a read-only overview of every peer's four transport settings), and a row of tiles — Uptime, IPC latency and the session count.

Two things to know before reading it. Counters that are zero are not rendered at all, so an empty area on a healthy link does not mean the feature is missing. And IPC latency is the round trip between the window and the local service — it is not the network time to a peer.

One step on the quality ladder — a (sample rate, bit depth) pair. Rung 0 is the highest quality; the number increases as quality decreases, matching the direction AUTO moves when a link degrades. See Audio Quality.

Two settings offer AUTO and they mean different things.

Quality AUTO behaves differently depending on how the audio is travelling:

The degraded ladder both starts and stops one rung lower, and it watches backlog rather than loss and jitter — on TCP, loss only appears after audio has already been dropped, so it is too late to be a downgrade signal. Do not quote the direct-link ceiling as if it were universal.

Latency AUTO adapts the target to measured network quality instead of holding a fixed figure.

Pinning a fixed quality rung does not just set a starting point: it stops the ladder entirely and the rung stays where you put it.

• Sample rate (kHz) — samples per second. Sets the frequency ceiling.
• Bandwidth (kHz) — the highest frequency that survives, always half the sample rate. Derived, never measured.
• Bit depth (bit) — precision of each sample. Affects noise floor only; it has no effect on bandwidth.
• Channels — AudioHub carries one mono channel. The Mode B virtual devices present as stereo to the operating system, but the wire is mono and every bitrate in the ladder is per mono channel.

16 kHz and 16 bit are different axes. Every quality label writes both.

The receive-side buffer that holds arriving audio frames briefly so that packets which arrive late or out of order can still be played in the right place.

Its depth is the single largest tunable contributor to latency. The latency setting is effectively a target for this buffer's depth, expressed as an end-to-end goal rather than a raw frame count.

The name is slightly misleading here. On our reference link, network jitter is 0.18 ms at p95 with zero loss — the buffer is not protecting against the network. What it absorbs is the sending process's own scheduling stalls. See Latency.

The moment of playback arrives and the buffer has nothing to deliver.

The criterion is exact and possibly counter-intuitive: an underrun occurs if and only if the specific next frame is missing — it does not depend on how full the buffer is overall. Losing one packet causes exactly one concealment whether the buffer holds 2 frames or 12.

Buffer depth therefore buys lateness tolerance, not loss tolerance. A packet that arrives late but within the buffer's depth still makes its slot; a packet that never arrives is an underrun at any depth.

After an underrun the buffer re-primes from a low water mark, which is why underruns tend to arrive in clusters rather than evenly spread.

Filling a frame that never arrived, instead of inserting silence. Silence is audible as a click; concealment usually is not.

The technique is a decayed repeat, not synthesis: the last real frame is replayed at 70 % of its previous level, and again at 70 % of that, for up to five consecutive frames — 50 ms. Beyond that AudioHub emits true silence and the count moves to the silence counter.

So the two counters mark a threshold, not a preference: a rising silence count means gaps longer than 50 ms, not merely more of them.

A weighted damage index, not a share:

(concealed + 3 ×ばつ silence + 0.5 ×ばつ half-frame concealed) / (played + concealed + silence)

It is not a percentage of the output and it is not capped at 1 — a stream that was half silence reads 1.5, not 0.5.

The weights are the point:

• Silence counts three times because concealment still carries energy and continuity while silence is a vacuum. ITU-T G.113 puts unconcealed frame erasure at roughly ×ばつ the impairment of concealed erasure.
• A half-frame concealment counts half. It fakes 5 ms out of a 10 ms frame, by the same decayed-continuation method as PLC, so it is worth half a PLC frame. Without this term a deep rung could lose half its packets and still grade as excellent, because the jitter buffer sees full-length frames and records no PLC and no underrun.

It is one of the three components of the quality grade.

Specific to the two deepest quality rungs, which split each 10 ms frame into two 5 ms packets on the wire. When only one half arrives, the receiver delivers the frame with the missing half concealed rather than waiting for it. See Audio Quality.

Three ways audio goes missing, with different causes:

• Underrun — the receiver had nothing to play.
• Dropped — a buffer was full and discarded something. Which end it discards (oldest or newest) changes what you hear: consistently late but continuous, or late and broken up.
• Stale — on a degraded link, a frame that has waited past its 440 ms budget is discarded deliberately before sending. This is not a new loss source; it is leaving the gap that lets the receiver's concealment work.

440 ms is not arbitrary: it sits between the degraded jitter buffer's deepest target (400 ms) and its hard ceiling (480 ms). Below that window AudioHub would throw away audio the receiver was about to play; above it, the receiver discards the same audio silently and nothing on the sending side can count it.

The app's own tooltip for this counter still says 200 ms. 440 is the value in the code.

Measured total latency minus the sum of all known stages. A persistently large value means there is a buffer in the path that AudioHub is not modelling. It is the completeness check on the latency figure, not an error term.

The displayed latency is a lower bound, because at least one stage that is known to exist could not be read accurately. It is never resolved by substituting zero.

Permanent for outputs whose platform API is known to report far less than the device genuinely adds: Bluetooth, HDMI, DisplayPort, AirPlay, Continuity wireless and aggregate devices. On Windows the device-period reading is treated the same way — one measurement had the API report 10 ms for an endpoint that took 41.9 ms. A reading that is present but wrong is not the same as a missing reading, and AudioHub refuses to launder either into a clean number. See Latency.

The curve mapping a volume slider position to actual gain. A slider at 50 % does not mean half the amplitude; what it means is decided by the taper, and every device may use a different one.

Distinct tapers have been measured across devices on both platforms, and on macOS alone. This is the reason loudness and slider position cannot both be synchronised, and it is a live consequence rather than a fixed bug: at the same slider position, real Windows hardware measured 8–11 dB louder than real macOS hardware. See Volume.

Three different quantities that all get loosely called "volume":

• Slider position — what you drag, 0 to 1. Device-specific meaning.
• Amplitude — the linear multiplier applied to samples. Mute is exactly 0.
• Decibels — logarithmic, closer to perception, but mute is −∞ and every device places its floor somewhere different.

An AudioHub peer link carries the slider position. Because each device applies its own taper, the same position is a different gain at each end — that is the entire content of the Taper entry, and it is today's behaviour, not a solved problem. Amplitude reaches the wire in exactly one case: the send-side software gain used when the peer's device exposes no writable volume, which the interface labels Peer volume unsupported · Using local software gain.

AirPlay is a separate contract. Its -30..0 control field is a linear slider coordinate, not a gain, and it must not be run through an endpoint's native dB taper. See Volume and Share Protocols.

Reading system audio without becoming the system's output device. AudioHub's system audio capture is always a side tap: your output device and its volume are never changed. The alternative — requiring you to point system output at a virtual device — is explicitly out of bounds for this project.

The reverse dependency is not symmetrical, and one backend bites. On Windows device loopback the tap sits after the master volume, so lowering or muting your own output changes what the peer hears — and the resulting silence looks like a network fault. The macOS taps are expected to be upstream of the master volume; Windows process loopback is unmeasured.

A digest of a machine's public key, shown in the interface and used to verify identity when connecting. Any machine that can reach the control port obtains it during the handshake anyway; it is displayed so you can confirm you are pairing with the machine you think you are. See Discovery and Pairing.

The one-time exchange establishing mutual trust between two machines, via a 6-digit PIN. Once complete, trust is bidirectional — each appears in the other's list — and it survives restarts and address changes.

Unpairing revokes trust on both sides, but the two sides learn at different times. This machine removes the peer's virtual devices immediately. The peer is told at once only if it is online; if it is offline it finds out the next time it tries to connect and is refused. Until then it may still list a pair of offline devices bearing your machine's name, with nothing in its interface able to explain them. See Discovery and Pairing.

Not to be confused with Pair-Setup, below. Both involve a PIN and neither has anything else in common.

A machine in Share mode serves several peers at once: its microphone is fanned out to all of them, and audio arriving from all of them is mixed into its output.

On the consuming side the limit depends on the mode:

• Mode A binds one peer at a time.
• Mode B publishes devices for every paired peer and several may be in use simultaneously — up to 16 peers, and therefore at most 32 devices. Publishing is per direction, so a peer with no default input contributes only one device, not two; 32 is a ceiling, not a count. A peer past the end reports capacity without disturbing the devices already published, and the real number of slots is negotiated with the installed driver, so a driver built with a smaller pool shows up as a lower capacity rather than a refused handshake.

AirPlay's own authentication, unrelated to AudioHub pairing above. An AirPlay sender proves it knows the receiver's PIN — which is the password you set on the receiver — through a cryptographic exchange that never puts the password on the wire.

If you set no password, the PIN falls back to the fixed public constant 3939. The receiver is then open to anyone on your LAN. Clearing the password does not turn authentication off; it opens the receiver up.

AudioHub uses the transient form: nothing is stored, and every session authenticates again. It is not the persistent HomeKit pairing that remembers a device permanently — that is a will-not-do, not a gap. See Share Protocols.

The shared clock AirPlay 2 uses to decide when a sample should be heard, rather than playing it on arrival. Both ends read the same timeline, which is what lets a sender specify an exact presentation moment.

AudioHub's receiver only follows this clock; it never tries to become the reference. If the clock cannot be set up, the receiver does not start at all — there is no mode where AirPlay runs without it. Another AirPlay-receiving process already holding the clock is the usual cause on macOS.

Two limits come with it. The receiver accepts one sender at a time — a second is refused with 453 Not Enough Bandwidth — and it is IPv4 only on both platforms. On macOS the clock comes from a private system service, which enforces the one-sender limit a second time.

The two ways an AirPlay 2 sender can deliver audio, and they behave differently enough that the receiver treats them as separate paths:

• Realtime — small ALAC packets over UDP, played close to arrival. This is what system-wide output uses when you send a whole Mac's sound somewhere.
• Buffered — AAC-LC sent ahead over TCP with a presentation timeline. This is what a music app uses. Because the sender is ahead, it can also ask for things realtime cannot support, such as changing playback rate or flushing what was already queued.

Both run behind one identity and one listener, and each accepts exactly one format with no fallbacks. See Share Protocols.