Prototype
From August to December 2025, frequency analysis, peer-to-peer synchronization and
channel routing were developed as separate experiments. MUSIXQUARE began as an audio
visualizer for one device, using an AnalyserNode, configurable frequency
bands, per-band smoothing and a Canvas render loop. That audio graph became the basis of
the released app.
In October, the first PeerJS and WebRTC prototype synchronized two phones with hard seek
corrections and small playbackRate changes. The synchronization model was
rebuilt through November while direct file transfer was added. December focused on
channel routing with ChannelSplitter, per-band GainNodes and a
120 Hz low-pass filter for the subwoofer channel. The MUSIXQUARE name, wordmark and
#3b82f6 blue were adopted late that month.
-
August: Web Audio foundationBuilt the
AnalyserNodepipeline, frequency-band smoothing and Canvas visualizer that became the basis of the v1.3 audio graph. -
October: First peer-to-peer syncThe first WebRTC prototype used PeerJS, a hard seek above 0.5 seconds of drift and small
playbackRatechanges between 0.05 and 0.5 seconds. Every second, the host sent{ time, paused, playbackRate, timestamp }. This later informed SharedClock. -
November: Shared playback and file transferThe two-device prototype aligned playback over the room connection. Host MP3 files were transferred to guests as Blob data. Per-device offsets later became Nudge Sync.
-
December: Channel routing and identityVersions 1.0 through 1.2 added the stereo oscillator lab, Canvas spectrum visualizer, a subwoofer channel with a 120 Hz low-pass filter and L, Stereo and R controls. In late December, the project adopted the MUSIXQUARE name, wordmark, five-tab navigation and Light, Dark and System themes.
Build
From January to April 2026, the channel lab, synchronization prototype and frequency analyzer were combined into one app. Git history began on January 25, when the app already included host and guest roles, QR invitations, reverb, five-band EQ, virtual surround, Nudge Sync and an eight-channel role picker.
In February, Metered TURN enabled connections across different networks, and the
TypeScript rewrite began. The 12,018-line app.js was split into strict ES
modules under src/. March added chat, beat detection, Phase Sync and
Playwright tests. April introduced SharedClock and a two-stage YouTube synchronization
handshake.
-
January 25: First Git commitThe app already included five-tab navigation, host and guest roles, QR invitations, the audio-effect chain, Nudge Sync and an eight-channel role picker.
-
February: Remote connections through TURNMetered.ca TURN allowed WebRTC connections across separate networks. Sync latency was estimated from three RTT samples instead of raw timestamps.
-
February: TypeScript rewriteThe 12,018-line
app.jswas split into strict TypeScript ES modules. Protocol messages, EventBus handlers and state paths gained explicit types. The i18n key system was added. -
March: Chat, beat detection and browser testsChat commands, grouped messages, BPM analysis and Phase Sync were added. The Playwright suite covered late joins, network disruption and multi-device behavior.
-
April: SharedClock and YouTube synchronizationThe host clock became the timing reference for every device. Clients scheduled playback for the same target time and corrected measured drift. YouTube playback added a required rendezvous handshake and automatic skipping for unavailable videos.
-
April: Security auditsEight pre-launch audit rounds and further post-launch audits covered event mismatches, XSS validation, room-code randomness and the TURN endpoint. Each round closed with no critical or high-severity findings.
Ship
May 2026. The app moved to RAM-only audio storage, temporary private file sharing, Cloudflare TURN, Realtime SFU and Cloudflare-based WebRTC signaling.
-
RAM-only audio architectureThe app replaced OPFS with a RAM-only slot pool. This reduced preload overhead and removed disk persistence from the local audio lifecycle. A six-pass cleanup removed the remaining OPFS code.
-
Private remote file sharingRemote guests received local audio through temporary objects in a private Cloudflare R2 bucket. The first release encrypted files in the browser with AES; that application layer was later removed after the storage policy changed. Transfers now use HTTPS, short-lived download authorization, origin checks, automatic expiry and bucket lifecycle cleanup.
-
Cloudflare TURNCloudflare became the primary TURN provider in May. Metered.ca remained available as a fallback at that time and was later removed.
-
Cloudflare Realtime SFULocal guests continued to use direct peer-to-peer audio. Remote guests subscribed through Cloudflare Realtime SFU, allowing the host to publish one stream.
-
Cloudflare WebRTC signalingA Durable Objects worker replaced the public PeerJS signaling service. Offers, answers and ICE candidates now travel through the project's Cloudflare worker. PeerJS remains the localhost development adapter; production hosts do not fall back to it.
-
Product Hunt launchOn May 1, MUSIXQUARE was featured on Product Hunt and finished at number 13 for the day with 88 upvotes.
Current infrastructure
MUSIXQUARE currently uses Cloudflare Workers, Durable Objects, D1, TURN, Realtime SFU and R2.
-
Cloudflare: hosting, signaling, room state, TURN, SFU and storageThe app Worker serves explicit app entry points, writes invite metadata and provides API endpoints for TURN credentials, YouTube search and Realtime sessions. It also applies security headers and immutable asset caching. Signaling Durable Objects carry WebRTC offers, answers and ICE candidates, while PRO Room Durable Objects own persistent room state. D1 stores account, PRO registry, grant, metrics and Developer API records. Cloudflare TURN supplies relay credentials. If those credentials are unavailable, Standard Rooms use a STUN-only direct path rather than another TURN provider. Realtime SFU carries system audio when the selected route requires it. R2 stores temporary Standard Room shares and persistent private PRO media under separate lifecycle rules.
-
WebRTC: playback sync, chat and system audioData channels carry playback control, playlist updates, chat and Nudge Sync data. System audio uses direct WebRTC or Cloudflare Realtime SFU according to room type, network classification, audience size and route health. ICE may select TURN for a direct media path. ICE candidates received before remote SDP are queued and applied after setup.
-
Browser client: audio engine, local storage and buildThe audio engine uses the native Web Audio API. Its main path is source to stereo width, preamp, role routing, EQ and reverb. Parallel bass and exciter paths join before master output and analysis. Audio tracks remain in a RAM-only slot pool and are not written to OPFS. The app is built with Vite and strict TypeScript targeting ES2022. The Service Worker caches the offline shell.
Possible future work
These items have no scheduled dates.
-
Eight-channel routing interfaceThe audio engine includes eight-channel routing primitives. The current interface exposes Center, Left, Right and Subwoofer. The full FL, FR, Center, LFE, side and rear picker has not been scheduled.
-
Native system-audio hosting on mobileMobile browsers do not implement
getDisplayMedia({ audio: true }). Hosting system audio from a phone would require a native app and platform screen-capture APIs.
Browser and platform limits
These restrictions come from browser APIs, operating systems and DRM services.
-
YouTube effects and channel routingThe YouTube IFrame API does not provide raw audio samples to Web Audio, so YouTube playback cannot use MUSIXQUARE's EQ, reverb, surround or channel routing.
-
Capturing system audio on iOS and AndroidMobile browsers do not implement
getDisplayMedia({ audio: true }). A phone can receive a computer host's stream through the SFU, but it cannot host a system-audio stream from the browser. -
Spotify, Apple Music, Tidal and other DRM servicesDRM-protected audio cannot be captured or passed to Web Audio. Supporting these services would require separate platform integrations and licensing agreements.