用途：排查嵌入式 I2S 扬声器（MAX98357A、PCM510x 等）上的静态噪声。噪声成因多种但听感相似，容易误判为硬件问题，因此应以测量数据为先、理论推测为后。
主要能力与步骤： 一、向用户获取精确症状以区分成因：仅在有声前后出现、贴近静音多为功放空闲/时钟门控/DIN 悬空；语音可辨但夹杂噪声或清晰与噪声交替，多为传输中采样错位；语音完全无法分辨多为格式不匹配（字节序、位宽、采样率）；清晰语音下持续微弱嘶声多为功放噪声底/增益/电源轨。 二、先证明源数据是否干净：抓取设备收到的 PCM 并统计。资料提供了一个 python3 脚本示例，统计 RMS、超过半幅值比例与过零率，并分别按大端与小端解析。干净语音过零率约 5–15%、过半幅值约 1–3%；字节交换或乱码时过零率约 40–50%、过半幅值约 40%。资料提到 Gemini TTS 名义上标示 audio/L16（按 RFC 为大端）实际返回小端，应从数据验证字节序而非按标签交换。 三、流式 PCM 对齐陷阱：16 位采样不得跨传输边界拆分。若字节粒度的 FreeRTOS RINGBUF_TYPE_BYTEBUF 收到奇数字节块，消费者按 got/sizeof(int16_t) 计算并归还整个条目，会丢弃落单字节，使后续每个采样偏移一字节；丢弃偶数次则重新对齐（清晰），奇数次则错位（噪声），故出现清晰与噪声交替。修复方式是在写入端保留奇数尾字节并在下次写入前拼接，使进入环形缓冲的始终为偶数字节；话语结束或中止时重置进位，避免半采样渗入下一句。资料提到参考实现位于 packages/robocar/unified/main/audio_player.c 的 audio_player_write。另发现语音文本缓冲 SPEECH_TEXT_MAX 需容纳渲染后句子长度。 四、欠载：流式源产生音频可能慢于 DAC 消耗，欠载听起来像宽带噪声而非空隙。资料称依据 ESP-IDF v5.4 源码验证：i2s_common.c 中 msg_queue 深度为 desc_num - 1，队列满时 TX ISR 丢弃最旧条目；写入者停顿超过 desc_num-1 个描述符周期后，i2s_channel_write() 拿到最旧的空闲描述符，其 memcpy 会写入正被读出的缓冲区，auto_clear 清零无法挽救。修复方向：以预滚（preroll）为门控，攒够 N 毫秒或抓取完成即开始；该“或”是关键，短句可从完整缓冲播放而不会欠载；门控应作为环形缓冲属性而非逐句属性；增大 dma_desc_num；批量写入生产者数据。 五、以上均已排除后才考虑模拟侧：MAX98357A 在该板无 shutdown GPIO，持续放大；门控 BCLK 或让 DIN 悬空会在句间爆音。可选方案为持续输出零值（保持通道开启、空闲时喂静音），或通过释放/扩展 GPIO 门控功放 SD 引脚，最终由用户以听感裁定。
限制：资料未提供完整的安装命令、支持的芯片型号全集、性能指标或定价信息；结论主要基于特定项目的实测记录，应由使用者按自身硬件验证。