The Peer Details Page

The peer detail page

One screen per paired peer, and the screen with the most controls in the app. Everything that is set per peer is here: the alias, the four transport targets, the connection method, the tunnel address, and unpairing. Nothing on it is global — the Settings page has no latency, quality or connection-method control at all.

How to get there. Click a peer's card on the Peers tab; the whole card is the button. From the Stats tab, the peer names in the Transport card link here too. The button at the top left, labelled Peers, goes back.

If you arrive at "Peer not found", the peer was unpaired, or the service has not returned the list yet.

---

The title row

A status dot and the peer's name, then two icon buttons and a status word.

Element	What it is
Dot + word	Online, Offline, or Reconnecting…. Reconnecting is a third state: the service is still dialling on a backoff, it has not given up
✎ Edit alias	Opens the alias sheet (below)
⚠ Open danger zone	Opens the unpair sheet (bottom of this page). It is red because it is the one destructive control on this screen; without the colour it reads as another settings icon

The name shown is the alias if you set one, otherwise the name the peer called itself at its last connection.

---

Alias

The ✎ button opens a sheet titled Alias with a single field, Name.

• The placeholder is the peer's own computer name — leave the field empty and that is what gets used.
• Up to 48 characters. Leading and trailing spaces are trimmed, and a name of nothing but spaces counts as no alias.
• Default clears the field, Save writes it, Cancel or Esc discards it. Save stays disabled until the text differs from what is stored. Enter saves.
• The sheet is one edit transaction: the page keeps refreshing behind it, but what you have typed is never overwritten by a refresh.

The alias renames the virtual devices, in place

The sheet says so on screen — "This also renames this peer's virtual devices in the system audio device list" — and the important half is in place:

The rename is applied to the same device UID. No device is removed and no new one is created, so an application that has already selected this peer's AudioHub device keeps that selection. Nothing in Zoom, OBS or the system's own sound panel needs re-picking.

The device's identity is its UID, which embeds the peer's fingerprint, not its name. That is also why a peer renaming its own computer does not disturb anything here.

Two consequences worth knowing:

• The visible device name is AudioHub – <label>, and the speaker and the microphone deliberately carry the same label. The direction is already carried by the system's own device class and icon. See Platform Notes.
• If two peers end up with the same label, the one paired first keeps it untouched and the later one gets (2). Renaming the incumbent because someone else paired a second identically-named laptop would change a device label for a reason its user could never connect to the event.

---

Connection

One card, in four parts, in this order: the four transport targets, the connection method, the virtual devices (Mode B only), and the tunnel address (conditionally).

The four transport targets

A two-by-two grid. Columns Latency and Quality, each with a ?; rows Send (↑) then Receive (↓), in that order because the peer card's metrics use the same order — that is how "the 300 I set" and "the 304 on the card" line up.

Each of the four cells is a slider showing the target, with a line underneath showing the measurement. The line never repeats the target back at you.

The slider	The stops
Latency	AUTO, then 13 fixed millisecond targets: 0 (Lowest), 10, 20, 30, 50, 75, 100, 150, 200, 300, 500, 750, 1000
Quality	AUTO, then the PCM rungs from PCM 16 kHz · 16 bit up to PCM 48 kHz · Float32. Opus stops are listed but refused by this build

Both stop tables come from the service rather than the app, so what you are offered is what this build can actually deliver. A stop the build cannot deliver is still drawn on the scale but cannot be selected, and says why. Full behaviour: Latency and Audio Quality.

A direction with no stream is not hidden. Both sliders stay on screen and stay usable; the line under each reads a dim No stream. This is the rule that most often looks like a bug and is not — you can set a target for a direction that is currently idle, and it applies when audio starts.

The other things that line can say:

Under the slider	Meaning
No stream	Nothing is flowing in that direction
Measuring…	A stream exists, but the reading has not converged yet — about ten seconds
Actual: N ms, optionally · Min or · Max	The measurement, with a marker when the servo has hit the physical floor or ceiling
48 kHz · 24-bit	Under a Quality slider: the live wire format, in the same units as the slider label above it
Unset · Auto	Share mode only — see below

Which rows appear. In Mode A and Mode B, only the directions the peer actually has: a peer with no default microphone has no Receive row at all. In Share mode both rows always appear.

A stop that no longer exists is not silently dropped. If the stored value is one this build does not know, the service resets it to Auto and the card says so in amber: Send Latency "…" is unavailable · Reset to Auto. A setting that disappeared while the interface stayed self-consistent is the failure this line exists to prevent.

In Share mode the sliders are disabled, and only two of them have a value

A machine in Share mode sets no profiles of its own — the peer using it does. The card says which peer, and then shows what that peer asked for:

Cell	Share mode
Receive latency	The value the peer pushed. This machine's receiving jitter buffer is the thing executing it
Send quality	The value the peer pushed. This machine's sending ladder executes it
Send latency, Receive quality	Unset · Auto — those two are executed on the peer's machine, so it has nothing to state here

The values are shown rather than hidden deliberately: hiding them would leave the person whose machine is being used with no way to see what is being executed on it. This machine's own stored targets are kept untouched and come back when you switch to Mode A or Mode B.

Connection method

Below the sliders, a heading Connection method with a ?, then the current reading, then four buttons.

The line above the buttons is the reading; the buttons are the choice. They are two different quantities and neither is allowed to impersonate the other. A peer set to Auto can be running on TCP relay right now, and the buttons will still say Auto — because Auto is what you chose.

The reading is labelled Current path:

