基于WebSocket的全双工音频流：ESP32 AI玩偶连续对话链路实战

我一度以为“能对话”和“连续对话”之间差的只是模型的响应速度。后来在 ESP32 上做 AI 玩偶把交互链路从 HTTP 整段录音上传切到 WebSocket 二进制音频流才发现真正挡住体验的不是模型推理快慢而是链路设计。最早那版玩偶是典型的对讲机模式按下按钮开始录音松开上传服务器依次跑完 ASR、LLM、TTS再把整段音频文件传回来播放。一次交互四五秒起步而且用户永远不知道它是在听、在想还是已经死机。这篇文章就把我重构这条链路的完整过程拆开讲从协议设计、ESP32 端采集发送到服务端流水线、全双工打断再到我实际踩过的 1006 断连、播放粘包、缓冲抖动这些坑。适合手上有 ESP32-S3 开发板、想做语音交互玩具或桌面机器人、或者正在被“WebSocket 传音频”折磨的朋友。文章里所有参数和配置都是我实测跑出来的可以直接抄但建议结合你自己的硬件环境微调。1. 从“能对话”到“连续对话”差的不是模型而是链路1.1 对讲机式交互的四个硬伤先复盘最早那版行为的完整链路因为理解痛点才能理解重构的必要性。用户按下玩偶身上的触摸按键ESP32 通过 I2S 接口从 INMP441 麦克风采集音频暂存到内存 Buffer等用户松开按键后把整段录音通过 HTTPS POST 上传服务器。服务器依次调用 ASR、大模型、TTS 三个服务最后把合成好的音频文件传回 ESP32由 I2S 功放模块播放出来。这套流程跑通之后你会发现四个硬伤。第一交互节奏完全由用户触发。按键按下才算一段话的开始这本身就违背了人类对话的习惯——人说话不是“按下再说”的。小孩玩玩偶的时候尤其明显他根本不知道什么时候该按键经常按早了、松晚了录进去一堆静音和杂音识别结果自然稀烂。第二上下文是断裂的。用户说完一句要等整条链路全走完才能说下一句这期间的“等待”不只是延迟更是对话语境的空洞。真正自然的对话里停顿是允许的但每一段停顿都应该是在等对方继续而不是在等一个“处理中”的加载态。第三无法打断。TTS 播放到一半时这套链路没有任何机制让用户插话。实际场景里用户想打断玩偶说话是非常高频的需求——尤其在它开始长篇大论讲一个无聊的段子时。不能打断意味着每次都要等它啰嗦完体验直接崩掉。第四延迟被串行放大。录音整段上传、ASR 要等完整语音、大模型要等 ASR 完成、TTS 要等整个文本生成每一环都在等上一环“彻底做完”才开工。哪怕每个环节只花 500ms用户感知到的也是两秒起步的呆滞感这对“对话”来说是致命的。这四个问题的根源不在模型而在“请求-响应”这种一次性交互范式。它的最小交互单位是“一整段音频”而不是“一帧音频”。要从根上改变体验必须把链路从一问一答式的对象存储交互改成持续流动的流式交互。1.2 全双工音频流是“连续感”的物理基础什么叫连续对话我的定义很朴素双方都能在任何时刻开口双方都能在任何时刻插话而且整个过程中音频是持续流动的而不是一段一段被切割的。这背后要求链路具备两个能力上行持续采集传输下行持续接收播放。前者是 ESP32 端麦克风数据的持续推送后者是服务端合成音频的持续回传。两条方向同时进行这就是通信里说的全双工Full-Duplex。但全双工只是物理基础有了全双工不代表就有连续体验还得处理“什么时候该听、什么时候该停、什么时候能抢话”这些语义问题这就要靠语音活动检测VAD和打断机制配合。这里先区分一个容易混淆的概念全双工链路解决的是“能不能”VAD 和打断机制解决的是“要不要”。链路不通后面所有机制都无从谈起链路通了机制做得糙体验依然是碎的。所以这两件事都得做顺序不能乱。1.3 WebSocket 在 ESP32 场景下的选型理由既然要流式传音频可选的方案其实有几个HTTP 分块传输、SSEServer-Sent Events、MQTT、WebSocket。我逐个对比之后还是选了 WebSocket。HTTP Chunked 能做服务端向客户端的流式回传但上行还要分多次 POST建连成本高而且它本质是单向流做不了全双工。SSE 也是单向的适合服务端推送通知不适合音频这种双向高频数据流。MQTT 倒是全双工ESP32 上也有成熟客户端库但 MQTT 是为消息分发设计的主题订阅和 QoS 机制对音频流来说全是多余开销而且它默认走 TCP 8883 端口在很多网络环境里反而容易被卡。WebSocket 的优势在于它是从 HTTP 升级来的 TCP 长连接原生支持双向实时传输并且协议自带二进制消息类型。音频数据可以直接作为二进制消息发送不需要像 MQTT 那样再套一层业务格式。ESP32 官方 IDF 里有现成的 esp_websocket_client 组件稳定性和内存占用都经过大量产品验证对小内存芯片非常友好。还有个现实因素服务端生态。Python 的 FastAPI/websockets、Node.js 的 ws、Go 的 gorilla/websocket 都有成熟的实现而 ASR、TTS、大模型这些服务的流式接口也基本都是流式返回。WebSocket 正好能和这些流式接口毫无违和感地对接上。所以无论从端侧还是服务侧看WebSocket 都是这个场景下最顺手的全双工管道。2. WebSocket 二进制帧设计采样率、编码格式与帧边界2.1 为什么必须用二进制帧而不是 JSON 文本帧很多第一次做音频传输的朋友会习惯性把音频做 Base64 编码塞进 JSON再用 WebSocket 的文本消息发。功能上勉强能跑工程上是场灾难。先算一笔账。16kHz、16bit、单声道的 PCM 音频一秒钟是 32KB 数据。按 20ms 一帧切每帧是 640 字节。Base64 编码会把数据膨胀约 33%640 字节变成约 854 字节再套一层 JSON 字段名和引号一帧轻松超过 900 字节。单帧看起来不多但音频是每 20ms 一帧、每秒 50 帧持续不断的流量累计下来带宽浪费非常可观。ESP32 走 WiFi 传输带宽和信号稳定性本来就有限没必要在没用的字节上耗掉资源。更关键的是处理开销。ESP32 是 MCU主频最高 240MHz 左右JSON 的序列化和反序列化在 PC 上毫秒级完成在 ESP32 上则要认真掂量 CPU 占用。二进制帧则可以直接用内存块拷贝和指针偏移来读写几乎没有解析成本。另外WebSocket 协议本身对二进制消息有完整的边界保护一条消息对应一个完整的 WebSocket 帧。只要保证每条消息里放的是一个或多个完整的音频帧接收端就能按帧切分不用像裸 TCP 那样处理粘包问题。2.2 音频编码选型PCM、Opus 还是 Speex确定用二进制消息后下一个问题是音频编码格式。这一步直接决定链路的数据量和端侧 CPU 负载必须动手前想清楚。裸 PCM 最省事采集到什么就发什么。优点是端侧零编解码开销、出问题好排查缺点是码率高16kHz/16bit 单声道每秒 32KB。WiFi 信号不稳时容易卡顿长时间录音会产生很大的数据量。Speex 是老牌语音编码压缩率尚可、延迟可控ESP32 上也有移植版但低码率下音质一般项目更新已基本停滞现在不值得从零引入。Opus 是语音场景的最优解。16kHz 采样率下用语音模式16kbps 到 24kbps 码率就能获得不错的可懂度换算过来每秒只要 2 到 3KB不到裸 PCM 的十分之一。Opus 的帧长支持 2.5ms 到 60ms 多档20ms 是语音交互很均衡的选择——延迟可感知编码开销又能摊薄到每一帧。算法延迟约 26.5ms20ms 帧长完全能接受。ESP32 上跑 Opus 需要注意移植方式。ESP-IDF 里可以通过组件管理器直接引入 opus 组件也可以把 libopus 源码编进构建系统。实测在 ESP32-S3 上对 20ms 帧做一次编码CPU 占用大约在个位数到十几个百分点取决于优化等级完全扛得住。我的建议是先跑通链路用裸 PCM协议调稳再切 Opus如果你直接奔着产品级体验做就一步到位用 Opus省得二次返工。Speex 这个中间态没必要选。2.3 自定义协议头与消息类型定义选完编码就得设计应用层消息格式。WebSocket 只保证消息边界但音频流里除了音频数据还要有控制信令——比如“我说完了”“开始合成”“我要打断”——这些信令必须和音频区分开所以需要一个自定义协议头。我在项目里用的二进制协议头是 12 字节定长所有消息统一走这个头字段长度字节说明Magic2固定 0xAA55快速校验消息类型10x01 上行音频0x02 下行音频0x03 控制信令0x04 ACK标志位1bit0 最后一帧bit1 带 VAD 事件序列号4每帧递增排查丢帧时间戳2帧内音频相对会话起始的毫秒偏移载荷长度2紧随其后的音频载荷字节数时间戳非常关键。两端设备的时钟不可能完全一致ESP32 的晶振和服务器时钟存在漂移长期运行后播放端会逐渐快于或慢于发送端音频越听越“紧”或越听越“拖”。有了时间戳接收端可以做缓冲对齐。序列号是排查问题的利器。WiFi 环境下丢帧是家常便饭有了序列号服务端日志里看到 1024 之后直接跳到 1050就知道中间丢了 26 帧定位速度快很多。消息类型里 0x03 控制信令是连续对话的灵魂。打断指令、静音事件、开始说话、结束说话都走它。不要把控制逻辑塞进音频载荷更不要放到另一个 HTTP 接口里——那样就重新引入了建连开销。所有信令走同一条 WebSocket 连接顺序天然有序处理最简单。2.4 帧边界与处理逻辑很多做过裸 TCP 编程的朋友会担心粘包这里先明确一点WebSocket 是面向消息的协议每条消息有明确长度边界不存在 TCP 层面的粘包问题。真正要处理的是“应用层帧对齐”。什么意思你在 ESP32 端每 20ms 生成一帧 Opus 数据但发送时不一定每帧单独发一条消息——每秒 50 条消息的频率会带来不小的开销和抖动。我实践中的做法是每 100ms 攒够 5 个音频帧合并到一条 WebSocket 二进制消息里发送。这样消息频率降到 10 条/秒WiFi 和服务器都轻松很多。但收端就面临一个对齐问题一条消息里有 5 个音频帧每个帧长度因为 Opus 变码率而不固定接收端必须按协议头的载荷长度字段逐帧切分。如果消息末尾残留半帧就要缓存到下一批再处理。我的服务端实现是维护一个残段缓冲区收到二进制消息后先把残段追加到当前数据尾部然后循环解析——读 12 字节协议头读载荷长度切出完整音频帧交给下游直到剩余数据不足一个完整帧就把残段存回缓冲区等下条消息。这段逻辑写起来不到 30 行但它是整条链路稳定性的地基。3. ESP32 端音频采集与发送的工程细节3.1 I2S 采集的 DMA 缓冲配置ESP32 端最底层的活就是把麦克风数据稳定读出来。我用的是 ESP32-S3 加 INMP441这是块 I2S MEMS 麦克风四线接口SCK、WS、SD、L/R接法很常规。在 ESP-IDF 里把 I2S 配置为主接收模式采样率 1600016bit单声道。DMA 缓冲参数是第一个坑。ESP-IDF 的 I2S 驱动通过 DMA 把硬件数据搬到内存DMA 描述符数量和每个描述符的帧数直接决定搬运粒度和中断频率。我实测下来 dma_desc_num 6、dma_frame_num 240 是个顺手的组合每个 DMA 缓冲区是 240 帧 × 2 字节 × 2 声道 960 字节6 个缓冲区共 5760 字节内存开销不大中断频率适中。有个细节容易被忽略INMP441 虽然是单声道 MEMS 麦但 I2S 总线上数据仍然是左右两个声道轮流输出的只有一个声道有有效数据。读数据时要把另一个声道丢掉否则音频速度会慢一倍。代码上就是每 4 字节一组取前 2 字节。采集任务的实时性也有讲究。I2S 读取要用带超时的阻塞读不要死循环轮询。我在 FreeRTOS 里开独立任务优先级设为 5栈 4096 字节循环调用 i2s_channel_read读满 320 个采样点正好 20ms就交给下一层。这个优先级不能太低否则被 WiFi 任务饿死也不能太高抢了 WiFi 任务导致掉线。优先级 5 是我试出来的稳妥值。3.2 分帧发送、时间戳与本地回声抑制数据从 I2S 读出来后下一步是分帧。20ms 对应 16kHz 采样率下 320 个采样点、640 字节裸 PCM。这 640 字节是最小处理单元开了 Opus 就丢给编码器生成压缩帧用裸 PCM 就直接进协议头打包。发送前每帧都要配好序列号和时间戳。序列号用全局 uint32 自增时间戳用 esp_timer_get_time() 换算成毫秒。这里有个关键细节时间戳必须在采集时刻打而不是发送时刻打。因为发送队列一拥堵两个时刻能差几十甚至上百毫秒一旦时间戳标晚了服务端 VAD 和日志分析就全乱了。本地回声抑制是 ESP32 玩偶绕不过去的坎。玩偶音箱和麦克风距离很近TTS 播放的声音会被麦克风重新采上来形成回声。如果服务端不做回声消除玩偶会听到自己说话引发严重的自我打断、自言自语。产品级做法是在 ESP32 上跑 AEC回声消除比如 ESP-ADF 里的 AEC 组件但它对硬件有依赖——通常要配合 ES8311 这类带参考信号的 codec 芯片才能达到理想效果纯 INMP441 方案做 AEC 效果有限计算量还大。我的折中方案是物理上尽量隔离麦克风和喇叭麦克风朝前、喇叭朝下软件上做“打断增益”策略——TTS 播放期间如果麦克风能量超过一个较高阈值就判定用户在大声插话。因为人嘴离麦克风近声音能量通常远大于音箱播出的声音。这个方案不完美但零额外硬件成本实测“小孩对着玩偶说话”这种场景完全够用。3.3 WebSocket Client 选型与内存占用控制ESP32 上的 WebSocket 客户端有几种选择官方 IDF 的 esp_websocket_client、Arduino 生态的 WebSockets 库、自己用 lwIP 裸写。强烈建议直接用官方组件。它已经处理了 TCP 连接、TLS如果要 wss、帧编解码、ping/pong 心跳这些底层细节和 IDF 事件循环无缝集成遇到问题能搜到的资料也最多。内存永远是 ESP32 的主题。ESP32-S3 有 512KB SRAM但 WiFi 协议栈、TLS如果用 wss、RTOS、音频缓冲区都要占。实测一套最小配置下来.bss 加 .data 约 120KB堆上还有 WebSocket 收发缓冲、I2S DMA 缓冲、音频发送队列我用的容量 20 帧约 12.8KB、TTS 播放缓冲。整体峰值内存占用 300KB 上下可接受但继续加功能就要精打细算了。两个具体优化建议第一WebSocket 接收缓冲默认可能较大如果你只收音频帧和信令把缓冲调到能容纳一条最大消息即可省下的内存给播放缓冲。第二局域网内建议直接用 ws:// 而不是 wss://TLS 握手和加解密在 ESP32 上吃掉的内存和 CPU 相当可观语音交互的传输安全由 WiFi 网络本身兜底就够了。发送路径上我用 FreeRTOS 队列把音频帧从采集任务投递给独立发送任务避免在采集任务里直接调用 WebSocket 发送。esp_websocket_client_send_bin 在 WiFi 信号差时可能因 TCP 发送缓冲满而阻塞如果在采集任务里调用会把采集流程卡死导致音频断流。独立发送任务加队列缓冲相当于给系统加了缓冲垫抖动时丢一点延迟不丢连续性。4. 服务端音频链路ASR、LLM、TTS 的流水线调度4.1 上行音频的解包、重采样与识别缓冲服务端我用 Python FastAPI 加 websockets 库每个 WebSocket 连接对应一个 asyncio 任务。收到的二进制消息先按协议解析把音频载荷切出来送进识别前处理流水线。这里有个容易忽略的步骤采样率对齐。ESP32 端 I2S 配的是 16kHz但有些 ASR 服务要求 8kHz 或 16kHz有些本地模型要求 48kHz。在 ESP32 端改采样率不现实所以统一放服务端做重采样。我用 soundfile 加 librosa 的轻量重采样也可以用 webrtcvad 的降采样实现。这步放在 ASR 之前保证端侧采样率怎么配服务端都能正确消费。语音识别缓冲是连续对话的关键。服务端要把碎片化音频帧拼成“话语片段”而不是每来一帧触发一次识别。我的做法是维护一个 10 到 30 秒的环形缓冲持续写入最新音频同时维护一个“已识别边界”指针。VAD 判定一句话结束时把边界到当前位置的音频切出来送 ASR识别完成后推进边界指针。这个设计让你随时能回溯最近说过的话也能在用户连续说话时无缝衔接下一句。4.2 流式 TTS 下行从“生成完再播”到“边生成边播”连续对话的另一个关键突破在下行链路。传统做法是大模型输出完整文本再调 TTS生成完整音频文件后传输播放。这种串行模型在对话场景是灾难——用户说完一句话要等大模型整段生成、TTS 整段合成、文件整段传输三个“整段”叠起来延迟轻松超过 5 秒。正确做法是三个环节全部流式化。大模型用流式接口逐 token 输出TTS 选支持流式合成的引擎按句号、问号等标点切分文本块每生成一个块立即合成一段音频然后立刻通过 WebSocket 把音频帧下行推给 ESP32。这里有个经验不要每个 TTS 分句单独发一条消息而是维护下行音频队列把 TTS 输出的音频按 20ms 帧切好后批量发送。批量大小根据网络状况动态调整——信号差时增大批量减少消息频率信号好时减小批量降低播放延迟。我在服务端用了一个简单的自适应策略统计最近 1 秒内下行消息发送耗时超过 200ms 就把批量从 5 帧提到 10 帧低于 100ms 就降回 5 帧。4.3 服务端“边听边想边说”的状态机服务端核心不只是管道拼装而是一个状态机。我把每个连接会话的状态定为五种状态含义输入事件迁移动作IDLE空闲等待语音VAD 检测到语音开始进入 LISTENING清空 ASR 缓冲LISTENING正在听用户说话VAD 检测到语音结束将 ASR 缓冲送识别与大模型进入 PROCESSINGPROCESSING正在思考/生成回复大模型完成开始 TTS 合成进入 SPEAKING启动下行音频流SPEAKING正在播放回复收到用户打断信令停止 TTS 与下行推送回 LISTENINGEND会话结束收到关闭信令清理连接资源这五个状态看起来简单但它解决了一个很实际的工程问题上行音频流和下行音频流是异步的可能在任意时刻交错到达。没有状态机服务端代码会变成一堆难以维护的 if 分支有了状态机每个事件的处理逻辑都约束在明确的状态上下文里出 bug 时只要看“在哪个状态收到了哪个事件”就能定位。比较微妙的是 PROCESSING 状态的合并。当用户在 SPEAKING 阶段打断并说出新的一句话这时候大模型可能还在生成长句回复。我的处理是收到打断后立即丢弃当前 TTS 队列让大模型生成任务进入可取消状态asyncio task 里检查取消标志等新一句话的 ASR 结果出来后重新发起新一轮生成。不要试图“接着上次的上下文续说”直接开新 turn 更干净上下文通过会话级消息列表维护不依赖音频流顺序。5. 半双工到全双工VAD、打断与静音检测的取舍5.1 VAD 放在端侧还是服务端VAD 负责回答一个问题这段音频里有没有人声。它放端侧还是服务端直接影响链路的复杂度和体验。端侧 VAD 的优点是省流量、省服务端算力。ESP32 上可以做很轻的能量检测计算每帧 PCM 样本的均方根RMS超过阈值判定有声音。缺点是误判率高——环境噪声、音箱回声、拍手声都可能触发。好一点的方案是移植 webrtc VAD 到 ESP32噪声鲁棒性比纯能量检测好不少但代码量和内存占用会上一个台阶。服务端 VAD 的优点是可以跑更重的模型比如 Silero VAD准确率大幅提升端侧逻辑保持极简——只负责推流。缺点是服务端要接收全量音频包括静音段流量和算力成本更高。我的选择是分级处理端侧跑一个极低阈值的能量检测只用来决定“这一帧音频要不要发出去”——能量接近完全静音的帧直接丢弃能省约 30% 到 50% 流量真正的人声判定、端点判定、打断判定全部交给服务端 VAD。这个分级的本质是让便宜手段在前端挡住一眼假的无效数据让昂贵判断留在后端做精细决策。5.2 打断机制播放中采集与回声泄漏处理连续对话体验的胜负手是打断。用户说“停”的时候玩偶必须在几百毫秒内停下。打断的完整链路是ESP32 在 TTS 播放期间保持麦克风采集 → 端侧能量检测发现高能量音频用户说话→ 端侧通过 WebSocket 发 0x03 控制信令打断事件→ 服务端收到后立即停止 TTS 合成与下行播放队列 → 服务端回 ACK → ESP32 收到 ACK 后清空本地播放缓冲。这里有个“先斩后奏”的细节ESP32 不能等服务端 ACK 才停止播放否则会多出一整个 RTT 的延迟。正确的做法是端侧发出打断信令后立即降低播放音量或直接静音等服务端 ACK 到达再做完整清理。真实对话里用户感受到的打断延迟取决于端侧本地处理速度而不是网络往返。打断场景下最大的敌人还是回声泄漏。TTS 播放时用户说话和音箱声音混在一起被麦克风采上来。如果只看能量高能量既可能是用户说话也可能是播放音量调大了。我的处理是双阈值TTS 播放期间的打断阈值比静音监听期间的 VAD 阈值高一档而且要求连续 3 帧60ms都超阈值才判定为打断避免单帧突发噪声误触发。这个参数要实测调整音箱音量越大阈值抬得越高。5.3 端点检测策略与延迟控制的平衡端点检测解决另一个问题用户说完一句话后系统什么时候开始处理这句话它和 VAD 有区别——VAD 判断有没有语音端点检测判断一句话什么时候开始、什么时候结束。最简单的策略是静音计时VAD 检测到语音后开始计时如果连续 N 毫秒检测不到语音就判定话语结束并触发 ASR。N 一般取 500ms 到 800ms。太短会把句中正常停顿误判为结束比如“今天天气……真好”中间的停顿太长会让用户觉得系统反应迟钝。N 值其实可以动态调。我在服务端做了很粗的适配如果上 5 句话的平均语速较快静音超时缩短到 400ms用户语速慢比如小孩说话放宽到 900ms。不需要机器学习统计近几段话语字数和音频时长估算语速即可。另一个取舍是 ASR 触发时机。等静音超时结束才触发用户会明显感到“我说完后停了一拍才有反应”。更激进的策略是“语音结束前提前启动 ASR”——VAD 检测到语音能量明显下降且持续 200ms 时先把前段音频送去做初步识别等确认端点再做最终识别。这个策略能省 300ms 左右感知延迟但会给 ASR 服务增加负载而且用户说完又补一句时要处理识别结果被后半句修正的合并逻辑。我的建议是先做保守版跑顺了再上激进版。6. 实测踩坑1006 断连、粘包与缓冲抖动的排查记录6.1 WebSocket 1006 断连的根因链项目做到一半最头疼的问题是连接随机断开WebSocket 客户端回调报 onclose code1006。1006 表示连接在没有发送任何 Close 帧的情况下异常断开也就是说底层 TCP 连接莫名其妙没了。排查过程是一层层剥的。先看是不是服务器主动断开——去 Nginx 访问日志看发现连接 60 秒左右被切断。查配置默认 proxy_read_timeout 是 60s而 WebSocket 长连接只要 60 秒内没有数据流动Nginx 就会把连接干掉。但我的音频流是有数据的为什么 60 秒内没有数据因为连续对话意味着用户可能在玩偶讲完一句话后 30 秒都不开口这段时间没有上行音频也没有下行音频连接被判定为闲置。第一个修复方案是加心跳ESP32 每 10 秒发一帧 0x03 控制信令或 WebSocket ping 帧服务端收到后回 pong。这样连接永远有流量不会被代理层判定闲置。加心跳后断连依然偶发只是频率降了。继续查发现和 ESP32 的 WiFi 休眠有关。IDF 的 esp_websocket_client 默认对 TCP keepalive 是开启的但底层 lwIP 的 keepalive 超时默认 7200 秒根本起不到短时保活作用。我把 lwIP 的 TCP keepalive 改为 30 秒探测一次同时把应用层心跳改成 15 秒双保险后断连基本绝迹。这里有个教训排查 1006 不能只盯应用层要从底往上查——TCP 层、代理层、NAT 层、睡眠策略每一层都可能掐掉连接。我踩过的根因和解法总结如下根因表现解法Nginx/网关 idle 超时断连时间固定在 60s/300s应用层心跳或调大 proxy_read_timeoutESP32 WiFi 休眠断连时间不规律重启后恢复关闭 modem sleep或调整 keepaliveTCP keepalive 默认超时过长长时间闲置后保活失效缩短 lwIP keepalive 间隔服务端接收缓冲溢出大量上行音频时断开加大 asyncio 接收缓冲或提高消费速度6.2 播放端粘包与“机器人抢话”问题下行音频流跑通后又出现一个诡异现象玩偶经常在 TTS 刚开头的 0.5 秒内“抢话”把整段话在一瞬间压缩着播完然后陷入长时间沉默。问题本质是播放缓冲堆积导致的时基错乱。服务端为降低消息频率把多个音频帧合并成一条消息下发ESP32 收到后用队列缓存、按序播放。但播放任务和接收任务是并发的如果播放任务启动时机不对——比如队列里只有 2 帧40ms 音频就开播那么网络抖动导致的空窗期会让播放器“饿死”播完 40ms 后突然没货然后又来一批数据全部倒出听感就是一句话被压缩着爆出来。解决方法是启动缓冲Startup Buffer。播放任务不要一收到音频帧马上播先积累固定时长缓冲我用 120ms即 6 帧达到目标后开始播放。多付 120ms 延迟换来播放流畅度大幅提升这是延迟和顺滑之间的合理妥协。抢话问题的另一个来源是 TTS 分句合并。服务端大模型流式输出时如果标点切分策略不当可能把完整一句话拆成两半TTS 先合成前半句并下行播放后半句还在生成中ESP32 播完前半句后队列空了只能干等。听感是“机器人说一半突然被掐断”。修复办法是 TTS 切分至少保证一个完整语义单元——按句号、问号、感叹号切不按逗号切。6.3 调优后的参数清单与实测效果最后给出一份我调稳定后的关键参数表方便直接抄作业。这些参数基于我的硬件环境实测ESP32-S3 加 INMP441 加 I2S 功放模块服务端 FastAPI 加 websockets局域网内 WiFi。不同环境需要微调但作为起点足够。参数我的取值说明音频采样率16kHz / 16bit / 单声道ASR 通用输入格式音频帧长20ms320 采样点Opus 标准帧长上行批量5 帧/条消息10 条/秒降低消息频率下行启动缓冲120ms6 帧保证播放顺滑打断阈值静音监听阈值 6dB避免回声误触打断持续判定连续 60ms3 帧窗口心跳间隔15 秒 control 帧连接保活TCP keepalive30 秒lwIP 配置服务端静音超时500~900ms按语速动态调整调完这组参数后实测局域网内从用户说完话到玩偶开口回答首帧音频延迟约 1.2 秒ASR 0.3s 加大模型首 token 0.5s 加 TTS 首帧 0.4s打断响应约 300ms持续对话 30 分钟无 1006 断连。这个成绩离消费级产品还有距离但作为 DIY 玩偶已经非常够用。调试 WebSocket 音频链路时不要只盯着 ESP32 看现象。我强烈建议在服务端写一个简单的回环调试模式——客户端发上来的音频原样下行回传ESP32 收到后直接播放。用这个模式测试 10 分钟如果听到的是连续且不失真的自己说话声说明链路传输没问题如果中间有断裂或吞字那就是缓冲或丢帧问题和 ASR、大模型、TTS 都无关。这个回环测试法能把链路问题和服务问题快速切开省下大量瞎猜的时间。这条链路重构完我自己最大的感受是想让设备“像人一样说话”决定体验上限的往往不是那颗最强的大模型而是音频能不能像呼吸一样顺畅地流动。WebSocket 二进制流只是手段最终目的是让玩偶不再像一个被按一下动一下的机器而是一个真的在“听你说话”的伙伴。下一篇可以聊聊怎么在这个链路上加多轮记忆和角色人设欢迎持续关注。