A studio-to-transmitter link, or STL, has one job: get audio from one place to another reliably enough that a listener never hears the seam. Traditionally that job belonged to dedicated hardware, point-to-point radio links or leased lines built for exactly this and nothing else. AudioLink replaces that hardware with a Node.js relay server and a browser, which sounds like a downgrade until you look at what the hardware was actually solving and what a general-purpose internet connection changes about the problem.
Compression is the wrong place to save bandwidth
The obvious way to make an audio link more tolerant of a mediocre connection is to compress the audio, smaller packets, less bandwidth needed, more headroom before things break. AudioLink does the opposite for its core link: audio is captured in the browser using the Web Audio API's AudioWorklet and transmitted as raw PCM Float32 samples over the WebSocket connection, uncompressed.
The reasoning is that compression and network resilience solve different problems, and conflating them costs you on both. A compressed stream has to be encoded before it's sent and decoded on arrival, adding latency that compounds badly for something meant to feel close to real-time. Uncompressed PCM has effectively none of that overhead. The tradeoff is bandwidth, so the resilience problem doesn't disappear, it just has to be solved somewhere else instead of hidden inside the codec.
Where the resilience actually lives
That "somewhere else" is the jitter buffer and auto-reconnect logic sitting on top of the raw PCM stream. A WebSocket connection over a real internet path doesn't deliver samples at a perfectly even pace, packets burst, get delayed, occasionally get lost. A jitter buffer absorbs that by holding a short cushion of audio before playback, so a late packet eats into the cushion instead of causing an audible gap. Auto-reconnect exists for what the buffer can't absorb: an actual dropped connection, where the relay has to notice, re-establish the session, and resume without a human intervening mid-broadcast.
This is the actual tradeoff: instead of a codec silently discarding detail to survive a bad connection, AudioLink keeps the full signal and puts the burden of surviving a bad connection onto explicit, inspectable logic that can be tuned and debugged. A codec's resilience is opaque. A jitter buffer's behavior is something you can reason about.
Why the relay bypasses the usual web server layer
AudioLink's relay serves SSL directly rather than sitting behind Nginx, the opposite of how most of the rest of the infrastructure is set up. A reverse proxy is normally the right call, but for a long-lived, bidirectional streaming connection, that extra hop is a place for buffering or timeout behavior tuned for typical HTTP traffic to interact badly with continuous audio. Terminating SSL directly removes that variable, at the cost of managing certificate renewal independently.
Where uncompressed genuinely stops making sense
AudioLink's planned Pro tier introduces adaptive bitrate using Opus, stepping between 256, 128, and 64kbps based on observed packet loss, jitter, and throughput. That's a deliberate acknowledgment that a remote transmitter on an unpredictable connection, a phone hotspot at a remote broadcast, is a different problem than a link where bandwidth is generally sufficient. Uncompressed PCM assumes the bandwidth is there to spend. Adaptive Opus assumes it might not be, and trades fidelity to keep the link alive at all.
The underlying idea
The instinct to compress audio to survive a bad network conflates two problems: how much data you're sending, and how gracefully you recover when the network hiccups anyway. AudioLink's core link solves the second problem directly, with logic you can reason about, rather than asking a codec to paper over both at once.