家人们先说说我为啥要把这玩偶的音频链路整个推倒重来。手头这个基于 ESP32 的 AI 玩偶项目最早跑的是“一问一答”模式按下按钮说话、松手等回复、播放 MP3、结束。当时觉得挺像那么回事直到拿去给朋友家孩子演示孩子对着玩偶说了句“给我讲个故事”玩偶答完“好的在讲了”然后……空气安静了五秒。孩子直接问我“它是不是坏掉了”那一刻我意识到用户要的不是一个会回答问题的录音机他们要的是“连续对话”——像打电话一样能随时插话、随时中断、随时再来一轮。这篇就完整记录我这次用 WebSocket 二进制音频链路重构 ESP32 AI 玩偶的全过程包括帧协议设计、ESP32 端代码改造、服务端状态机调整、以及一堆实测里才暴露的坑。1. 旧链路是“对讲机模式”我先复盘了这三点才动手1.1 一次让我决定重构的翻车演示先说清楚旧链路当时是什么体验。用户按住玩偶身上的触摸按钮开始说话松手后玩偶通过 HTTP 把整段录音 POST 到服务器服务器先跑 ASR 识别成文字再丢给大模型拿回复文本接着调 TTS 合成一整段音频最后返回一个 MP3/OGG 文件玩偶边下边播。这套流程单看每一步都没毛病但串在一起就全是问题。那次演示的完整时间线我记得特别清楚孩子 14:32:05 松手玩偶 14:32:07 才开始有反应识别出的文字在 14:32:08 才出现大模型想了 2 秒多TTS 合成又花掉 1.5 秒等到玩偶真开口已经是 14:32:14。也就是说从“孩子说完话”到“玩偶开始说话”中间隔了差不多 7 秒。成年人知道这是技术延迟小孩不知道小孩只会觉得“它坏了”。更致命的是没有打断能力。TTS 播到一半孩子突然抢话说“不对我要听奥特曼”玩偶根本不理你非要把当前这整段朗读完才肯听下一个指令。这种体验放在智能音箱上都会被吐槽放在一个本来主打“陪伴感”的玩偶身上基本等于劝退。1.2 旧的“半双工”架构到底卡在哪从通信模型上看旧链路本质是半双工上行录音和下行播放永远不会同时发生。录音期间不播、播放期间不听双方轮流占用信道。HTTP 又是典型的请求-响应模型一次请求只能拿到一个完整资源服务器不可能在录音还没结束时就把第一段 TTS 音频推过来。这就意味着“连续对话”需要的两个关键前置条件旧链路一个都不满足流式传输音频数据不是一次性打包上传的用户说话时麦克风采到的每一帧数据都应该尽快进入识别管线而不是等整句话录完。全双工下发服务器一旦生成音频响应应该立刻推给设备开始播放而不是等所有内容合成完再一次性下发。像“嗯”“然后呢”这种语气词合成出 200ms 就能先播出去用户会感觉机器“活”了。1.3 旧方案里三个必须拆掉的地基问题复盘之后我把旧链路的问题归纳成三个层面这三个问题决定了泥瓦匠式修补没有意义必须重构。第一个是协议选型问题。HTTP 短连接根本无法承载“一句话拆成几十帧连续上行 音频流持续下行”这种时序。就算硬用 chunked response 模拟流式客户端也要维护一套极别扭的半连接状态而且 HTTP 头部开销在弱网下占比高得离谱。第二个是数据格式问题。旧链路传输的是完整音频文件格式还是 MP3。MP3 编码有帧头对齐要求每一帧 1152 个采样点在低码率下延迟和封包效率都差。另一个问题是音频文件必须等服务器全部合成完毕后才能拿到完整时长播放器没办法在接收开头 20ms 数据时就开始解码播放。第三个是设备端管线问题。ESP32 端录音和播放用的是同一个 I2S 总线配置思路但实际采集线程和播放线程互相独立缓冲管理混乱。旧代码里我直接用了两个esp32-audioI2S这类库函数没有做统一的抽样率/位深管理导致录音的 16kHz PCM 传到服务器、服务器返回的却是 44.1kHz 的 MP3设备端还得转码降采样白吃一截 CPU 和内存。把这三个问题写清楚后重构方向就非常明确了用 WebSocket 长连接替代 HTTP 短连接用二进制音频帧替代文件传输用统一采样率的 Opus 码流替代 PCM/MP3 混杂。接下来一个个说。2. 新链路设计二进制帧、Opus 与全双工 WebSocket 的组合拳2.1 为什么偏偏选 WebSocket而不是 HTTP/2 或裸 TCP先说 WebSocket 的几个特性这些都是从这次重构里实际尝到甜头的。第一是连接复用。一次握手成功后上行和下行共用同一条 TCP 连接设备端不需要为每一轮对话重新建连。我实测过ESP32 走 Wi-Fi 建一个 TLS 连接光握手就要 500ms 到 2s而在连续对话场景用户每 20 秒就抛一句话用短连接光 TLS 握手就吃掉一大半延迟预算。第二是天然全双工。HTTP 1.1 没法做到服务端随时主动推数据除非 SSEHTTP/2 虽然支持 server push 但用起来限制多而且嵌入式端 HTTP/2 实现太少见没必要给自己找麻烦。WebSocket 协议本身就不区分“请求-响应”双方随时可以往对方发数据帧这跟语音对话的实时交互模型完全贴合。第三是二进制帧支持。WebSocket 规范里定义了 text frame 和 binary frame语音数据走 binary控制指令走 text一套连接两种载荷互不干扰。相比之下如果用 JSON 嵌套 base64 传 PCM 数据光编码膨胀就是 33%ESP32 上还得一遍遍做 base64 编解码纯属浪费算力。顺带补充一句如果你是在服务端选型Node.js 的ws库、Golang 的gorilla/websocket或gobwas/ws都行。我自己服务端用的是 Node.js 的ws处理二进制帧和流式转发非常顺手。做嵌入式客户端时ESP-IDF 环境下用原生esp_websocket_client组件即可Arduino 环境下则常用ArduinoWebsockets库两者底层都兼容 binary frame。2.2 二进制帧结构这次定清楚后面少改十次这是整个重构里我认为最核心的设计决策。协议头必须兼顾两点足够简单让 ESP32 在中断和低内存环境下能快速解析足够自描述让服务端不用维护会话状态就能知道每一帧在干嘛。我最终定下来的帧格式是 4 字节定长头部 变长负载偏移 长度 字段 说明 0 1 magic 固定 0xAB用来快速过滤脏数据 1 1 type 帧类型0x01 音频上行0x02 音频下行0x03 文本事件0x04 控制帧 2 2 seq 帧序号设备端从 0 开始自增用于排查丢帧和乱序 4 4 ts_ms 采集/生成时间戳相对开机时间 8 2 payload_len 负载长度单位字节 10 0-1500 payload 音频数据或文本/控制内容别小看这个 seq 和 ts_ms。真上线后你会发现排查“为什么用户听着音频一顿一顿”这类问题光靠 Wireshark 抓包是效率极低的因为 TCP 层看不到应用语义。有了 seq服务端一算连续两帧序号差值就能判断是不是设备端有丢帧有了 ts_ms你能算出“采集→上云→识别→合成→下发→播放”每一跳的精确耗时。我在调试阶段就是把这两字段打印出来才发现播放线程优先级不足导致的周期性卡顿。type 字段也别省。有朋友问我为啥不把服务端合成音频直接也当文本帧处理我只回了句客户端每个 type 走完全不同的处理函数你省掉这一个字节后续就要写一堆 if 判断代价完全不成比例。2.3 Opus 编码与 16kHz 单声道带宽和延迟的平衡点一开始我也纠结过到底用 PCM 直推还是压缩。PCM 的好处是省掉编解码的 CPU 开销16kHz、16bit、单声道下码率固定 256kbps一小时对话就是约 115MB 流量对 Wi-Fi 来说其实也够。但问题在于公网链路不稳时256kbps 持续上行很容易把上行带宽打满尤其在 2.4GHz Wi-Fi 干扰严重的环境里丢包和延迟会同时恶化。Opus 是语音场景最稳的选择。我配置成 16kHz 采样率、单声道、码率 24kbps编解码复杂度设为 5。这个配置的实测效果语音可懂度和 PCM 几乎无差别带宽却只有原来的 1/10。设备端 opus_encode 一帧 20ms 的音频ESP32-S3 240MHz 大概只花 1.8ms CPU 时间完全在可接受范围。选择 20ms 的帧长也是有讲究的——语音编解码惯例中 20ms 是低延迟和压缩率的最佳平衡点太长如 60ms虽然码率更低但端到端延迟明显增加太短如 10ms压缩率又上不去。服务端识别引擎我用的也是 16kHz 采样率的标准接口这样设备端采集端根本不需要做重采样I2S 采集的 16kHz PCM 丢进 Opus 编码器、传到服务端解码后就是识别引擎能直接处理的裸 PCM。把采样率这件事从头到尾统一成 16kHz省掉了降采样环节这条链路才称得上“纯”。另外提醒一下Opus 库编译进 ESP-IDF 时建议直接使用opuscomponent 或esp-opus这类封装不要在 Arduino 里手动塞一堆 C 源文件否则后面 OTA 升级时版本管理会让你怀疑人生。3. ESP32 端重构实战I2S、环形缓冲与任务的三角博弈3.1 硬件选型与 I2S 配置里最容易踩的坑先交代硬件。这次用的是 ESP32-S3 加一颗 ES8311 音频编解码芯片麦克风走 I2S 输入喇叭走 I2S 输出。ESP32-S3 的向量指令对 Opus 这类浮点运算有一些优化空间实际测下来比经典 ESP32 编码效率高不少建议新项目直接上 S3。I2S 配置是整个设备端最容易出问题的地方。ESP-IDF 5.x 中正确配置方式如下#include driver/i2s_std.h i2s_chan_config_t chan_cfg { .id I2S_NUM_0, .role I2S_ROLE_MASTER, .dma_desc_num 6, .dma_frame_num 240, .auto_clear true, }; i2s_std_config_t std_cfg { .clk_cfg I2S_STD_CLK_DEFAULT_CONFIG(16000), .slot_cfg I2S_STD_PHILIPS_SLOT_DEFAULT_CONFIG(I2S_DATA_BIT_WIDTH_16BIT, I2S_SLOT_MODE_MONO), .gpio_cfg { .mclk GPIO_NUM_2, .bclk GPIO_NUM_3, .ws GPIO_NUM_4, .dout GPIO_NUM_5, .din GPIO_NUM_6, .invert_flags {0}, }, }; i2s_new_channel(chan_cfg, tx_handle, rx_handle); i2s_channel_init_std_mode(tx_handle, std_cfg); i2s_channel_init_std_mode(rx_handle, std_cfg);有几个细节坑到过我这里直接说结论DMA 描述符数量不要少于 4帧数不要少于 160。太小会导致 I2S 中断频率过高CPU 空转在中断上下文里太大则会增加音频延迟。我试过 6×240中断大约每 30ms 一次比较舒服。16kHz 采样率要配 16bit 位深别为了省带宽去用 8bitES8311 内部会做位深转换但转换会引入额外的量化噪声。mclk 必须提供。ES8311 这类编解码芯片内部 PLL 需要 MCLK 做参考有些库默认不启 MCLK会导致输出有轻微杂音。我这次是从 ESP32 的I2S_MCLK引脚输出 2.048MHz 给 ES8311。3.2 环形缓冲区和任务拆分让“嘴”和“耳朵”各干各的这是这次重构里改动最大、收益也最明显的一块。旧代码是在同一个loop()里先读麦克风、再处理逻辑、再写喇叭天然串行。重构后我把音频 IO、网络 IO 和逻辑处理拆成了三个独立 Tasktask_mic优先级 5负责从 I2S RX 读数据 → 塞进上行环形缓冲。task_ws_send优先级 6从上行环形缓冲取数据 → Opus 编码 → 打包成 ws_audio_frame → WebSocket 发送。task_ws_recv优先级 4接收下行二进制帧 → Opus 解码 → 塞进播放环形缓冲。task_spk优先级 5从播放环形缓冲取数据 → I2S TX 写出。关键点在于两个环形缓冲。ESP-IDF 里官方freertos/ringbuf.h提供的RingbufferType_t足够用但要注意创建时可选用RINGBUF_TYPE_BYTEBUF还是RINGBUF_TYPE_NOSPLIT。音频帧是固定大小的 buffer直接用NOSPLIT保留完整帧语义会方便很多读侧用xRingbufferReceiveUpTo尽可能多拿几帧批量处理减少系统调用次数。上行缓冲大小建议 8KB 左右。因为 20ms Opus 帧很小缓冲可以容纳几百毫秒音频这样即使网络偶尔抖一下也能平滑掉。下行缓冲我开了 24KB主要原因是为了对抗服务端一次性把整段 TTS 音频发完的突发流量。缓冲区越大抗突发越强但延迟也随之升高24KB 在 16kHz/16bit/PCM 解码前约等于 0.75 秒实际在弱网环境里表现不错。这里还有一个调优经验播放任务优先级不能太高否则会抢占网络收包任务导致下行缓冲堆积。ESP32 双核的调度逻辑里核心 0 通常跑 Wi-Fi 协议栈核心 1 跑应用任务。我建议把task_ws_recv和task_spk固定到核心 1 上并且task_spk优先级比task_ws_recv低一级这样网络包到达时能第一时间被取走而 I2S 播放只要保证不欠载就行欠载时缓冲区内还有几百毫秒余量可以补。3.3 回声消除与打断Barge-in的处理思路连续对话最大的体验要求是“能打断”。也就是说玩偶正在说话时用户直接开口它得能立刻停下并开始听用户下一句指令。这一步如果做不好整个重构就白干了。我知道业界产品级方案是上 AEC声学回声消除把喇叭播放的声音从麦克风采集里减掉。但在 ESP32 上用开源 AEC 效果一般ES8311 自带一些 ANC 能力但配置复杂我这次并没有依赖硬件 AEC。我实际采取的是一种“软打断 半双工窗口”策略设备端播放 TTS 音频时把麦克风采集到的音频继续往服务器发但服务端语音活动检测VAD模块的灵敏度调低。用户说话的能量超过播放平均能量的 1.5 倍以上且持续超过 300ms判定为用户打断服务端立刻下发一个control: barge_in帧设备收到后立即清空下行播放缓冲、停止当前播放任务。用户在玩偶说话时环境噪声没那么大所以这种基于能量比的判据在室内场景已经足够稳定。我实测这个方案在正常家庭噪音环境下打断成功率大概在 95% 左右。偶尔会有误触发比如电视声音太响引发打断但整体体验已经比旧版强太多。真要做产品级下一阶段我会考虑在离线侧挂一个轻量的 AEC 模块但当前重构阶段没必要为了所谓“完美”卡住进度。4. 服务端配套改造流式状态机、断句与 1006 重连4.1 从“请求-响应”到“流式状态机”的转变服务端是整个链路里最容易被低估的部分。旧服务端代码就是三个独立接口/asr、/llm、/tts每个接口独立处理一次请求。重构后我在服务端维护了一个简单的 WebSocket 会话状态机每个连接内部维护当前状态-------- 收到音频上行 --------- 检测到完整句 --------- | LISTEN | ------------ | ASRING | ------------- | LLMING | -------- --------- --------- | 流式拿到增量回复 | v --------- 播放完成后 CANCEL/IDLE --------- 合成一帧发一帧 | PLAYING | ------------------------ TTSING | --------- ---------这个状态机的核心价值是让 ASR、LLM、TTS 三段流水线并行起来。用户第一句话还没说完ASR 的中间结果已经开始往 LLM 输入LLM 开始生成回复时第一个词语一出来 TTS 就已经在合成TTS 合成出前 200ms 音频立刻通过 WebSocket 下发。端到端延迟就这样从串行的 7 秒压缩到了 1.1 秒左右。需要注意的是LLM 流式输出接口比如 OpenAI 风格的 SSE 流需要逐 token 转发到 TTS 管线。市面上很多 TTS 引擎不支持“逐 token 合成”但支持“窗口式增量合成”即你给前 500ms 文本就能先合一段继续补充文本则从上次断点继续。我实践下来这种方案效果尚可但偶尔会有边界字音发飘所以后来改成了LLM 每输出约 20 个中文字符就触发一次增量 TTS 合成保证每个音频分片内部语义完整。4.2 静音检测、断句与用户抢话的判据连续对话场景里服务端必须能区分“用户停顿思考”和“用户说完了”。这里我用了一个组合判据单独靠能量阈值一定会翻车。VAD 能量阈值基于用户前 500ms 音频的平均能量动态调整固定阈值在安静和嘈杂环境下效果天差地别。无话时长检测到语音后静音超过 700ms 判定为一句结束但如果当前已识别的文本以“但是”“然后”“所以”这类连接词结尾则放宽到 1200ms。这个规则是从日常口语习惯里倒推的人说话时这些词后通常有停顿。下发半句就算一句没结束只要已识别出超过 8 个字的稳定文本就先把这部分文本送给 LLM 和 TTS。因为 LLM 模型多少能猜出后半句的大致意图提前合成可能造成“半句答复”现象所以这条规则要配合打断功能使用。用户抢话的逻辑在状态机里其实很简单。只要当前状态不是LISTEN服务端收到能量足够的音频上行帧就认定是打断下发barge_in控制帧然后把状态机重置回ASRING丢弃之前 LLM 生成的未播放内容。看似粗暴但从产品角度看这就是用户要的“连续对话”——机器和人都在实时响应而不是各说各的。4.3 掉线、1006 与服务端主动断开重连策略不能偷懒WebSocket 长连接在公网环境下掉线是常态。你搜[websocket] onclose code 1006会看到海量帖子1006 意味着连接异常关闭通常由网络切换、超时、中间层空闲断连导致。对 ESP32 设备来说Wi-Fi 休眠、路由器 DHCP 租约到期、运营商 NAT 超时都可能导致 1006。我的处理方案分三层第一层是心跳保活。设备端每 20 秒发一个 ping 控制帧服务端收到后回复 pong。如果设备端连续 3 次没收到 pong就主动调用esp_websocket_client_close并进入重连流程。这个间隔要仔细调太短会多吃电量太长又无法及时感知断线。20 秒是我在电池场景下的折中选择。第二层是指数退避重连。第一次失败等 1 秒第二次 2 秒第三次 4 秒最多退避到 30 秒并加入随机扰动±20%。这样能避免多台设备集体掉线后同时重连把服务端打崩。第三层是服务端状态还原。设备重连后服务端不能默认用户还在上一轮对话要发送一个hello控制帧携带当前会话 ID 和必要上下文。设备端收到后清空所有缓冲区和状态机回到LISTEN状态。简单说就是连上先别急着说话先互相确认身份再恢复现场。我在 Node.js 服务端用ws库监听close事件时特意记录了 close code 和 reason。1000 表示正常关闭比如设备主动休眠不重连1006 等异常码才走重连逻辑。这个判断很关键否则设备休眠时会反复重连。另外还有个小坑ESP32 端用esp_websocket_client时如果上一条连接没有完全 close 干净就立刻新建底层 lwIP 的 socket 资源会泄漏。我处理方法是重连前先esp_websocket_client_stop等 100ms 后再esp_websocket_client_start实测能显著减少重连失败率。5. 重构后的实测数据与后续想继续做的方向5.1 端到端延迟从 7 秒降到 1.1 秒数字会说话先上实测数据。测试环境是家里 200M 宽带 2.4GHz Wi-Fi手机热点模式服务端部署在云服务器ESP32-S3 ES8311Opus 16kHz/24kbps帧长 20ms。指标重构前重构后从说完话到开始听到回复约 7 秒约 1.1 秒第一帧音频开始播放的时间必须等整段 TTS 完成约 0.8 秒用户打断响应时间不支持约 150ms单轮对话上行流量约 64KB整段 PCM/MP3约 8KBOpus 压缩后WebSocket 连接数每次新连每会话 1 条用户主动询问“它是不是坏了”频繁发生基本消失这 1.1 秒里麦克风采集到 Opus 上行的链路约 120ms服务端 ASR 先出结果约 350msLLM 首个 token 约 300msTTS 增量合成首包约 200ms下行 WebSocket 传递约 80msESP32 解码播放约 50ms。这条流水线时间上是重叠的所以总延迟比串行累加小得多。单独看 ASR 中间结果的意义也很重要。即使 LLM 还没开始回答只要玩偶在听完用户说话后 100ms 内开始有表情动作比如灯光变化、点头用户就会觉得机器“有反应”。这是纯技术指标替代不了的体验提升。5.2 内存、CPU 和电量的代价是否值得重构不是没有代价。新增的 WebSocket 长连接、Opus 编解码器、两个环形缓冲区、三个任务让 ESP32-S3 启动后内存占用从重构前的约 150KB 涨到约 190KB。但因为 ESP32-S3 通常有 2MB PSRAM部分大块缓冲我显式分配到 PSRAM 上内部 SRAM 只保留了运行关键路径的小缓冲所以还有宽裕。CPU 占用上Opus 编码在 ESP32-S3 240MHz 双核上约占 5% 单核能力解码约 3%加上 WebSocket 协议处理约 4%整体对系统的影响可忽略。真正的开销大户是 Wi-Fi RF 常开和音频编解码芯片的供电重构后因为对话变长玩偶实际使用中平均功耗比旧版高了 15% 左右但对于插电底座充电的玩偶来说完全不是问题。如果未来做纯电池版我建议下一个版本加上低功耗唤醒链路平时关闭 Wi-Fi 和音频编解码芯片只保留一个低功耗音频唤醒引擎ESP-SR 的 WakeNet 在 ESP32-S3 上运行效果不错检测到唤醒词再快速拉起网络和音频管线。这样待机功耗能降到 10mA 以下。5.3 后续想继续做的三件事这次重构把“连续对话”的骨架搭好了但离真正的“自然陪伴”还有一段路。第一是本地 VAD 本地打断。目前打断判断依赖服务端网络 RTT 100ms 之内问题不大但如果 Wi-Fi 信号差导致 RTT 到 400ms打断响应就会明显迟钝。ESPRESSIF 的 ESP-SR 里有现成的语音活动检测组件下一步我打算在设备端做瞬时能量检测高于阈值时立即关闭下行播放缓冲再等服务端确认这样打断响应能压到 50ms 以内。第二是多模态表情同步。既然音频链路已经是二进制流式了我计划在帧类型里新增一种event帧专门传表情、动作、灯光指令等非音频事件。比如 TTS 说到“开心”时服务端可以在这个词前面插入一个表情帧玩偶的眼睛提前亮起这种音画同步体验会让陪伴感再上一个台阶。第三是离线兜底模式。儿童用户有大量场景家里网络不稳我也不想让玩偶一断网就变傻。准备在本地跑一套极简的固定问答库比如儿歌、古诗、简单对话通过服务端下发的离线包在启动时加载到 PSRAM。这样断网时玩偶至少能做 80% 的简单应答等网络恢复再无缝切回大模型。最后分享一个调试小技巧吧也是这次重构里我觉得最能省时间的一件事。给 WebSocket 帧协议里的 seq 字段和 ts_ms 字段打日志时不要用 ESP_LOG 那种容易刷屏的方式而是单独开一个调试频道只有当seq % 50 0或者检测到乱序时才打印。这样平时跑业务完全无感一旦出问题立刻能拿出“第 10 秒到 14 秒之间上传帧序号有 12 帧缺失”这种精确线索。排查弱网问题的时候这个字段会救你无数次。