小智的音频之心：I2S 采集 + OPUS 编码怎么设计

上一节刷固件之后，你手里那块板子已经能开机、连网、亮起来了。但它还是个哑巴——不会听，也不会说。这一节我们就拆开它的音频之心：声音从哪进来、怎么处理、怎么送出去。这条链路一断，小智就只是个会亮屏的摆件；这条链路通了，它才配叫"语音助手"。

先说清楚这一节讲什么、不讲什么。I2S 是怎么回事、三根线各管什么、采样率位深的物理账，L4 的 I2S 音频实战和I2S 原理已经讲透了，这里不重复。这一节只干一件事：看小智这个真实项目，是怎么把这些零件设计成一条能边录边传、边收边放的音频流水线的。 讲设计和取舍，引用非搬运——代码以上游仓库最新版为准。

先看这条音频链走了哪几站

把小智的音频想成一条双向水管，一头是空气里的声音，另一头是云端的大模型。声音在这条管里要经过五站：

采集 → 编码 → 上传   （你说话，往上走）
              ↓
           云端 ASR / LLM / TTS
              ↓
播放 ← 解码 ← 下发   （它回话，往下走）

• 采集：INMP441 数字麦克风用 I2S 把你的声音变成 PCM 采样点，源源不断吐进芯片。
• 编码：芯片把这段原始 PCM 用 OPUS 压一道，体积砍到几分之一。
• 上传：压好的音频帧沿着网络长连接流式送到服务端。
• 下发/解码/播放：云端回话时反着来——TTS 合成的音频（也是 OPUS 压过的）下发到板子，板子解码回 PCM，经 MAX98357 功放推给喇叭。

看懂这五站的顺序，你就知道后面每一段代码在整条链的哪个位置。记住一个关键设计原则：原始音频从不裸奔上网，进出网络那两站中间，永远隔着一层编解码。 为什么，下面细说。

采集端：为什么是 INMP441 + I2S

小智的"耳朵"用的是 INMP441 这类 I2S 数字 MEMS 麦克风，不是那种三只脚的模拟麦。这个选择不是随便定的，它决定了整条链的音质起点。

模拟麦输出的是一根怕干扰的电压线，声音才几十毫伏，在杜邦线上走一段就蹭上电源纹波、Wi-Fi 串扰，ASR 模型会被这些噪声搞糊涂。INMP441 把"采集 + 模数转换"做进了麦克风芯片壳子里，直接吐 24 位数字信号——模拟段极短，几乎不给噪声可乘之机，出来就是 0 和 1，沿 I2S 走多远都不失真。做语音 AI，从起点就用数字麦，这是小智和几乎所有正经语音模组的共识。

采集这一站有个容易被忽略的坑，正是拆真实项目才看得到的增量：INMP441 吐的是 24（或 32）位，但有效位在高位，你读到的 int32 得先右移若干位才拿到真正的振幅。 这一步漏了，声音要么爆音、要么几乎听不见。小智的音频输入代码里，读完 I2S 缓冲后有一步位移和格式归一，把麦克风的原始位宽对齐成后续编码要吃的格式——别小看这几行，它是"能听清"和"一团糊"的分水岭。接线和读取的骨架细节见 L4 I2S 实战和 INMP441 说明，这里不铺代码。

至于采样率，小智语音链路走的是 16kHz、单声道。原因在原理篇算过账：人声主要能量在 8kHz 以下，按采样定理 16kHz 足够覆盖；再往上堆采样率，数据量涨、内存和上行带宽都吃紧，对语音识别却没有收益。16kHz 是语音场景的甜点，不是妥协。 音乐才需要 44.1kHz，语音硬要堆高只是白烧内存。

编码端：OPUS 这道压缩为什么必须有

这是整条音频链最值得琢磨的一个设计决定。先算一笔账你就懂它非有不可。

16kHz 采样、16 位、单声道的原始 PCM，一秒就是 32KB。你要把这段音频边录边流式送给云端 ASR，一次对话说十几秒，就是几百 KB 的裸数据往外推。问题在于：ESP32-S3 的内存本就紧张，上行带宽（尤其走 WiFi 弱信号或 4G）更不富裕，裸 PCM 这个体积扛不住——要么内存爆，要么传输跟不上说话速度，延迟越攒越大，你说完半天它才反应。

