Low-latency control messages over WebRTC data channels

WebSockets route every message through a server. WebRTC lets two browsers talk directly once they have exchanged connection details, so on the same local network a control message can travel from phone to desktop without leaving the room.

Data channels can be configured as ordered and reliable (like TCP) or unordered with limited retransmits. For a note-on or note-off, losing the message is worse than a small delay, so reliable delivery is the right choice. For a fader that sends a stream of positions, only the latest value matters, and an unreliable channel avoids waiting on stale retransmissions.

Using two channels — one reliable for discrete events, one unreliable for continuous controls — gives each kind of message the behaviour it needs.

MIDI messages are three bytes. Sending them as small binary arrays rather than JSON objects keeps parsing trivial on both ends. Rate-limit continuous controls to changes that actually differ from the last sent value.

Phones sleep, Wi-Fi drops, and tabs get backgrounded. The connection layer should notice a closed channel, show it clearly in the UI, and make reconnecting one tap. Stuck notes are the classic failure: when a connection drops, send note-off for anything still held.