ESP32+WebSocket二进制流：从对讲机到连续对话AI玩偶的链路重构

最近把手里那个只会“一问一答”的 ESP32 AI 玩偶彻底改了一遍通信层从按钮对讲机变成了真正的连续对话。先说结论核心改动不在 AI 模型而在 WebSocket 二进制音频链路的重构。原来走 HTTP 上传录音、再等整段文本和整段语音回来延迟和交互感都很差现在改成 WebSocket 全双工二进制帧后首包音频延迟能压到几百毫秒体验完全不一样。这篇文章就把整个链路从协议设计、帧格式、ESP32 端实现到服务端流水线编排完整拆开讲适合正在做 ESP32 语音设备、智能玩具、本地语音助手或者想把现有语音硬件从“半双工轮询”升级成“流式全双工”的开发者参考。我会把原理、代码、参数和踩过的坑都交代清楚尽量让你看完能直接抄作业。1. 为什么要把音频链路改造成 WebSocket 二进制流1.1 半双工轮询为什么会让人难受先回顾一下最传统的“能对话”实现方式——按键触发式用户按住按钮说话松开后整段录音文件上传到服务端服务端先做完整的语音识别ASR把识别文本交给大语言模型LLM生成回复再把整段回复文本做语音合成TTS最后把整段音频文件回传给 ESP32 播放。从用户视角看这个流程体验极其糟糕。假设你说了一句话 2 秒钟流程中各环节耗时大概是录音上传 0.3 到 1 秒WiFi 环境不同差异很大ASR 整段识别 0.5 到 1 秒LLM 生成首 token 可能 0.5 秒生成完整文本 1 到 2 秒TTS 整段合成 0.5 到 1 秒音频下载加播放又是一个完整句子时长。粗算下来你说完一句“今天天气怎么样”之后至少要等 3 到 5 秒才能听到答案。关键问题在于这些时间是串行累加的而且每个环节都在等上一步“完整结束”中间有大量等待空隙。更致命的是交互模式的割裂感。用户必须知道“我要先按住按钮”说话期间不能听回复播放期间通常也不能说话否则录音就串了。这就像对讲机而不是对话。模型再聪明交互层是半双工体验就被死死锁在“玩具”的档位。1.2 全双工链路的核心架构与方案选型要让玩偶从“能对话”走向“连续对话”本质是把通信链路从“文件传输”改成“实时流传输”。我把目标拆成四个要求麦克风音频要持续分帧上行服务端能在用户说话过程中实时返回中间状态TTS 音频生成一部分就下发一部分播放过程中用户能随时打断barge-in。这四个要求同时满足交互体验才会接近人和人说话。传输层选型上我最开始对比过三个方案HTTP 轮询、SSEServer-Sent Events、WebSocket。HTTP 轮询先被排除因为每次请求都要重新建立连接而且要自己设计双端缓冲延迟高又浪费流量。SSE 支持服务端向客户端单向推送文本流没问题但客户端要持续上传音频就不顺得额外再开一路 HTTP 上传两条链路的状态同步很别扭而且 SSE 对二进制帧的支持也比较绕。最终选 WebSocket原因很直接全双工、基于 TCP 长连接、原生支持二进制帧Binary Frame、生态成熟。服务端和 ESP32 端都有可用的 WebSocket 库把底层握手和分片处理都封装好了我可以把更多精力放在音频帧协议上。很多人以为 WebSocket 只是“能传消息”实际上它最值钱的能力是二进制帧通道。语音本质是 PCM 采样点或者 Opus 编码后的字节流天然适合二进制帧承载。如果继续用 JSON 文本包一层比如{audio: base64字符串}编码膨胀和数据解析开销都不小。16kHz、16bit、单声道的 PCM 裸流一秒钟就是 32000 字节Base64 编码后膨胀到约 42667 字节多出 33% 的流量。对 ESP32 这种内存和 WiFi 带宽都有限的设备来说这是完全可以规避的浪费。所以我在方案里直接定了个规矩音频数据一律走二进制帧JSON 文本只用来传控制指令和事件。1.3 整条音频链路的数据流向设计改造完成后我画的链路逻辑其实很清晰ESP32 通过 I2S 接口读取模拟麦克风或数字麦克风比如 INMP441的 PCM 数据按固定时间窗口切成小块每 20ms 的音频数据打包成一个二进制 WebSocket 帧实时上行到服务端服务端接入流式 ASR语音识别服务边收边识别利用静音检测VAD判断用户是否说完一句话一句话识别完成后把文本交给 LLMLLM 流式生成回复文本服务端把已经生成的那部分文本立刻送入 TTSTTS 边合成边返回音频块服务端再把音频块用二进制帧下行推给 ESP32ESP32 写入 I2S 功放播放。这里最关键的工程认知是“分片与流水线并行”。上行音频按 20ms 分片下行 TTS 音频也按 20ms 到 60ms 分片整条链路像一条流水线ASR 跑的时候麦克风还在采LLM 生成文本的时候ASR 已经在下游等待TTS 合成第一句话的时候LLM 可能已经在生成第二句。各个模块纵向打通之后用户感受到的延迟就不再是“所有环节时间相加”而是“首包音频下发的延迟”这个数值可以压到 300 到 800 毫秒。2. 二进制帧协议的设计与编解码2.1 帧结构定义别嫌头大这是全链路的基石音频链路重构中最容易忽视、但最值得花时间的地方就是自定义二进制帧协议。WebSocket 只管“传二进制消息”但不关心消息里装的是什么。如果不定义自己的帧结构服务端收到一坨字节根本分不清哪段是音频、哪段是控制指令、哪段是心跳包。尤其当 ASR 中间结果、LLM 增量文本、TTS 音频块、打断指令混在一起时没有协议就是灾难。我在项目里最终采用的帧结构如下所有多字节整数统一用大端序Big Endian字段长度说明magic2 字节固定 0xAA55用于快速校验和对齐version1 字节协议版本当前为 1opcode1 字节帧类型见下文sequence2 字节序列号用于丢帧检测和播放排序timestamp4 字节音频采样时间戳毫秒用于播放队列抖动消除payload_len2 字节载荷长度最大 65535payload不定长音频数据或文本数据帧头一共 12 字节加上 payload 就是完整的一帧。有人可能觉得 12 字节头在音频场景下很浪费其实完全不用担心如果每帧带 640 字节 PCM 音频20ms 16kHz 16bit12 字节头只占 1.8% 左右如果走 Opus 压缩20ms 音频通常只有 60 到 80 字节这时头部占比会高一些可以改成 40ms 一帧来摊薄开销。opcode 这块我定义了 6 个常用值0x01 上行音频帧0x02 下行音频帧0x03 上行文本命令如唤醒词触发、配置切换0x04 下行文本事件如 ASR 中间结果、LLM 增量文本0x05 心跳 Ping/Pong0x06 打断指令Play Interrupt。把这几个 opcode 定义清楚后服务端的主循环就变成一个大 switch按 opcode 分流处理逻辑非常清爽。2.2 音频编码与采样参数的计算过程音频帧的编码格式选择直接决定链路延迟、流量和 ESP32 的 CPU 占用。我实测对比过 PCM 直传和 Opus 压缩两种方案最终项目中默认走 Opus 压缩同时保留 PCM 模式用于调试。PCM 方案参数采样率 16000Hz位深 16bit单声道。每 20ms 的采样点数是 16000 / 1000 × 20 320 个采样点每个采样点 2 字节所以一个音频块是 320 × 2 640 字节。这个 640 字节就是我们每次 WebSocket sendBinary 的 payload 大小。如果不做任何压缩16kHz 16bit 单声道意味着每秒 32000 字节一分钟约 1.92MB这是裸 PCM 的带宽成本必须在选型时想清楚。Opus 方案参数Opus 编码器在 16kHz 采样率下码率可以压到 24kbps 到 32kbps。以我常用的 24kbps 为例20ms 音频块的理论大小是 24000 / (1000 / 20) / 8 60 字节。也就是说同样 20ms 的数据量Opus 能把 640 字节的 PCM 压到 60 字节左右压缩比超过 10 倍。代价是 ESP32 需要跑 Opus 编码通常会占一个核 10% 到 20% 的 CPU取决于主频和优化等级对 ESP32 来说这个开销完全可接受。还有一个工程细节不要在 ESP32 上用太高的码率档位实测 24kbps 到 32kbps 对口语对话已经完全够用码率再高对识别准确率没有明显提升反而白白增加带宽和编码耗时。解码播放侧也要注意下行音频如果走 OpusESP32 需要跑 Opus 解码器。解码后的 PCM 数据要按 I2S 的字时钟和位时钟写入。我实测下来解码 20ms 音频在 ESP32 上耗时只有几毫秒完全不会造成播放卡顿问题主要出在缓冲区管理上后面章节会专门讲。2.3 为什么要用二进制帧而不是 JSON 包装这个点值得单独拿出来说。很多 WebSocket 教程都会教{type: audio, data: base64...}这种 JSON 结构写成代码确实直观但在音频链路上这是个隐形杀手。开销不仅仅是 Base64 的 33% 膨胀。更重要的是 JSON 解析是有 CPU 成本的ESP32 是 Xtensa 双核 240MHz 的 MCU解析大量 JSON 字符串会白白烧掉宝贵的算力。音频流每秒要传输几十帧数据每帧都做一次 JSON 序列化/反序列化CPU 占用和堆内存碎片都会明显上升。而且在 ESP32 这种内存有限的设备上JSON 解析需要额外字符串缓冲区内存峰值不好控制我在早期版本里就遇到过反复 malloc/free 导致堆碎片最后干脆全换成固定字节数组处理二进制帧内存占用立刻稳定下来。从稳定性角度讲二进制帧的字段长度和偏移量固定解析逻辑就是“从 buffer 里按偏移量取值”几乎不会出现“键名拼错”“类型不匹配”这类低级错误。调试时用 Wireshark 抓包也能直接看到每个字节的含义比在一堆 JSON 字符串里找音频数据高效得多。所以我强烈建议只要你的音频链路有任何实时性要求就直接放弃 JSON 包装音频的念头用自定义二进制帧一步到位。3. ESP32 端与服务端的双工链路实现3.1 ESP32 端的 WiFi 与 WebSocket 连接管理硬件端我使用的是 ESP32-S3 系列外接 INMP441 数字麦克风和 MAX98357A I2S 功放模块。开发框架用的是 ESP-IDF 5.xWebSocket 直接使用官方组件esp_websocket_client这个组件支持 TLS、自动重连、二进制帧收发比自己在 lwIP 上裸写协议栈省心得多。连接管理上有两个必须做好的细节第一是 WiFi 和 WebSocket 的依赖关系。ESP32 刚上电时 Wi-Fi 可能还没连上WebSocket 客户端的transport层会一直重试这个重试逻辑本身没问题但要注意设置合理的reconnect_timeout_ms。我设置的是 3000ms 基础值失败后每次翻倍最多 30 秒封顶防止服务器不可用时每几百毫秒就疯狂触发重连。第二是心跳机制。WebSocket 有 Ping/Pong 帧但esp_websocket_client组件默认的心跳配置比较保守我选择在应用层每 30 秒发送一个 opcode 为 0x05 的二进制心跳帧服务端收到后回复同样 opcode 的 Pong。如果连续 3 次心跳没有收到回复客户端主动断开并重连。这个机制看起来简单但对长连接稳定性特别重要尤其是一些路由器 NAT 超时时间比较短空闲连接不保活的话很容易被中间设备静默断开。3.2 音频采集分帧与发送的代码骨架ESP32 端实现的核心是三个任务录音任务、发送任务、接收播放任务。我直接贴一段录音分帧发送的核心逻辑骨架基于 ESP-IDF// I2S 配置16kHz, 16bit, 单声道 i2s_config_t i2s_cfg { .sample_rate 16000, .bits_per_sample I2S_BITS_PER_SAMPLE_16BIT, .channel_format I2S_CHANNEL_FMT_ONLY_RIGHT, .communication_format I2S_COMM_FORMAT_STAND_I2S, .dma_buf_count 8, .dma_buf_len 320, // 20ms 音频块 }; // 录音循环读出 640 字节 PCM 后做 Opus 编码并组帧发送 int16_t pcm_buf[320]; uint8_t frame[FRAME_HEADER_LEN 640]; opus_int16 opus_in[320]; uint8_t opus_out[640]; while (1) { size_t bytes_read 0; i2s_channel_read(i2s_tx_handle, pcm_buf, sizeof(pcm_buf), bytes_read, portMAX_DELAY); // 编码为 Opus得到压缩后的字节数 int opus_len opus_encode(opus_encoder, pcm_buf, 320, opus_out, sizeof(opus_out)); // 组装自定义二进制帧 frame[0] 0xAA; frame[1] 0x55; frame[2] 1; // version frame[3] OP_AUDIO_UPLINK; // opcode frame[4] (uint8_t)(seq 8); frame[5] (uint8_t)(seq 0xFF); // timestamp 和 payload_len 按同样方式填充 // ... memcpy(frame FRAME_HEADER_LEN, opus_out, opus_len); esp_websocket_client_send_bin(client, frame, FRAME_HEADER_LEN opus_len, pdMS_TO_TICKS(50)); seq; }这段代码的关键点在于I2S DMA 缓冲长度dma_buf_len 320正好对应 20ms 音频读一次就是完整的一帧数据省去了额外拼接。发送时esp_websocket_client_send_bin是同步接口会给一个超时时间避免底层发送队列堆积时无限阻塞。如果 WiFi 信号差导致发送超时录音任务会因为超时等待而退避天然形成一种背压backpressure不至于让内存无限堆积。3.3 服务端流水线ASR、LLM、TTS 如何并行编排服务端我用的 Node.jsTypeScriptWebSocket 库用的ws。整条流水线的核心编排思路是“三段式流式处理”。第一段是上行音频识别。收到 opcode 0x01 的二进制帧后把 payload 里的 Opus 字节解码成 PCM或者直接透传给云端 ASR 服务同时把音频数据送入流式 ASR 的 AudioInputStream。ASR 返回的结果有两种中间结果is_finalfalse和最终结果is_finaltrue。中间结果可以推给 ESP32 显示“正在听你说话”也可以直接丢弃因为后面还有大模型在把关。最终结果出现时说明用户一句话说完了这时候触发第二阶段。第二段是 LLM 流式生成。LLM 采用 streaming 方式返回每生成一小段增量文本就立刻把这段文本推送到三方模块。这里有个细节不需要等 LLM 完整生成结束才开始 TTS而是按句子切分比如按标点句号、问号、感叹号切分一个完整句子生成完就送去 TTS实现“边说边写”。第三段是 TTS 音频下发。TTS 服务支持流式返回时每返回一段音频块比如 20ms 到 200ms 的 PCM/Opus服务端就封装成 opcode 0x02 的下行音频帧推给 ESP32。这样首包音频的延迟主要由“第一句文本生成耗时 第一段 TTS 合成耗时”决定而不是整句加整段合成的总耗时。我在局域网环境实测从用户说完话到听到第一个字能稳定控制在 500 到 900 毫秒和原来 3 到 5 秒的等待相比完全是两个世代的体验。服务端还有一个容易忽略的点——打断逻辑。当 ESP32 播放下行音频时如果用户开始说话麦克风采集到有效语音VAD 判定语音活动ESP32 需要向服务端发送 opcode 0x06 打断指令。服务端收到后立即停止当前 TTS 音频下发并清空待发送队列。同时 ESP32 本地也要清空播放缓冲保证用户新说的话不会被旧回复盖住。这个双向清空动作是“连续对话”体验的临门一脚少了它就不像人跟人聊天。3.4 ESP32 播放任务与音频缓冲队列下行播放的逻辑我单独设计了一个带“水位”管理的 FIFO 队列。WebSocket 收到 opcode 0x02 的下行音频帧后先把解码后的 PCM 数据存入队列播放任务从队列里取数据并写入 I2S。队列有一个目标水位我设为 200ms 音频换算成 PCM 就是 16000 × 0.2 × 2 6400 字节。为什么要有 200ms 的水位因为网络存在天然的抖动WiFi 环境下一秒内可能出现几个 20ms 到 50ms 的延迟尖峰。如果收到一帧就立即播放任何一个网络抖动都会直接变成声音卡顿如果队列缓存太深又会让用户感觉回复反应变慢。200ms 是实测下来比较平衡的值在局域网稳定环境下用户几乎感知不到这 200ms 的额外延迟但网络抖动时播放依然流畅。播放任务还要处理“语音打断”时的清空操作。一旦收到 0x06 打断指令播放任务会立即清空整个 FIFO并拉低 I2S 输出或输出一段短暂静音确保用户一开口玩偶立刻“闭嘴听你讲”。这个动作在代码里其实就是queue_reset()加i2s_zero_dma_buffer()但设计上没有这个状态机的话很容易出现“打断后还播半句旧语音”的尴尬情况。4. 调试、踩坑与稳定性优化4.1 常见问题速查表与排查思路我重构这套链路时踩过不少坑整理成一张速查表按出现频率排序现象可能原因解决方案连接建立后几秒被断开服务端配置了maxPayload二进制帧超过限制服务端把maxPayload和perMessageDeflate配置合理压缩默认关闭“stream disconnected before completion”报错服务端返回数据时连接已关闭或 TLS 握手失败检查 WebSocket 握手路径是否经过代理代理是否支持 Upgrade 头播放有明显杂音或嘶嘶声I2S 位深不匹配ESP32 读到了 32bit 数据当成 16bit设置I2S_CHANNEL_FMT_ONLY_RIGHT并确认麦克风格式与 I2S 配置一致语音延迟高但不丢帧播放队列水位过高把 jitter buffer 水位从 500ms 降到 200ms一段时间后自动断线NAT 超时或服务端空闲连接回收应用层 30 秒心跳保活ESP32 反复重启堆内存不足或任务栈溢出用heap_caps_get_free_size监控调大录音/播放任务栈到 4096 字节服务端收到帧但解析失败帧头长度不对或字节序错误在服务端打印帧头各字段原始值和 ESP32 端逐个字节比对其中stream disconnected before completion这个报错我在折腾 Nginx 反向代理时遇到得最多。WebSocket 走 Nginx 代理时默认配置如果你不主动设置proxy_read_timeout和proxy_buffering off连接非常容易异常断开。后来我把代理层改成location /ws/ { proxy_pass http://backend_ws; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; proxy_send_timeout 3600s; proxy_buffering off; }这个配置里proxy_buffering off尤其关键它保证服务端发下的音频帧不会被 Nginx 缓冲成“攒一批再发”。否则流式 TTS 的意义就废了客户端收到的音频会是一坨延迟突然爆发的大包。4.2 延迟与稳定性的平衡调优链路调优本质是在延迟、吞吐、稳定性三者间找平衡。我调整过程中有几个印象深刻的点。第一个是 Nagle 算法。WebSocket 底层的 TCP 连接默认可能启用 Nagle小包会被延迟合并发送。20ms 一帧音频数据如果你发的包太小比如 Opus 60 字节Nagle 可能会把几个包攒在一起发送导致每帧延迟增加几十毫秒。ESPNOW 和 Wi-Fi 底层有时还会叠加 Delayed ACK两者一起会造成明显的延迟抖动。我的做法是在 socket 层面关闭 NagleESP-IDF 里可以设置TCP_NODELAY// 在 WebSocket 底层 socket 设置 TCP_NODELAY int flag 1; setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, flag, sizeof(flag));实验效果非常明显关闭后 20ms 一帧的发送节奏立刻稳定下来不再出现 60ms 到 80ms 的随机抖动。第二个是任务优先级。录音和发送任务不能设置成最高优先级否则播放任务会被饿死导致声音断续。我在 FreeRTOS 里把录音任务设为 5播放任务设为 6发送任务设为 4WiFi 底层任务维持默认优先级。这个分配保证高码率下行音频时播放任务始终能抢到 CPU 及时写 I2S而录音任务即便偶尔抖动一两个 20ms 帧也不会影响整体通话。第三个是内存预分配。ESP32 上做音频链路最忌频繁 malloc。我在初始化时把所有固定大小的 bufferI2S DMA buffer、Opus 编码输入输出 buffer、网络发送 buffer一次性分配好整个运行期间不再动态申请大块内存。这样既避免了堆碎片也把内存峰值控在一个可预测的范围内。实测下来这套链路跑一整天空闲堆内存几乎不掉。4.3 心跳保活与断线重连的工程细节长连接稳定性的两个支柱是心跳和重连。心跳我前面说过是 30 秒一次这里补充一个细节服务端不应该只被动回 Pong还应该主动检测客户端是否存活。我在服务端实现了一个简单的“最后活跃时间”记录收到任何一帧包括音频帧都更新这个时间每 60 秒扫一遍超过 90 秒没有活跃的连接直接关闭由客户端侧触发重连。这样比单纯依赖 Ping/Pong 更可靠因为有些路由器会把 Pong 帧正常放行但数据帧已经在某个环节被掐断了。重连策略我用的是指数退避加抖动Exponential Backoff with Jitter。基础时间 1 秒每次失败乘 2最大 30 秒然后加一个 0 到 500ms 的随机抖动。之所以加随机抖动是因为玩偶如果批量上电所有设备同时重连会对服务端造成瞬时连接风暴抖动能有效抹平峰值。ESP32 端还有一个容易踩的坑是 WiFi 重连和 WebSocket 重连的联动。如果 WiFi 连接断了WebSocket 必然断这时候esp_websocket_client的重连可能触发太早WiFi 还没恢复就反复失败。我的做法是在应用层监控esp_netif的事件WiFi 断开时先暂停 WebSocket 重连等GOT_IP事件后再调用esp_websocket_client_start重新开始连接。这样既省电又避免了无效重连刷日志刷到爆。5. 实测效果与接下来值得做的扩展5.1 链路改造前后的实测数据对比为了让改造效果更直观我把同一个玩偶、同一个云端大模型服务分别用旧方案HTTP 整段轮询和新方案WebSocket 二进制流跑了一组对比测试。场景是用户问“今天有什么新闻”测试统计从“用户停止说话”到“开始听到第一个字”的首包延迟以及整句话播放完成的完整交互时间指标旧方案HTTP 整段新方案WebSocket 二进制流首包音频延迟3.2 秒左右0.6 到 0.9 秒音频上行方式文件整体上传20ms 分帧实时上行下行音频方式整段音频文件下载TTS 分片实时下发是否支持打断不支持支持VAD 打断指令数据格式JSON Base64自定义二进制帧 Opus平均交互时延5 到 8 秒1.5 到 3 秒这个对比已经能说明问题。旧方案的交互时延随回复长度线性增长因为要等整段 TTS 合成完才下载新方案的交互时延主要取决于“第一句话文本生成 第一段 TTS 合成”后续音频边生成边播放用户感知反而没有明显变慢。5.2 从“能对话”到“连续对话”的体验差异很多没做过音频设备的人可能会问那 3 到 5 秒的延迟真的那么重要吗做过语音交互产品的人会告诉你非常重要。延迟超过 2 秒用户会本能地觉得“这东西傻了”或者“它没听见”延迟降到 1 秒以内用户才会有“它在认真听我说话并且马上回应”的感觉。再往前一步连续对话的意义在于用户可以自然地和玩偶来回交流。比如你先问“今天天气怎么样”它回答后你立刻追问“那明天呢”中间不需要按钮不需要唤醒词因为麦克风链路始终在跑VAD 自动判断你在说话。这种体验才是 AI 玩偶区别于“语音问答机”的关键分水岭。5.3 后续可以继续做的扩展方向这套 WebSocket 二进制音频链路稳定跑起来之后我还在规划几个扩展点。第一个是端侧唤醒和端侧 VAD 的进一步升级。目前 VAD 我主要依赖服务端但端侧如果能提前做一层简单的能量检测可以省掉很大一部分无效上行流量。ESP32 上可以做一个低功耗监听模式平时只跑一个轻量 VAD检测到语音能量超过阈值再唤醒完整音频链路。第二个是音频的多路并发。一个 ESP32 玩偶未来可能要同时处理“本地播放 上行录音 云端远程音频下行”多路流这就需要在协议层引入更多流 ID 的概念。目前协议帧里靠 timestamp 和 sequence 做播放排序后续可以加一个 2 字节的 stream_id 字段为将来多路音频流比如同时播放背景音乐和语音回复留好扩展位。第三个是更精细的插话和打断策略。现在打断是“一刀切”用户一说话就清空播放队列。更自然的策略是判断用户的插话是提问还是闲聊如果是闲聊可以继续播放如果是提问才打断。这个需要把 ASR 的中间结果接入打断判定逻辑也是我下一步正在做的东西。至少到目前从按键对讲机到 WebSocket 二进制流连续对话这个关键跨越已经让我手里的玩偶真正有了“活物感”这趟重构非常值得。