先看证据
把设备靠近变成一种连接方式
Simon Willison 在 2026 年 10 月 15 日发布了 Chirp Pong，一项双人游戏实验：两名玩家分别在手机上打开静态网页，游戏状态通过扬声器发声、再由另一部手机的麦克风接收。他要验证的是，两台手机能否不经过 Wi-Fi 或蓝牙配对，就靠近场声音维持一局游戏。实验记录给出的结论很克制，只有“看起来能工作”，没有附上测试数据。
这件小工具值得技术负责人看的地方，不是它让声音取代了互联网，而是它重新安排了连接的前提。传统的设备间交互常要求配网、配对或登录，这里则把“把两部手机放近”变成拓扑的一部分，一部设备发声，另一部设备监听。建立链路的步骤少了，但通信条件并没有消失，而是落到了设备和环境上。
从浏览器音频到可校验的数据帧
网页通过浏览器麦克风 API 获取声音，再用 Web Audio 播放音调、分析麦克风输入。源码把数据编码成多组固定频率的正弦音，而不是发送一段供人听的语音或音乐。它采用 16 阶频移键控，也就是一个符号可表达 4 bit；每个符号持续 50 毫秒，每帧开头先有两个同步符号，合计 100 毫秒，帧尾再附上 CRC-8 校验值。
连接建立也不是靠“听见声音”后就直接开打。呼叫方在较低频段发送 HELLO，对端在较高频段回应 WELCOME，源码还用随机 nonce 处理双方同时发起呼叫的情况。进入游戏后，BALL 帧承载球的位置、角度、速度、旋转、道具、连续回合数和强力击球标记；球越过屏幕上边缘时，这些状态会传给另一部手机。设计目标因此很清楚：传递一组紧凑的游戏状态，而不是复制完整的音频或视频。
省掉配对步骤，条件仍写在操作说明里
Chirp Pong 页面所说的“不需要 Wi-Fi、蓝牙或账号”，指的是两部手机之间传递游戏数据的方式，并不表示网页本身无需加载。浏览器要访问麦克风，页面必须通过 HTTPS 提供，用户也需要授予权限。操作说明还要求两部手机屏幕朝下、背靠背放在桌上，彼此相距几厘米，调高音量并关闭静音。对玩家而言，这是一套明确的摆放和授权流程，对工程实现而言则是链路前置条件。
源码还关闭了回声消除、降噪和自动增益控制。这些功能通常服务于通话体验，但会改变麦克风收到的声音，因而可能干扰程序识别编码音调。这个取舍说明，浏览器提供音频 API 并不意味着声学数据链路可以不加控制地直接使用。静态网页降低了分发和启动门槛，设备摆位、浏览器音频处理和权限管理仍然要纳入设计。
游戏规则让通信能力变得可见
这不是一个只展示音调解码的空壳演示。页面提供双手机对战，也提供单机对 CPU 练习；对战可以设定先到 7、11 或 15 分获胜，连续命中 6 次时得分倍率变为两倍，达到 12 次则变为三倍。游戏把球越过屏幕边界与状态交接绑在一起，玩家能从玩法上看到两台设备之间何时发生了交互。
这些规则也让工程师更容易界定原型在做什么：它要传的是离散而有限的状态字段，且传输事件与球的位置变化相关。这样的机制适合拿来探索近场游戏或展陈交互，因为设备无需先完成传统配对。但材料没有提供帧传输时延、丢包率或玩家操作响应的数据，所以不能仅凭一局游戏能跑起来，就推断它能支撑对时序和连续性要求更高的应用。
可行性演示离可靠交付还有一段距离
声学通信的优势和限制来自同一件事：两台设备不必共享路由器或完成无线配对，但它们必须处在能互相发声和收音的位置。页面给出的几厘米摆放距离、调高音量和关闭静音要求，已经说明这不是一种可随意放进口袋、隔着房间使用的链路。源码标出的两个频段约为 1,406–3,000 Hz 和 3,375–4,969 Hz，也说明系统依赖特定音调范围，而不是抽象地“用声音联网”。
公开证据目前只支持一个有限判断：浏览器能力足以让作者做出一项近场声学通信实验，游戏状态可以通过声音在两台手机之间传递。它没有证明不同手机和浏览器间的成功率，也没有说明噪声会把可用距离压缩到什么程度。若团队要沿这条路做原型，应先固定设备、浏览器、距离和环境，实测状态帧能否稳定收发，再决定是否值得继续投入；若产品无法接受近距离摆放、音量要求或麦克风授权，换用其他通信链路会是更直接的判断。