Chirp Pong: Networking via Sound Waves Lets Two Phones Battle Without Any Connection

When "networking" relies on sound waves

Simon Willison has built another small experiment: Chirp Pong. The question it sets out to answer is very specific — can you build a two-player game running on two phones placed near each other using pure static HTML, with game state transmitted entirely via sound waves (chirps) picked up by the microphone, rather than over Wi-Fi, Bluetooth, or a cable?

The answer: it works.

What's interesting about this experiment isn't that it's "another Pong" — it's that the entire network layer we take for granted is removed and replaced with a physical channel: air.

Implementation: the microphone as a network card

From a technical standpoint, Chirp Pong's architecture is remarkably restrained:

• Pure static HTML, no backend, no WebSocket, no WebRTC
• Two phones placed near each other
• Game state encoded as audio signals broadcast through the speaker
• The other end captures the audio via the Web Microphone API, decodes it, and reconstructs the state

This effectively replaces the network stack with sound waves. Latency, bit errors, and obstruction all become real problems, but the original verdict is "It seems to work" — in close-range scenarios, the approach is viable.

You might not realize that this kind of "acoustic communication" isn't a new concept, but squeezing it into a pure frontend, zero-dependency two-player game makes the engineering trade-offs very tangible: you give up reliability and generality, and in return you need no pairing and no infrastructure beyond a permission prompt.

Chirp signals and audio modulation

A chirp is a short audio signal whose frequency varies linearly (or by some other pattern) over time. These signals have distinctive spectral characteristics and extremely strong autocorrelation, so the receiver can use matched filtering to pinpoint their arrival time even in noisy environments — which is why they're widely used in radar, sonar, and early acoustic data transmission schemes. Encoding game state into chirps, the core difficulty isn't in producing the sound itself, but in how the receiver segments valid signals from microphone samples, corrects for frequency shift, and reconstructs the bitstream. Common approaches use frequency-shift keying (FSK) or OFDM-style multi-subcarrier encoding to gain higher data density and noise resistance. But these schemes all need to push sound into frequency bands nearly imperceptible to the human ear, or into extremely short pulses — otherwise the constant "beeping" would severely degrade the gaming experience.

Web Microphone API and audio sampling

The Web Microphone API mentioned in the article actually corresponds to a combination of the browser's MediaDevices.getUserMedia and the Web Audio API. The former handles requesting microphone permission and obtaining the raw audio track; the latter uses AudioContext to turn the audio stream into programmable PCM data — for example, reading samples frame by frame via ScriptProcessorNode or AudioWorkletNode, then handing them to custom demodulation logic. On the speaker side, AudioContext generates oscillators or buffer sources to "broadcast" the state. The entire pipeline runs inside the page's JavaScript sandbox, never touching a server or native layer — which is precisely what makes Chirp Pong possible as pure static HTML.

Not just Pong: gameplay reimagined

The original article directly shares the prompt given to the model (Claude Opus 5.5 Extra, running inside Claude Code), which explicitly demands breaking Pong's monotony:

Build a two-player competitive Pong-like game where two players hold their phones together, and game state is transmitted via audio noise and parsed by the Web Microphone API — but add graphical and gameplay variations to make it more interesting and more intertwined than Pong.

In other words, the author himself wasn't satisfied with "replicating Pong." The goal is a strongly interactive two-player experience, not two people each staring at half a screen. The word "intertwine" is key — the two players' actions need to genuinely mesh together, not be mirror-symmetric independent matches.

The role of AI coding assistants in prototyping

Claude Code is Anthropic's command-line AI coding agent, capable of reading and writing files, executing commands, and iteratively running projects directly in the terminal; "Opus 5.5 Extra" refers to the top-tier model in that series aimed at complex reasoning tasks. The key difference between such tools and traditional code completion is that they can independently organize implementation order and debug around a multi-file, multi-step goal — not just offer line-by-line suggestions. A project like Chirp Pong perfectly illustrates where its applicability lies: unconventional constraints (audio channel, real-time dual-device sync), small-to-medium total code volume, and no existing dependencies to follow — exactly the scenario that's hard to solve by searching for and stitching together off-the-shelf libraries, and instead well-suited to letting the model build a self-consistent small system from scratch.

This is more a probe of capability boundaries

Placed within Simon Willison's consistent line of experiments, Chirp Pong tests three things at once:

1. The boundaries of browser capabilities — how complex a state sync can a pure static page plus a microphone support?
2. Alternatives to near-field communication — when system-level pairing is too much hassle, is sound a genuinely underrated shortcut?
3. The efficiency of AI-assisted development — the distance from idea to a runnable prototype for a complete small game with unconventional constraints (audio channel, dual device, real-time) has been compressed dramatically.

Point 3 deserves particular attention. The original article devotes only a single sentence to the model and the entry point, with no description of the debugging process at all. This understatement itself says something about the current state of tooling: for experimental projects of this medium complexity, AI coding assistants can already handle the bulk of implementation work.

Predictable limitations

The original doesn't elaborate on failure cases, but several clear constraints follow from the approach itself:

• Distance: acoustic communication is sensitive to the spacing between devices — they must be "close to each other"
• Noisy environments: reliability drops significantly in loud places
• Bandwidth: the amount of state audio encoding can carry is limited, which caps game complexity
• Symmetry: both ends must simultaneously receive and send — self-echo (your own speaker picked up by your own microphone) needs handling

These limits mean Chirp Pong won't replace any serious multiplayer networking solution anytime soon. Its value is as prototype validation: when you just want to quickly test a two-player interaction idea without touching servers or pairing flows, sound waves are a path that genuinely works.

Nearly zero cost to try

The tool itself is a webpage, publicly accessible, click-and-play. No installation, no account, no network configuration needed. For anyone wanting to explore the Web Audio API or Web Microphone API, or simply curious what a "game without networking" looks like, this is a sample you can dive right into and take apart.

Replace the network layer with air, replace the pairing flow with "hold your phones closer" — Chirp Pong's inspiration isn't in the game itself, but in the reminder it offers: many things treated as "essential" infrastructure actually have simpler, more direct alternatives.

One-line Summary

Simon Willison's Chirp Pong swaps the network layer for sound waves, letting two phones play a two-player match through their microphones.

Paragraph Summary

Simon Willison's experimental project Chirp Pong tests a specific question: can two nearby phones transmit game state via sound waves instead of Wi-Fi, Bluetooth, or a cable, using pure static HTML? The answer is yes. The implementation relies entirely on the Web Microphone API and audio codec — no backend, WebSocket, or WebRTC. Game state is encoded as audio signals broadcast through the speaker, captured and decoded on the other end. The prompt given to Claude Opus 5.5 Extra explicitly requires graphical and gameplay variations, refusing to merely replicate Pong. The approach's limits are also clear: it depends on close range, is vulnerable to noise, and has limited audio bandwidth — it's positioned as prototype validation rather than a general-purpose multiplayer solution. The experiment also showcases the efficiency of AI coding assistants in building a complete small-game prototype with unconventional constraints.