Under the hood.

Transport — P2P, with relay fallback

SESSION AM is not purely peer-to-peer. It's P2P whenever the network allows it, with an automatic fallback so the session never just breaks.

Audio runs over WebRTC. The connection always attempts a direct P2P link first — broadcaster and listener exchange audio straight between browsers, with no server in the middle. This works whenever both sides are reachable through standard NAT traversal (STUN).

When a direct path can't be established — symmetric NAT, restrictive firewalls, certain corporate or mobile networks — the connection falls back to a TURN relay, run on Cloudflare's infrastructure. The relay only routes encrypted traffic between the two peers; it doesn't decrypt, inspect, or store anything that passes through it.

Codec — Opus, 48kHz, up to 510kbps

SESSION AM streams via WebRTC using the Opus codec, with raw, unprocessed capture on the broadcaster side.

The broadcaster captures audio at native 48kHz with all browser-side processing disabled (no echo cancellation, no noise suppression, no automatic gain control) — the signal reaching the encoder is clean and unprocessed.

Opus was developed by the IETF specifically to outperform older codecs across both speech and music — a combination most legacy codecs handle poorly. At the bitrates SESSION AM uses, Opus is considered transparent: in controlled ABX listening tests, trained listeners are generally unable to distinguish 510kbps stereo Opus from the uncompressed source. At comparable bitrates, it outperforms MP3 and AAC, and its real-time adaptive behavior — the same one used by Discord, Zoom, and WebRTC generally — is why it remains the standard for low-latency live audio (5–66ms encoding latency).

Where the ceiling actually is

Opus stereo has a practical quality plateau around 450–510kbps. Past that point, more bitrate doesn't buy more audible quality.

The real-world constraint on perceived quality is almost never the codec — it's the listener's network. A broadcaster on Ethernet or stable WiFi can sustain 510kbps without issue; a listener on congested mobile data may need a lower bitrate to avoid buffering. That's why SESSION AM exposes bitrate as an adjustable control rather than a hardcoded constant.

Could SESSION AM go lossless? Technically WebRTC can carry uncompressed PCM, but browsers don't expose simple APIs to negotiate this, and the bandwidth cost would be substantial for negligible perceptual gain at this bitrate. For a real-time P2P tool designed to run in any browser with zero install, Opus at 510kbps is the correct engineering choice — not a limitation.

Cross-source gain calibration

Not all capture paths deliver the same gain — and most browser-based audio tools skip this entirely, leaving the broadcaster to compensate by ear.

System Audio capture (via the browser's getDisplayMedia API) and virtual audio devices (Loopback, BlackHole) are fundamentally different capture mechanisms. Chrome applies its own internal mixing to system audio before handing it to WebRTC, independent of any constraint a developer sets.

We measured this directly rather than assuming. Using a pink noise reference signal at -12dB input, at identical system volume, the two capture paths read differently on the VU meter:

The 7dB delta is consistent and repeatable. SESSION AM now applies a fixed +7dB gain compensation via the Web Audio API whenever System Audio is the active source — a GainNode in the signal path before the stream reaches WebRTC. The result: regardless of which capture method the broadcaster uses, listeners receive audio at matched perceived loudness.

Adaptive per-listener connection quality

Most WebRTC tools treat P2P-vs-relay as a one-time decision. SESSION AM monitors it continuously, for every listener, independently.

ICE tries a direct connection and falls back to TURN relay only if the direct path fails to establish. The problem: a connection can establish successfully but still perform poorly — packet loss, jitter, intermittent drops — while remaining technically "connected." ICE has no built-in mechanism to detect that kind of silent degradation.

SESSION AM addresses this with active monitoring on the listener side. Every 4 seconds, each listener independently reads its own WebRTC statistics and calculates real packet loss over that interval — the actual delta, not cumulative since session start, which is what reveals degradation as it happens. If loss exceeds a 5% threshold for two consecutive checks (~8 seconds of sustained degradation, filtering out single transient blips), that specific listener triggers a reconnect forced through the TURN relay — without affecting any other listener or the broadcaster.

Persistent session IDs

Every SESSION AM session has a permanent ID. Set it once — the link stays the same forever, for every session you run under that name.

When the broadcaster creates or names a session, the ID is stored locally in the browser. There are no accounts, no server-side tokens, no expiry. The session URL is constructed as sessionam.com/listen/{sessionID} — a static, predictable link that a director, producer, or bandmate can bookmark and open again in six months.

This is intentional. Most streaming tools generate a new room or link per session, which means a new WhatsApp message, a new copy-paste, a new moment of friction every time. A persistent ID makes the session a fixed channel — the score for a film, the rehearsal room for a band. The link becomes infrastructure, not a one-time token.

Pro Mode — DataChannel & MTC relay

Pro Mode uses a second WebRTC channel — a DataChannel, separate from the audio track — to carry MIDI timecode and sync signals browser to browser, with zero extra install on the listener side.

WebRTC supports two distinct channel types: MediaStream tracks (for audio and video) and DataChannels (for arbitrary binary or text data). SESSION AM's Pro Mode opens a DataChannel alongside the existing audio connection for each listener that the broadcaster activates it on. The audio and sync travel in parallel on the same peer connection.

Sync DAW — MTC relay

The broadcaster's DAW sends MIDI Time Code (MTC) quarter-frame messages to SESSION AM via the Web MIDI API. SESSION AM re-broadcasts these messages in real time over the DataChannel to each Pro-enabled listener. The listener's browser receives the quarter-frame stream and uses the Web MIDI API to output it as a local MTC signal, which the listener's DAW chases as if it were a hardware MIDI source.

Tape Sync — latency-compensated timecode start

Tape Sync solves a different problem: synchronized playback start without requiring the listener's DAW to chase MTC continuously. The broadcaster sets a target timecode and fires a latency beacon — a round-trip measurement between broadcaster and each listener. SESSION AM uses the measured RTT to calculate each listener's offset, then triggers playback start at the compensated moment so both sides hit the same timecode simultaneously.

A manual offset field is available as a fine-tune for cases where the round-trip measurement doesn't fully account for local system latency (audio buffer size, interface latency). In practice the beacon compensation is accurate enough for most use cases without adjustment.

Bottom line