Evidence at a glance
Making Proximity a Way to Connect
On October 15, 2026, Simon Willison published Chirp Pong, an experiment in two-player gaming. Each player opens a static web page on a phone, and game state travels as sound played by one phone and received by the other phone’s microphone. The question was whether two phones could keep a game running at close range without pairing over Wi-Fi or Bluetooth. The post’s conclusion is restrained: it “seems to work,” with no test data attached.
The useful idea for a technical lead is not that sound replaces the internet, but that the experiment changes the preconditions for connecting devices. Many device-to-device interactions require network setup, pairing, or login. Here, placing the phones near one another becomes part of the topology: one device emits sound, and the other listens. There are fewer connection steps, but the communication requirements have not gone away. They have shifted onto the devices and the environment.
From Browser Audio to Checkable Data Frames
The page uses the browser microphone API to receive sound, then Web Audio to play tones and analyze the microphone input. Its source encodes data as groups of fixed-frequency sine waves rather than sending speech or music intended for human listening. The scheme uses 16-level frequency-shift keying, so one symbol can represent four bits. Each symbol lasts 50 milliseconds, each frame begins with two synchronization symbols totaling 100 milliseconds, and a CRC-8 value is added at the end to check the frame.
Establishing a connection also takes more than simply hearing a sound and starting play. The caller sends HELLO in a lower frequency band, and the other phone responds with WELCOME in a higher band. The source uses a random nonce to handle the case where both phones call at once. During the game, a BALL frame carries the ball’s position, angle, speed, spin, power-ups, streak count, and a marker for a powerful shot. When the ball crosses the top edge of the screen, those fields are sent to the other phone. The design is therefore aimed at compact game-state updates, not at copying a full audio or video stream.
Fewer Pairing Steps, but Setup Still Matters
The page’s claim that the phones need no Wi-Fi, Bluetooth, or account refers to how they exchange game data. It does not mean the web page itself needs no delivery mechanism. Microphone access requires the page to be served over HTTPS, and the user must grant permission. The instructions also ask players to place the phones screen-down and back-to-back on a table, a few centimeters apart, turn up the volume, and disable silent mode. For players, that is a specific setup routine; for implementers, it is part of the link’s preconditions.
The source also disables echo cancellation, noise suppression, and automatic gain control. Those features usually help with calls, but they alter the sound reaching the microphone and could interfere with recognizing encoded tones. The trade-off shows that having audio APIs in the browser does not make an acoustic data link usable without control. A static page can lower the barrier to distribution and launch, while device placement, browser audio processing, and permission management remain part of the design.
The Game Makes the Link’s Capabilities Visible
This is not an empty demonstration that only shows tone decoding. The page offers both a two-phone match and a single-phone practice mode against the CPU. A match can be set to finish at 7, 11, or 15 points; a streak of six hits doubles the score multiplier, and a streak of twelve triples it. By tying the ball crossing the screen boundary to a handoff of state, the game makes it possible to see when the devices interact through play.
Those rules also help engineers define what the prototype is doing: it sends a limited set of discrete fields, and transmission is tied to the ball’s position. That mechanism could be useful to explore a nearby-device game or an exhibit interaction where conventional pairing is an obstacle. But the available material gives no frame latency, packet-loss rate, or player-response measurements. The fact that a game can run does not establish that the link can support applications with more demanding timing or continuity requirements.
A Feasibility Demo Is Not Yet a Reliable Product
The advantages and limits of acoustic communication come from the same fact: the devices do not need a shared router or wireless pairing, but they do need to be positioned so that one can play sound and the other can record it. The page’s instructions to keep the phones a few centimeters apart, raise the volume, and disable silent mode show that this is not a link to use casually from a pocket or across a room. The source specifies two frequency bands, roughly 1,406–3,000 Hz and 3,375–4,969 Hz, which also makes clear that the system relies on particular tone ranges rather than on an abstract idea of “networking with sound.”
The evidence supports a limited conclusion: browser capabilities were enough for the author to build a near-field acoustic experiment, and game state could pass between two phones as sound. It does not establish success rates across phone models and browsers, or how much noise reduces the usable distance. A team considering this approach should first fix the devices, browser, distance, and environment, then measure whether state frames arrive reliably before investing further. If a product cannot tolerate close placement, a volume requirement, or microphone permission, choosing another communication link is the more direct decision.