Everything you need to know to set up and run a Broadcast Web Comms session — from creating your first room to managing groups and hot mics during a live production.
The host creates and owns the session. To get started:
Tip: Use headphones during sessions to prevent feedback between your microphone and speakers. The system does not apply echo cancellation by default, giving you clean unprocessed audio.
Hold the HOLD TO TALK button on a channel to transmit your microphone audio to that person. Release to stop. This is the default mode for all channels.
Click the OPEN mode button on a channel to keep your microphone continuously active to that person — no need to hold a button. The PTT button will show ● OPEN MIC. Click PTT to return to push-to-talk.
Click the LISTEN button on any channel to monitor that person's incoming audio continuously, regardless of whether they are actively talking to you. Useful for monitoring a specific operator at all times.
Groups allow the host to create named collections of participants and talk to them all with a single PTT. To create a group:
Groups appear for all participants immediately. Any user can press a group PTT button to talk to all members of that group simultaneously.
Hot Mic is a host-only feature that makes a participant's microphone always active — transmitting to everyone in the session continuously, without them needing to press PTT.
Hot Mic + Listen: Hot mic makes someone always transmitting. Listen makes you always receiving them. Enable both to create a continuous monitoring feed of a specific operator.
Each TX channel has an independent audio processing chain. Click DSP on a channel to open the processor panel:
Each processor has an on/off toggle and takes effect in real time with no interruption to the connection.
Click 1K TONE on any channel to send a 1kHz sine wave at −8 dBFS to that specific user. This replaces your microphone signal on that connection only and is useful for checking audio routing and signal levels. The TX meter will show the tone level. Click again to stop and restore your microphone.
Enable your camera on the setup screen to share video with all participants. Remote video feeds appear automatically in the Video Feeds panel. Each feed tile includes:
Program audio uses its own independent audio context and can be routed to a different output device from the comms audio. This is useful for monitoring a Blackmagic Web Presenter or similar device's embedded audio.
rooms path.Full technical reference for the Broadcast Web Comms system — architecture, audio/video pipeline, network requirements, and system specifications.
Broadcast Web Comms is a single-file browser application built on WebRTC. It uses a full-mesh peer-to-peer topology — every participant connects directly to every other participant. There is no central media server; audio and video are routed peer-to-peer via encrypted DTLS/SRTP streams.
Firebase Realtime Database is used exclusively for signalling (session coordination). No media passes through Firebase. Once a session is established, Firebase traffic is minimal and the system remains fully functional even if Firebase connectivity degrades temporarily — existing peer connections are unaffected.
Mesh topology: For N participants, N×(N−1)/2 peer connections are established. For a 4-person session that is 6 connections. For 8 people, 28 connections. Larger sessions may require more bandwidth.
| Capture | |
| Sample Rate | 48,000 Hz (48 kHz) — browser default |
| Bit Depth | 16-bit (browser capture pipeline) |
| Channels | Mono (1 channel) — typical browser mic capture |
| Echo Cancellation | Disabled by default (raw capture) |
| Noise Suppression | Disabled by default (raw capture) |
| Auto Gain Control | Disabled by default (raw capture) |
| Codec / Transport | |
| Audio Codec | Opus (WebRTC standard) |
| Opus Bitrate | Up to 128 kbps (configurable via SDP) |
| Opus Complexity | Browser-managed adaptive |
| Packet Loss Concealment | Yes — native Opus PLC |
| Forward Error Correction | Yes — Opus in-band FEC |
| Transport | WebRTC DTLS-SRTP (encrypted) |
| Typical Latency | 20–80 ms (network dependent) |
| Web Audio Processing (DSP) | |
| Noise Gate | RMS-level gated GainNode, 50 Hz poll rate |
| Compressor | Native DynamicsCompressorNode (WebAudio API) |
| EQ | 4× BiquadFilterNode in series (HP, LS, Peak, HS) |
| DSP Isolation | Per-peer — independent chain per connection |
| Test Tone | 1000 Hz sine, −8 dBFS (OscillatorNode) |
| Capture | |
| Default Resolution | 1280×720 (720p) — ideal constraint |
| Frame Rate | 30 fps — ideal constraint |
| Codec | VP8 / VP9 / H.264 (browser negotiated) |
| Video Bitrate | Up to 1,500 kbps (balanced mode) |
| Audio-priority bitrate | 150 kbps video, 128 kbps audio reserved |
| Program Audio (Video Tiles) | |
| Audio Context | Independent per feed — isolated from comms |
| Routing | MediaStreamSource → GainNode → AudioContext destination |
| Output device | Follows devOutSelect or system default |
| ICE / NAT Traversal | |
| STUN Servers | Google STUN ×2, Cloudflare STUN |
| TURN Servers | Metered Open Relay (openrelay.metered.ca) |
| TURN Protocols | UDP/80, TCP/443, TLS/443 (TURNS) |
| Firewall compatibility | Full — TURNS/443 passes strict firewalls |
| ICE Restart | Automatic on connection failure |
| Signalling | |
| Signalling transport | Firebase Realtime Database (WebSocket) |
| Signalling data | SDP offer/answer, ICE candidates only |
| Session cleanup | onDisconnect() hooks — presence auto-removed |
| Reconnect | Automatic presence re-registration on reconnect |
| Bandwidth Estimates (per peer) | |
| Audio only | ~160 kbps bidirectional |
| Audio + 720p video | ~1.8 Mbps bidirectional |
| Bandwidth modes | Auto (adaptive RTT), Audio Priority, Balanced |
| Media encryption | DTLS-SRTP (mandatory, WebRTC standard) |
| Signalling encryption | TLS (Firebase WebSocket) |
| HTTPS requirement | Required for getUserMedia (mic/camera) access |
| Room access | 6-character alphanumeric room code |
| Data channels | SCTP over DTLS (encrypted, used for PTT/DC signalling) |
| Chrome / Chromium | Full support — recommended |
| Microsoft Edge | Full support |
| Firefox | Full support |
| Safari | Partial — WebRTC supported, setSinkId not supported (output routing unavailable) |
| Mobile Chrome (Android) | Full support |
| Mobile Safari (iOS) | Limited — getUserMedia restrictions apply |
| Protocol | HTTPS (required for mic/camera access) |
| File | Single self-contained HTML file (~155 KB) |
| Dependencies | Firebase SDK (CDN), Google Fonts (CDN) |
| Server requirement | None — static file hosting only |
| Firebase plan | Free Spark plan sufficient for small sessions |
| Concurrent connections | Up to 100 (Firebase Spark limit) |