Current path	Means
Direct (UDP) · Lowest latency and jitter	The bytes are on UDP
TCP relay · No UDP · Full features · May stutter	Degraded, in amber
Single-link mux · App-layer only · Shared send/receive link · Most likely to stutter	Degraded, in amber
—, greyed	Not determined. The line then says which of the two reasons applies: the service does not report connection methods, or the peer is offline, so there is no active path to identify. A dash is never a quiet way of saying "direct"

While the path is degraded, an evidence row appears under it: the link's address, whether the link is up, the send backlog, the timed-out drop count, and — on Single-link mux — the control frames carried on the shared connection. It also states plainly that this version of the service does not report why or when the downgrade happened, rather than leaving the space blank.

The four buttons are Auto (the default), Direct (UDP), TCP relay and Single-link mux. Each carries its consequence underneath. A pin takes effect immediately and beats the automatic detector — including pinning back to Direct. Single-link mux is a real, selectable choice and does not require a tunnel address; without one it multiplexes over plain TCP. All of this, including when the service moves between methods on its own, is on Transport Tiers.

A stored method this build does not recognise is reset to Auto with an amber line saying so, exactly like the sliders above.

Dial policy is not on this page

A peer also carries a dial policy — both (the default), outbound_only or inbound_only — which decides whether this machine may originate a connection to it. It matters on a tunnel that only carries connections one way, where the side that cannot originate otherwise keeps dialling a peer it can never reach.

There is no interface for it in 1.0.0. It is set from the command line, and must be written together with the connection method:

audiohub ctl peer-transport --peer <fingerprint> --tier tier2 --dial-policy inbound_only

A peer configured inbound_only is in a third state — not offline, but expected to arrive — and this page renders it as offline. See Which side dials.

Devices (Mode B only)

When this machine is set to Mode B, the Connection card also lists the virtual devices this peer is asking for — one row per direction, with the device's name, its UID, frames carried, and a state:

State	Meaning
● In use	An application is passing audio through it right now
○ Idle	Published and visible in the system list, nothing using it
○ Registering	Not yet confirmed by the driver, or not yet visible in the system list

Under the rows is one sentence explaining the current situation — the devices are ready, or the peer is offline so they stay listed but pass no audio, or the driver state plus whether every requested direction is listed yet. When a peer has no devices, that sentence is the reason why, and each reason has a different fix: the 16-peer limit is full, the driver is not installed, they were removed by Remove on disconnect, or the machine is not in Mode B after all.

The block appears whenever Mode B is requested, even if the driver failed to come up — that is exactly the moment the explanation is needed. It is not shown in Mode A or Share mode, and not shown for a peer that has advertised no audio capability at all. See Operating Modes and Settings Reference.

Tunnel address

The last part of the Connection card, and it only appears when it can do something: when Single-link mux is selected, when an address is already stored, or when the service had to clear an address it could not parse. A stored address you could not see would be one you could not clear either.

The field is Peer address (ws://), with Save and Clear.

• Empty: connections go to the IP:port recorded at pairing.
• ws://host[:port][/path]: outbound connections are wrapped in a WebSocket.
• wss:// is refused with a specific message, because the problem is not a typo — there is no TLS client compiled into this release.

With an address stored, everything this machine dials uses the single-link mux, whatever the four buttons above say, and the card states that override on screen rather than letting the picker look effective. Saving an address deliberately does not move the picker for you. Full detail: Transport Tiers.

---

Sessions

Every active stream with this peer, one row each: the stream's ID, what it is (with Peer-started and Virtual tags where they apply), direction, bitrate, rung, loss, jitter, volume and a check column.

The last column is a Close button — except for streams a virtual device created. Those read System-managed and cannot be closed from here: the application on the other side of that device would go on playing into a device that no longer makes sound, and nothing in the system would explain why. Stop it where you started it, or by changing the app's device selection.

The Check column is a tone verification result and stays — in normal use; it is only produced for streams opened from the command line with a verification frequency.

When there is nothing running, the card says "No active sessions with this peer." Live per-second numbers and one-minute history for the same streams are on the Stats tab.

---

Addresses

Every host:port this window has seen the service report for this peer, newest first, each with the time it was last seen. Before this window has observed anything, it shows the address the service currently has on file, marked Service.

Two things this list is not:

• It is not a fallback chain. When the service reconnects it resolves exactly one address — an explicit override if given, otherwise the single address it has recorded for the peer. It does not work back through this list. The list is here so you can see that a peer's address changed, which is the usual explanation for a peer that stopped reconnecting.
• It is not stored. The window builds it by watching the peer list; reloading the interface empties it back to the single service-reported address.

---

Identity

The peer's full fingerprint with a Copy button, then:

Field	What it is
Default port	The port this peer is dialled on
Paired	When the pairing was created
Key	The start of the peer's public key

This block is at the bottom of the page because checking a fingerprint is something you do on pairing day and essentially never again. What it is for is in Discovery and Pairing.

---

Unpairing

The ⚠ button in the title row opens a sheet called Danger Zone holding a single Unpair button, which then asks for confirmation a second time. The two are not redundant: the sheet guards against a mis-click, and the confirmation guards against a mis-judgement — it lists, by name, the actual virtual devices that are about to disappear from this machine, and warns that the system will switch away automatically if one of them is the current default.

Unpairing revokes trust in both directions and also clears that peer's four transport targets, so re-pairing the same machine later does not silently inherit settings from the previous relationship.

What happens on the other machine depends on whether it is reachable at that moment. The removal here is unconditional; the peer is told only if a control connection still exists when you press the button. A peer that is offline finds out the next time it dials and is refused. Until then its copy of this machine's virtual devices stays in its system list. See Discovery and Pairing.