OPUS 就是来解这道题的。 它是一种专为语音和实时传输设计的音频压缩格式，能把音频压到原来的几分之一甚至更小，而且天生为低延迟、抗丢包优化——这三点正好卡中"边录边传"的语音链路的命门：

• 压得狠：几百 KB 的裸音频压完只剩几十 KB，上行压力立刻松下来。
• 延迟低：它按小帧编码（常见 20/40/60 毫秒一帧），录一帧就能编一帧、发一帧，不用等整句录完，这才谈得上"流式"。
• 抗丢包：网络抖一下丢几帧，OPUS 能容忍性地恢复，不至于一丢包整句话就废。

所以小智的设计是：麦克风读出的 PCM，先经 OPUS 编码器压成一帧帧压缩音频，再打包沿长连接上传； 云端 TTS 回来的音频同样是 OPUS 压过的，板子收到后先解码回 PCM，才送进功放播放。上行下行两个方向，各挂一套 OPUS 编解码器。

OPUS 在小智里以组件形式引入（上游用的是乐鑫维护的 opus 编解码组件），编码参数（比特率、帧长、复杂度）都可调。这些参数怎么权衡"音质 vs 体积 vs CPU 占用"，属于调优细节，动手时对着上游配置和官方文档核；这里你只要建立一个牢固的设计意识：语音上云，中间必压一道，OPUS 是这条链的默认选择。

数据怎么在设备和云之间流

把采集、编码、网络三站接起来看，小智的音频数据流是这么转的——注意它是双向、流式、异步的，不是"录完再发、收完再放"的一问一答。

往上（你说话）：I2S 靠 DMA 把麦克风采样不停搬进缓冲，音频任务从缓冲取出一段 PCM → 做位移归一 → 喂给 OPUS 编码器压成一帧 → 交给网络层沿长连接送出。这一串在一个循环里连轴转，你还在说话，前面的话已经在往云端流了。

往下（它回话）：网络层收到云端下发的 OPUS 音频帧 → 解码回 PCM → 写进 I2S 发送缓冲 → MAX98357 功放把数字音频转模拟、推给喇叭发声。同样是流式的，TTS 一边合成一边下发，板子一边收一边放，不用等整句合成完。

这里有个真实项目才教得会你的设计细节：采集和播放要能同时进行（你话没说完它可能就开始应答，或者需要打断），所以音频链路通常拆成独立的任务，靠队列在采集、编码、网络、解码、播放各环节之间传数据。用队列解耦，某一环偶尔慢一拍，不至于把整条链卡死——这是嵌入式实时音频的常规范式，也是FreeRTOS 那套任务与队列在真实项目里的用武之地。

小结 · 下一步

这一节我们拆开了小智的音频之心，抓住的是设计而非代码：

• 五站链路：采集 → 编码 → 上传 →（云）→ 下发 → 解码 → 播放，双向流式，原始音频从不裸奔上网。
• 采集：INMP441 用 I2S 吐 24 位数字信号，比模拟麦干净；有效位要右移对齐；语音走 16kHz 单声道这个甜点。
• 编码：OPUS 是这条链的命门——它压得狠（内存/带宽扛得住）、延迟低（按小帧编，才能流式）、抗丢包，专治语音场景。
• 数据流：全双工、流式、异步，各环节拆成独立任务、靠队列解耦，不是串行的一问一答。

这些设计怎么落到能跑的接线和代码，回 L4 I2S 音频实战补物理层，采样率位深的账见 I2S 原理，麦克风本身看 INMP441。

下一步：声音能采、能压了，可它还得有条路送上云、把结果收回来。压好的 OPUS 帧到底沿着什么连接、以什么协议在设备和服务端之间流动？去下一节联网与传输，拆小智那条把音频推上去、把回答拉回来的"神经"。想回看整条链的全局，随时翻项目总览。