3、采样率与帧长：帧长选择的博弈论——延迟 vs 频率分辨率
好，咱们直接切入正题。
采样率和帧长，这两个参数在助听器算法里，就像一对欢喜冤家。你选了高采样率，数据量大了，延迟可能就上去了；你选了长帧长，频率分辨率是好了，但延迟也跟着涨。说白了，这就是一场博弈。
我个人习惯把这个问题叫做「帧长选择的博弈论」。你想想看，我们做嵌入式音频，尤其是助听器，最怕什么？怕用户觉得声音「慢半拍」。那种感觉，就像看视频音画不同步，非常难受。而帧长，就是决定这个「慢半拍」程度的关键因素之一。
3.1 帧长到底在影响什么？
帧长，简单理解就是算法每次处理的数据块大小。比如你设了 64 个采样点为一帧，那算法就得等攒够 64 个点才开始干活。
这直接决定了两个东西：
- 算法延迟：帧越长，你等数据的时间就越长。这是最直观的。
- 频率分辨率：帧越长，你能看到的频谱细节就越丰富。这是做 FFT 分析的基础。
嗯，这里要注意，这两个指标是直接冲突的。你不可能既要低延迟，又要高分辨率。必须做出取舍。
核心矛盾：
帧长每增加一倍，频率分辨率提升一倍，但算法延迟也增加一倍。
我在项目中遇到过一位产品经理，他坚持要 1ms 以内的延迟，同时又要求能分辨出 10Hz 以内的频率变化。我当时就笑了，这物理规律摆在那，神仙也难做啊。
3.2 采样率：另一个维度的博弈
采样率决定了你能处理的最高频率。助听器领域，16kHz 是主流，因为人声的绝大部分能量都在 8kHz 以内。但有些高端产品会用到 24kHz 甚至 32kHz，为了保留更多高频细节。
采样率高了，同样帧长下，延迟会降低。为什么？因为帧长是按采样点数算的，采样率高了，每个点的时间间隔就短了。比如：
| 采样率 | 帧长（点数） | 帧时间（延迟） | 频率分辨率 |
|---|---|---|---|
| 16 kHz | 64 | 4 ms | 250 Hz |
| 16 kHz | 128 | 8 ms | 125 Hz |
| 32 kHz | 64 | 2 ms | 500 Hz |
| 32 kHz | 128 | 4 ms | 250 Hz |
看到了吗？同样的 4ms 延迟，16kHz 下你只能得到 250Hz 的分辨率，而 32kHz 下你就能得到 250Hz 的分辨率。等等，这里好像有点绕。其实说白了，就是你可以用更高的采样率来「换取」更低的延迟，同时保持频率分辨率不变。
我的经验：
如果你对延迟要求极高（比如 3ms 以内），可以考虑把采样率提到 24kHz 或 32kHz。但代价是计算量翻倍，对芯片的 MIPS 要求更高。我曾经在一个低功耗芯片上试过 32kHz，结果电池续航直接砍半，得不偿失。
3.3 实际项目中的帧长选择策略
那到底怎么选？我一般会按这个思路来：
- 先定延迟预算：助听器行业有个不成文的规矩，总延迟最好控制在 10ms 以内。超过这个数，用户就会觉得「有回音」或者「声音不自然」。我个人习惯把算法延迟控制在 5ms 以内，给其他环节留点余量。
- 再算帧长上限：比如你选了 16kHz 采样率，5ms 延迟对应的帧长就是 80 个点。但实际中我们一般用 2 的幂次，所以 64 点或 128 点。64 点延迟 4ms，128 点延迟 8ms。嗯，这里我通常会选 64 点。
- 最后看频率分辨率够不够：64 点 FFT 的分辨率是 250Hz。对于助听器来说，这个分辨率在低频段（比如 250Hz 以下）是不够的。低频需要更精细的分辨率来区分不同的声音成分。
避坑指南：
我曾经在一个项目中，为了追求极致的频率分辨率，把帧长设到了 256 点。结果延迟到了 16ms，用户反馈说「听自己说话有回音」。后来我不得不改用 128 点，并配合一些后处理技巧来弥补分辨率不足的问题。所以，千万别为了一个指标牺牲了用户体验。
3.4 帧长选择的「黄金法则」
做了这么多年，我总结出几条经验，分享给你：
- 16kHz 采样率下，64 点帧长是「万金油」：延迟 4ms，分辨率 250Hz。大部分场景都能用。
- 如果对低频要求高，试试 128 点：延迟 8ms，分辨率 125Hz。适合做降噪和反馈抑制。
- 别轻易用 32 点：延迟是低了，但频率分辨率太差，很多算法效果会大打折扣。
- 帧长和 FFT 点数要匹配：一般帧长就是 FFT 点数。但有些算法会用重叠保留法，帧长可以小于 FFT 点数，这又是另一个话题了。
你想想看，其实帧长选择没有绝对的对错，只有合不合适。关键是要理解你的应用场景：是更在意延迟，还是更在意频率分辨率？
我个人习惯在项目初期，先做一个「延迟-分辨率」的权衡表，把不同帧长下的指标列出来，然后跟产品经理一起拍板。这样后面开发起来，心里也有底。
好，这一节就聊到这。下一节我们会深入讲讲，帧长选择对具体算法（比如降噪、反馈抑制）的影响。到时候我会拿实际代码出来分析，敬请期待。