从 ESP32 音频上传 Demo 到产品级实时音频流传输层：SDD-00 设计记录

最近我在重新思考一个看似简单、但实际很容易被低估的问题：

如何为 ESP32 设计一个产品级的实时音频流传输模块？

注意，这里不是做一个完整语音交互产品，也不是做一个新的 WebSocket 或 WebRTC Demo，而是只聚焦一个子系统：

Audio Capture / Encoder           Audio Decoder / Player
        ↓                                  ↑
        └────── Audio Stream Transport ───┘
                         ↓ ↑
                  Protocol Backend
                         ↓ ↑
              Server / Cloud / AI Service

也就是音频采集/编码和音频解码/播放之间，与底层网络协议 backend 相连接的这一层。

1. 为什么从“上行”改成“音频流”？

最开始我把问题描述成“实时音频上行传输层”。这个定位没有错，但还不够完整。

真实语音产品通常不只有上行。

它至少包含：

设备麦克风音频上传到云端。
云端 TTS 或语音回复下发到设备播放。
远程播报或云端音频流下发。
未来可能支持半双工或全双工语音交互。

因此，项目定位应该从：

ESP32 产品级实时音频上行传输层

升级为：

ESP32 产品级实时音频流传输层

项目名也从 esp-audio-uplink 调整为更中性的：

esp-audio-stream

2. 为什么这个问题值得重新设计？

让 ESP32 把音频发到服务器，或者从服务器接收音频播放，并不难。

很多 Demo 都可以做到：

while (recording) {
    read_audio_frame(frame);
    websocket_send(frame);
}

或者：

while (playing) {
    websocket_recv(frame);
    player_write(frame);
}

这些写法适合演示，但如果要进入真实产品，就会立刻遇到更难的问题。

上行方向：

Wi-Fi 断开 5 秒后怎么办？
服务端消费速度变慢时，发送队列会不会无限堆积？
网络恢复后，要不要继续发送旧音频？
实时语音的最大上传延迟如何控制？
音频采集任务会不会被网络发送阻塞？

下行方向：

云端 TTS 下发中断后怎么办？
网络抖动时播放缓冲如何控制？
播放任务变慢时，接收队列会不会无限堆积？
新的语音回复到达时，是否应该打断旧音频？
播放缓冲下溢时如何上报和恢复？

这些问题不是“协议能不能传音频”能解决的，而是产品级音频流传输策略问题。

3. 这个项目暂定叫什么？

暂定项目名：

esp-audio-stream

中文定位：

ESP32 产品级实时音频流传输层

一句话描述：

esp-audio-stream 是一个面向 ESP32 系列资源受限设备的实时音频流传输策略层，用于让设备侧音频上行、服务端音频下行以及未来双向音频流在弱网、断线、慢消费、慢播放、队列堆积、播放缓冲下溢等真实产品场景下保持可控、可观测、可恢复。

4. 它不是一个什么项目？

这是 SDD-00 阶段最重要的部分。

它不是：

I2S 麦克风驱动。
扬声器 / I2S 播放驱动。
音频编解码库。
完整音频 pipeline 框架。
ESP-ADF 替代品。
WebRTC 重写。
SIP / RTSP / RTMP 协议栈。
通用网络库。
云端语音识别 SDK。
云端 TTS SDK。
ESP32 WebSocket 音频上传 Demo。
ESP32 WebSocket 音频播放 Demo。
协议合集。

如果项目走向这些方向，很容易变成低价值重复劳动。

5. 与 ESP-ADF 的关系

ESP-ADF 是必须研究、兼容和借势的生态基座，但它不是本项目的直接竞品。

更准确的分层是：

ESP-ADF = 音频应用开发框架
esp-audio-stream = 实时音频流传输策略层

ESP-ADF 擅长处理 audio pipeline、audio element、ringbuffer、codec、I2S stream、HTTP stream、播放器、录音器、蓝牙音频、VoIP、RTSP/SIP/RTMP 等音频应用场景。

而 esp-audio-stream 只关注一个更窄的问题：

