MUSIXQUARE

Turn any room into a surround system with your devices

Comment

Inspiration

MUSIXQUARE began with a simple moment: I was listening music with friends on a laptop with weak speakers, while several phones were sitting unused on the table. I wondered, “Why can’t all these devices work together as one sound system?” As an architectural engineering student, I have always been interested in acoustics and in how sound changes the way we experience a space. That curiosity led to a larger idea: instead of buying dedicated speakers or installing another app, people should be able to use the devices they already own. What started as a small Web Audio experiment grew into a nine-month journey through real-time networking, synchronized playback, spatial audio, browser limitations, and many architectural rewrites. The goal remained the same throughout: make listening together as simple as opening a webpage.

What it does

MUSIXQUARE turns phones, tablets, and computers into one synchronized wireless sound system directly in the browser. No installation or account is required for the core experience. A host creates a room and shares a six-digit code, invite link, or QR code. Other devices can join within seconds and take on different speaker roles such as Left, Right, Center, or Subwoofer. For local audio, MUSIXQUARE combines role-based channel routing with advanced sound processing, including a five-band EQ, reverb, virtual bass, virtual surround, and treble enhancement. Each connected device plays its assigned part of the processed sound, turning the devices already in a room into a flexible spatial audio system. It also supports synchronized local files, YouTube co-watching, desktop system-audio sharing, encrypted remote file delivery, and real-time chat across both local and remote networks. Because the YouTube IFrame API does not expose raw audio, channel separation and advanced audio effects are available for local audio, but not for YouTube playback.

How I built it

MUSIXQUARE is built as a TypeScript web application using Vite, the Web Audio API, WebRTC, and Cloudflare infrastructure. The project began as a single-device audio visualizer using an AnalyserNode. Separate prototypes for frequency analysis, peer-to-peer synchronization, and channel routing were gradually combined into one application. The original implementation eventually grew into a 12,000-line JavaScript file. To make the system maintainable, it was rewritten as strict-mode TypeScript modules with typed protocol messages, clearer state boundaries, and automated tests. WebRTC data channels carry playback commands, synchronization data, playlist updates, chat messages, and device state. Local system audio can travel through direct WebRTC media connections. Remote system-audio listeners use a Cloudflare Realtime SFU so the host does not need to publish a separate stream to every participant. Playback is coordinated through a shared host clock. Each device measures network round-trip time and schedules playback against the same future timestamp. The system then detects and corrects drift instead of assuming that every device receives a command at the same time. For remote file sharing, audio is encrypted inside the browser before being temporarily uploaded to Cloudflare R2. The decryption key is shared separately and is never stored with the encrypted file.

During OpenAI Build Week

During OpenAI Build Week, I used Codex powered by GPT-5.6 as an engineering partner to meaningfully extend MUSIXQUARE beyond its pre-existing foundation. Rather than using it only for isolated code generation, I worked with Codex across the full development cycle: analyzing the real-time architecture, designing system boundaries, implementing features, tracing asynchronous failures, building regression tests, auditing security assumptions, and validating production deployments. The largest extension was a new persistent PRO room architecture. Before Build Week, MUSIXQUARE rooms were temporary and coordinated by a host browser. During the event, I built persistent rooms with stable room identities, private media storage, durable playlists, repeat and shuffle state, participant presence, server-owned playback authority, and recovery from sleeping or disconnected clients. I also added room-scoped Developer APIs for queue management, playback controls, and audio effects; optional account identity with account-bound permissions; a bounded room assistant; collaborative playlist controls; remote-media preloading; and media delivery designed to scale to as many as 100 connected devices. Codex and GPT-5.6 also helped me strengthen the experience surrounding those features. I added global drag-and-drop media loading, locale-aware pluralization, improved multilingual copy, safer reconnect identities, atomic session resets, more reliable YouTube transitions and rendezvous timing, playlist-following UI, interface sounds, and clearer real-time feedback. Behind the product, I created release manifests, deployment-state verification, live signaling and reconnection smoke tests, Cloudflare configuration safeguards, rollback procedures, and extensive unit and end-to-end regression coverage. I made the final product and architectural decisions myself, while Codex accelerated implementation, review, testing, and the investigation of complex edge cases across the browser, WebRTC, Cloudflare Workers, Durable Objects, D1, R2, and the production release pipeline.

