SoundWall - Turn every Phone into a Synchronized Speaker (WebRTC + PWA)

Hi everyone 👋

I’d like to share a side project I’ve been building: SoundWall.

🎶 What is SoundWall?

SoundWall synchronizes multiple smartphones so they can play the same song at the exact same time — creating a small mobile sound wall.

It’s a fun experiment in real‑time audio synchronization using WebRTC and Progressive Web App technology.

⚙️ Tech stack

• WebRTC for timing synchronization
• PWA (installable, offline‑capable)
• Minimal backend — sync logic runs entirely on the client

🌍 Use cases

• spontaneous outdoor sessions
• mini‑parties without Bluetooth speakers
• creative audio experiments

💬 Why I’m sharing

I’d love to get feedback from the community, especially on:

• WebRTC synchronization strategies
• timing optimization
• PWA best practices

🔗 Demo

https://soundwall.bolt.host

Thanks for reading — I’d love to hear your thoughts, ideas, or suggestions!

— Konstantinos

Comments

[Amit Feldman]

Synchronized multi-phone audio over WebRTC is a fun build — congrats on shipping it.

Quick public check of soundwall.bolt.host (headers + public config only):

1. Of the six standard security headers, only HSTS is set — and that one comes from the bolt.host platform, not your app. Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy are all unset. The catch: on bolt.host you don't control response headers, same as GitHub Pages. The standard fix is Cloudflare in front (free plan) with a Transform Rule that adds the header set — ~15 minutes, no code changes. For a WebRTC app, two of these punch above their weight: Permissions-Policy (declare mic/speaker access explicitly — browsers are tightening default policy around media devices) and CSP, where connect-src needs to explicitly allow your signaling/WebSocket endpoints or the policy will silently break the sync.

2. Three small on-page items: no meta description, no h1, and no canonical link. On a JS-rendered PWA these matter more than usual — crawlers and link-unfurlers (the social preview when someone shares the link) often see only the raw HTML shell, and right now that shell gives them almost nothing. Title tag is there and clean, at least.

3. One naming thing, in case it's unintentional: the article says SoundWall, but the deployed page title is "VibeQueue — Listen Together". If that's a half-finished rebrand, worth picking one before launch posts start accumulating under the old name.

TLS is fine (platform cert), robots.txt and sitemap.xml both 200. Happy to re-run the scan free once the headers land. Good luck with the launch!

[Kourouklidis]

Thanks a lot for taking the time and for the detailed feedback — really appreciate it.

I’ve already addressed the first batch of items: meta description, canonical tag, h1, and social preview tags are now in place so crawlers and link unfurlers get proper context.

I’m currently working on the remaining points around security headers (CSP, Permissions‑Policy, etc.). Because bolt.host doesn’t expose header control, I’m setting up a Cloudflare‑proxied domain so I can apply the full header set via Transform Rules.

I’ll share another update once that part is completed.