实时音频流在弱网、断线、服务端慢消费、客户端慢播放、队列堆积、播放缓冲下溢等情况下，如何保持可控、可观测、可恢复？

未来它可以有几种接入方式：

ESP-ADF Pipeline Uplink:
I2S Reader → Encoder → esp-audio-stream uplink sink

ESP-ADF Pipeline Downlink:
esp-audio-stream downlink source → Decoder → I2S Writer

Minimal ESP-IDF Application:
I2S Driver / Codec / Player ↔ esp-audio-stream session

6. 为什么不是直接 WebSocket？

直接 WebSocket 当然可以。

对于 Demo、局域网测试、简单音频上传或播放、小规模产品，直接 WebSocket 可能已经足够。

但 WebSocket 本质上是通信通道。它不会替你定义：

上行音频帧最大生命周期。
下行音频帧最大生命周期。
发送队列最大缓存时长。
接收 / 播放队列最大缓存时长。
队列满时丢新帧还是旧帧。
断线重连期间如何处理音频。
服务端慢消费时如何避免上行延迟无限增长。
客户端慢播放时如何避免下行延迟无限增长。
如何统计丢帧、延迟、重连、播放下溢和错误原因。

如果这些问题都由业务代码临时处理，最后业务代码本身就会变成一套隐式的传输策略层。

7. 为什么不是直接 WebRTC？

直接 WebRTC 也可以。

如果产品完全基于 WebRTC，设备资源足够，服务端架构也是 WebRTC，并且已有方案能满足状态管理、统计、重连、诊断和服务端协同，那么没有必要再做一套厚重封装。

这个项目不应该替代 WebRTC。

更合理的关系是：

WebRTC = 未来可能的 backend adapter
esp-audio-stream = backend 之上的统一音频流传输策略层

8. 核心价值在哪里？

这个项目的价值不是“又实现了一个协议”。

它真正想解决的是：

有界发送队列。
有界接收 / 播放队列。
音频帧生命周期。
过期帧丢弃。
服务端慢消费时的上行延迟控制。
客户端慢播放时的下行延迟控制。
Wi-Fi 断线后的状态机。
重连后是否补发或播放旧音频。
音频采集、发送、接收、播放解耦。
丢帧原因统计。
播放缓冲下溢 / 溢出统计。
错误分类。
弱网测试与价值验证。

一句话总结：

协议能传音频，不代表产品级音频流行为可控。

9. 第一阶段真正的对标对象

项目第一阶段不直接对标 ESP-ADF，也不急着对标 WebRTC 或 QUIC。

第一阶段对标对象应该是：

Direct WebSocket Baseline

包括：

Uplink Baseline:
Audio Frame → websocket_send()

Downlink Baseline:
websocket_recv() → Audio Frame → player_write()

候选方案是：

Audio Capture / Player ↔ esp-audio-stream ↔ WebSocket Backend

这两组实现需要在相同硬件、相同音频源、相同服务端、相同网络故障下对比。

10. MVP 范围

MVP 不追求多协议。

首版最小有价值形态是：

统一 AudioFrame
+ 方向字段：uplink / downlink / control
+ 有界发送队列
+ 有界接收 / 播放队列
+ 音频帧生命周期
+ 丢帧 / 播放缓冲策略
+ WebSocket backend
+ 连接状态机
+ 重连恢复
+ 收发统计
+ 错误分类
+ 测试服务端
+ 故障注入工具
+ Direct WebSocket baseline 对比

首版可以优先把上行验证做深，同时保留下行接口、状态和测试框架，避免项目名和抽象被 uplink 锁死。

11. 当前 SDD-00 结论

最终判断：

让 ESP32 收发音频不稀缺；
让 ESP32 在真实网络环境下稳定、可控、可诊断地持续处理实时音频流，才是价值。

因此，esp-audio-stream 可以继续推进，但必须保持边界：

不做 ESP-ADF 替代品。
不做 WebRTC 重写。
不做协议合集。
不做简单音频上传 / 播放 Demo。
第一阶段必须围绕 Direct WebSocket baseline 做价值验证。
如果价值验证失败，应缩小项目范围。

这是 SDD-00 阶段最重要的结论。