Challenges I ran into

The hardest challenge was synchronization. Sending “play now” to every device does not make them start together because each connection has different latency, jitter, decoding time, and device performance. I experimented with countdowns, timestamp correction, playback-rate nudging, and repeated round-trip measurements before arriving at a shared-clock architecture. Browser and operating-system limitations created another major challenge. YouTube’s IFrame API does not expose raw audio because of browser security and DRM restrictions. This means audio effects and per-channel routing cannot be applied to YouTube playback. Mobile browsers also do not expose system-audio capture, so hosting system audio remains limited to supported desktop browsers. Large audio files were difficult because the browser may need several copies of the same data during encryption, transfer, decoding, and playback. I ultimately adopted a RAM-only storage architecture to simplify the lifecycle and prevent persistent file leaks, but memory-constrained devices still impose practical limits. Remote connectivity required several infrastructure changes. I moved from public signaling services to Cloudflare Durable Objects, added TURN support for networks where direct P2P connections fail, introduced encrypted temporary remote sharing, and added an SFU path for remote system audio. Finally, real-time applications produce unusual edge cases: late joins, reconnecting devices, stale asynchronous operations, playlist changes during playback, hosts leaving unexpectedly, unavailable YouTube videos, and devices returning from the background. Testing these combinations has been an ongoing part of the project.

Accomplishments that I'm proud of

I am proud that MUSIXQUARE grew from one AnalyserNode and a canvas visualizer into a working real-time audio platform. Some accomplishments I am especially proud of include:

  • Rewriting a 12,000-line JavaScript monolith into strict TypeScript modules
  • Building a shared-clock synchronization system that works across different networks
  • Building a multi-device audio engine that applies reverb, a five-band EQ, virtual bass, virtual surround, and virtual treble, then distributes the processed audio across devices based on their assigned Left, Right, Center, or Subwoofer roles
  • Delivering encrypted remote audio files without storing the decryption key server-side
  • Supporting local P2P connections, TURN relays, and SFU-based remote system audio
  • Building extensive unit and end-to-end coverage for synchronization and multi-device scenarios
  • Completing repeated security and architecture audits
  • Launching publicly on Product Hunt and finishing as the #13 Product of the Day
  • Keeping the core experience browser-based, account-free, and easy to try

Most importantly, MUSIXQUARE is no longer only a technical demonstration. It is a complete product that people can open on real devices and use without rebuilding the project or configuring special hardware.

What I learned

I learned that synchronization is not a single algorithm. It is a continuous negotiation between clocks, networks, browser scheduling, media decoding, and user actions. I also learned that browser APIs have clear boundaries. Some limitations cannot be solved by adding more code. YouTube channel separation, mobile system-audio capture, and DRM-protected streaming require platform-level support or licensing agreements. Clearly documenting these boundaries is often more valuable than pretending they can be worked around. Rewriting the architecture taught me the importance of typed protocols and explicit state ownership. In a real-time system, a small ambiguity about which device controls a value can become a race condition across every connected peer. Testing also changed the way I build. Simple playback tests are not enough for a multi-device application. Late joins, reconnections, background suspension, stale events, network delays, and concurrent user actions must be treated as normal operating conditions. Finally, launching on Product Hunt taught me that people imagine uses I did not initially design for, including podcast monitoring, presentations, casual gatherings, shared viewing, and temporarily replacing weak laptop speakers. A clear core technology can support a much wider set of experiences than its original use case.

What's next for MUSIXQUARE

My next priority is a new playback engine designed to handle larger audio files more efficiently. The current RAM-only architecture keeps storage behavior predictable, but decoding and processing large files can still require too much memory on constrained devices. The new engine will focus on reducing peak memory usage while preserving synchronized playback. Another major focus is reliability under complex real-world conditions. I will continue finding and fixing edge-case bugs involving reconnections, late joins, backgrounded devices, rapid playlist changes, host migration, and overlapping playback operations. Finally, MUSIXQUARE already supports multiple languages, but translated interfaces need human review. I plan to improve translation quality, terminology consistency, layout compatibility, and clarity across every supported language. MUSIXQUARE started with a question about a few unused phones on a table. The next step is to make that idea reliable and intuitive enough to work in any room, on any combination of devices.

Built With

Share this project:

Updates