波仔
🎬 第四章 音频基础
📄 一句话概括

同一个音频技术，场景不同要求差很远——四个场景里只有【音乐欣赏】对延迟不敏感。

📝 本节和前面几节的关系

前面讲了采集、处理、存储，这一节跳出技术，看场景怎么反过来决定参数。

一、四大类场景

音乐欣赏：听歌、看片——追求音质，可以慢慢缓冲。 实时通话：打电话、视频会议——追求不卡不断，音质可以妥协。 语音交互：语音助手、语音输入——追求识别准，延迟要低。 音乐制作：录音棚、编曲——追求无损与极低监听延迟。 四类场景用的技术是同一套，但要求的参数完全不同。

二、延迟这一维

为什么实时音频比离线音频难？因为离线可以慢，实时不能。 离线播放可以攒几秒缓冲，卡一下也没人察觉。 实时通话里，声音必须在几十到一百多毫秒内走完采集、编码、传输、播放。 每多缓冲一点，就多一份延迟——这构成了实时音频的根本约束。

三、场景决定参数

音乐欣赏：44.1／48 kHz，对延迟不敏感，最怕音质损失。 语音通话：8／16 kHz，延迟必须小于 150 ms，最怕断续。 语音助手：16 kHz，延迟小于 300 ms，最怕识别不准。 音乐制作：48／96 kHz，监听延迟小于 10 ms，最怕卡顿。 注意只有第一行对延迟不敏感——其余三个场景里，延迟都是硬指标。

四、一个判断习惯

拿到任何音频需求，先问它属于哪一类场景，再定参数。 顺序反了就会出现典型错误：把通话做成高保真（延迟爆炸），或把音乐做成低码率（音质报废）。 同一个采样率不可能对所有场景都最优——这是这一节最想留下的一句话。

五、动手 Demo：同一个音频技术，场景不同要求差很远

四个场景的参数要求，排在一起看差别非常明显。

rows = [
    ("音乐欣赏", "44.1/48 kHz", "不敏感",  "音质损失"),
    ("语音通话", "8/16 kHz",    "< 150 ms", "延迟与断续"),
    ("语音助手", "16 kHz",      "< 300 ms", "识别不准"),
    ("音乐制作", "48/96 kHz",   "< 10 ms",  "监听延迟"),
]
for a, b, c, d in rows:
    print("%-8s %-12s %-10s %s" % (a, b, c, d))

实跑输出：

--------------------------------------------------------------------
同一个音频技术，场景不同要求差很远
--------------------------------------------------------------------

  场景         采样率要求      延迟要求     最怕什么
  -----------------------------------------------------
  音乐欣赏     44.1/48 kHz     不敏感       音质损失
  语音通话     8/16 kHz        < 150 ms     延迟与断续
  语音助手     16 kHz          < 300 ms     识别不准
  音乐制作     48/96 kHz       < 10 ms      监听延迟

  注意【音乐欣赏】那一行：**它是唯一对延迟不敏感的场景。**
  其余三个场景里，**延迟都是硬指标**——这就是实时音频比离线音频难的原因。

注意第一行：音乐欣赏是唯一对延迟不敏感的场景。 其余三个场景里，延迟都是硬指标——这就是实时音频比离线音频难的原因。

30 秒实验

  1. 写下你现在最常做的一件音频事（听歌／通话／录音／剪辑）。
  2. 判断它属于哪一类场景，据此写下你该选的采样率与延迟要求。

常见误区

  1. 一套参数走天下。同一个采样率不可能对所有场景都最优。
  2. 无视延迟。实时场景里延迟是硬指标，不是体验加分项。
自测三问（点开对答案） 1. 四个典型场景里，哪个对延迟不敏感？ —— 音乐欣赏（离线播放，可以慢慢缓冲）。 2. 为什么实时音频比离线难？ —— 离线可以缓冲、可以慢；实时必须在几十到一百多毫秒内走完全链路。 3. 定参数的正确顺序是什么？ —— 先确定场景，再由场景反推采样率、延迟与质量要求。

相关笔记