声音的数字之旅：从声波到耳朵的完整指南

发表信息: by

前言

不知道你有没有想过这个问题：当你拿起手机给朋友打电话说「喂」的时候，你的声音是怎么「飞」到对方耳朵里的？

毕竟，声音本质上就是空气的振动，它又不能真的「飞」过去。那中间到底发生了什么神奇的事情？

这篇文章就来聊聊这个话题。我会尽量用大白话把数字音频这件事讲清楚，不需要你有任何技术背景，只要你对「声音是怎么变成数据的」这个问题有点好奇就行。

一、声音的完整旅程：六个神奇的阶段

先来看看全貌。当你对着手机说话，声音要经过这么六个阶段才能到达对方的耳朵：

第一步：声波产生

你的声带振动，推动周围的空气分子来回晃动，形成一种肉眼看不见的「压力波」——这就是声波。你可以想象往平静的湖面扔一颗石子，水波一圈圈扩散出去，声波大概就是这个感觉，只不过它是在空气里传播的。

第二步：采集与数字化

声波撞到手机的麦克风上，麦克风把这种「空气振动」转换成「电信号振动」。然后一个叫 ADC（模数转换器）的小芯片，每秒钟给这个电信号「拍」好几万张「快照」，把连续的波形变成一串数字。

这一步特别关键，因为电脑只认识 0 和 1，不认识「波形」。所以必须把声音「翻译」成数字，电脑才能处理。

第三步：编码压缩

原始的数字音频数据量太大了——待会儿我会告诉你有多大。所以需要一个「编码器」来压缩数据，把文件缩小到原来的 1/10 甚至 1/20，同时还要尽量保证你听不出区别。

这一步就像是给声音「减肥」，减掉的都是「赘肉」（人耳听不到的部分），保留的是「肌肉」（人耳敏感的部分）。

第四步：网络传输

压缩好的数据被切成一个个小「包裹」，通过 WiFi 或者 4G/5G 网络「快递」出去。这些小包裹会在网络上七拐八拐，最终到达对方的手机。

第五步：解码还原

对方的手机收到这些小包裹后，解码器负责把它们「解压缩」，还原成原始的数字音频。这个过程必须要快，否则通话就会卡顿。

第六步：播放出声

最后，DAC（数模转换器）把数字信号变回电信号，功放把信号放大，扬声器的振膜开始振动，推动空气——声波就这样重新产生了，传到对方的耳朵里。

整个过程只需要几十毫秒，比你眨一下眼睛还快。是不是挺神奇的？

好，现在你已经知道了声音旅行的全貌。接下来我们一步一步展开聊。

二、声音的数字化：把「波」变成「数」

2.1 一个灵魂问题

这里有个根本性的问题：声音是连续的「波」，电脑只认识离散的「数」（0和1），这俩东西怎么能互相转换呢？

答案是：采样。

什么是采样？想象你用相机拍一个正在跑步的人。如果你一秒钟只拍 1 张照片，那你就只能看到这个人在某一个瞬间的姿势，完全不知道他是怎么跑的。但如果你一秒钟拍 1000 张照片，然后快速翻看，你就能看到一个流畅的「跑步动画」。

采样就是这个道理。我们不可能把整个连续的声波都记录下来（那需要无限的存储空间），但我们可以每隔一小段时间「拍一张快照」，记录那一瞬间声波的高度。只要「拍照」的速度足够快，我们就能用这些离散的点，还原出一个非常接近原始声波的曲线。

2.2 采样率：每秒拍多少张「照片」

采样率（Sample Rate） 就是每秒钟「拍照」的次数，单位是 Hz（赫兹）。

比如 44100 Hz，就是每秒拍 44100 张「照片」。这个数字也可以写成 44.1 kHz。

来感受一下不同采样率的区别：

采样率 每秒采样次数 听起来怎么样 用在哪儿
8 kHz 8000 次 闷闷的，像老式电话 电话、对讲机
16 kHz 16000 次 人声清晰，但音乐不行 语音识别、微信语音
44.1 kHz 44100 次 高保真，CD 标准 音乐、MP3
48 kHz 48000 次 影视行业标准 电影、视频配音
96 kHz 96000 次 发烧友级别 录音棚、Hi-Fi

你可能会问：为什么 CD 偏偏选了 44.1kHz 这么奇怪的数字？

这背后有个数学原理叫「奈奎斯特采样定理」：要想完整还原一个声音，采样率至少要是这个声音最高频率的 2 倍。

人耳能听到的最高频率大约是 20kHz（其实很多成年人只能听到 16kHz 左右，年纪越大听力越差）。所以采样率至少要 40kHz。再留点余量，就成了 44.1kHz。

简单说：采样率决定了你能录到多高的声音。采样率越高，高频细节越丰富，但文件也越大。

2.3 位深：每张「照片」有多细腻

光拍得快还不够，还得拍得「准」。

想象你测量一杯水的温度。如果你的温度计只能显示整数（36度、37度、38度），那你就没法区分 36.5 度和 36.8 度。但如果温度计能显示到小数点后两位，你就能测得更精确。

位深（Bit Depth） 就是这个「精度」。它决定了每个采样点能记录多少种不同的「高度」。

来看看具体数字：

位深 能区分多少级 听起来怎么样 用在哪儿
8-bit 256 级 有明显的「沙沙」声 早期游戏机、电话
16-bit 65,536 级 足够细腻，CD 标准 音乐、日常使用
24-bit 1677 万级 非常细腻，专业级 录音棚、专业制作

位深影响的是「动态范围」——也就是最大声和最小声之间的差距。

举个例子：16-bit 的动态范围大约是 96dB，这意味着它能同时录下蚊子飞过的声音（很轻）和摇滚乐队的演出（很响），而且两个都不失真。对于日常听音乐来说，这已经绰绰有余了。

24-bit 的动态范围更大（144dB），超过了人耳的极限。这主要是给专业录音师用的，他们需要在后期制作时有更大的调整空间。

简单说：位深决定了声音的细腻程度。位深越高，声音越「丝滑」，但文件也越大。

2.4 声道：有几个「喇叭」在响

这个好理解：

  • 单声道（Mono）：只有 1 个声道，所有声音从同一个方向来。电话、对讲机就是这样。
  • 立体声（Stereo）：2 个声道（左 + 右），能感受到声音的方位。你戴耳机听歌，能听出吉他在左边、鼓在右边，就是这个效果。
  • 5.1 环绕声：6 个声道（前左、前中、前右、后左、后右、低音炮），电影院那种「子弹从身边飞过」的感觉就是这么来的。

声道数越多，空间感越强，但数据量也成倍增加。

2.5 比特率：每秒有多少数据

现在我们可以算一笔账了。

比特率 = 采样率 × 位深 × 声道数

以 CD 音质为例：

44100（采样率）× 16（位深）× 2（立体声）= 1,411,200 bps ≈ 1411 kbps

这意味着什么？

  • 1 秒钟的 CD 音质音乐 ≈ 176 KB
  • 1 分钟 ≈ 10.3 MB
  • 一首 5 分钟的歌 ≈ 51.5 MB
  • 一张 60 分钟的专辑 ≈ 618 MB

看到这个数字你应该明白了：原始音频太 TM 大了！ 如果不压缩，你手机里存不了几首歌，在线听音乐也会卡成 PPT。

这就是为什么需要压缩。

2.6 PCM：数字音频的「原始底片」

最后介绍一个术语：PCM（脉冲编码调制）。

别被这个名字吓到，它其实很简单：PCM 就是按照上面说的方法（采样 + 量化）得到的原始数字音频数据。它就是一堆数字，每个数字代表某一瞬间声波的「高度」。

你可以把 PCM 理解成相机的 RAW 格式：

  • PCM / WAV = RAW，完全没压缩，保留所有细节，但文件巨大
  • MP3 / AAC = JPG，有损压缩，文件小了，但丢失了一些细节
  • FLAC = PNG，无损压缩，文件变小，但能 100% 还原

所有的音频编码格式（MP3、AAC、Opus、FLAC 等等），本质上都是在 PCM 的基础上做压缩。解码的时候再还原成 PCM，才能被 DAC 转换成声音播放出来。

三、音频压缩：给声音「减肥」

3.1 为什么一定要压缩？

上一节算过了：一首 5 分钟的 CD 音质歌曲有 50 多 MB。

这带来几个严重的问题：

  • 存储问题：手机 16GB 存储，只能存 300 首歌。想存整个音乐库？门都没有。
  • 传输问题：1411 kbps 的数据流，很多人的网速都跟不上，在线听歌会一直缓冲。
  • 流量问题：听一首歌就是 50MB 流量，一个月的流量套餐听不了几首。

所以压缩是刚需，不是可选项。

3.2 两种压缩思路

压缩分两种：有损压缩和无损压缩。

我喜欢用「整理衣柜」来类比：

有损压缩 = 扔掉不穿的衣服

衣柜塞满了，怎么办？把那些你再也不会穿的衣服扔掉。空间一下子就腾出来了，但扔掉的衣服就回不来了。

音频的有损压缩也是这个思路：删掉一些「不重要」的数据（比如人耳听不到的部分），文件变小了，但删掉的信息就找不回来了。

代表格式：MP3、AAC、Opus

无损压缩 = 用真空压缩袋

不想扔衣服？那就用真空压缩袋把衣服压扁。空间也能省不少，而且想穿的时候拿出来，衣服还是原来那件，一点没变。

音频的无损压缩就是找数据里的「规律」，用更聪明的方式来存储，不删除任何信息。解压之后能 100% 还原成原始数据。

代表格式：FLAC、ALAC、APE

对比项 有损压缩 无损压缩
压缩比 很高，能到 1:10 ~ 1:20 中等，大约 1:2
能否还原 不能，删掉的信息回不来 能，100% 还原
适合场景 日常听歌、在线音乐、流媒体 音乐收藏、专业编辑
代表格式 MP3、AAC、Opus FLAC、ALAC

3.3 有损压缩的秘密：利用人耳的「漏洞」

有损压缩听起来有点「偷工减料」的意思，但它之所以能把文件压这么小还让你听不出区别，是因为它利用了人耳的生理缺陷。

这门学问叫「心理声学」，专门研究人耳的各种「bug」。

漏洞 1：人耳听不到的频率

人耳只能听到 20Hz 到 20000Hz 之间的声音。低于 20Hz 的叫次声波（大象用这个交流），高于 20000Hz 的叫超声波（蝙蝠用这个导航），人类一概听不见。

所以，原始录音里如果有超出这个范围的声音，全删掉也没人发现。

更有意思的是，随着年龄增长，人能听到的最高频率会逐渐下降。20 岁的年轻人可能能听到 18kHz，到了 40 岁可能就只能听到 15kHz，60 岁可能只剩 12kHz。所以很多「高频细节」对大部分人来说本来就是摆设。

漏洞 2：掩蔽效应

这个更有意思。当一个大声的声音和一个小声的声音同时出现时，你的耳朵会自动「忽略」那个小声的。

比如你在摇滚演唱会现场，鼓手正在疯狂敲击，这时候旁边有人在小声说话，你根本听不见。不是因为他声音小，而是因为鼓声太大，把他的声音「盖住」了。

有损压缩就利用这一点：既然你反正听不见那些被「盖住」的声音，那我干脆就不存它们了。省下来的空间用来更精细地存储那些你能听见的声音。

所以有损压缩不是「随便删」，而是「聪明地删」——只删你听不到的，保留你听得到的。这就是为什么一个 320kbps 的 MP3 文件，大部分人用普通耳机听，根本分不出和无损有什么区别。

3.4 一个重要提醒

有损压缩是单向的、不可逆的。

这意味着：

  • 把 WAV 转成 MP3：信息会丢失
  • 把 MP3 转成 WAV：信息不会回来，只是换了个格式而已，文件变大了，音质没变好
  • 把 MP3 转成 FLAC：同样，只是换格式，不会提升音质

就像你把一张照片从 RAW 导出成 JPG 之后，再把这个 JPG 转成 RAW，模糊的地方不会变清晰。

所以如果你想收藏音乐，最好从源头就下载无损格式（FLAC/ALAC）。以后想要 MP3 版本，随时可以从无损转出来。但如果源头就是 MP3，那就永远只能是 MP3 音质了。

四、音频格式大 PK

市面上的音频格式有一大堆：MP3、AAC、Opus、FLAC、WAV……到底有什么区别？该用哪个？

4.1 格式速览

格式 出生年份 有损/无损 压缩比 一句话点评
MP3 1993 有损 ~1:10 兼容性之王，老当益壮
AAC 1997 有损 ~1:12 MP3 的继任者，Apple 御用
Opus 2012 有损 ~1:20 技术最强，新一代王者
FLAC 2001 无损 ~1:2 无损首选，免费开源
WAV 1991 无压缩 1:1 原始格式，体积最大
ALAC 2004 无损 ~1:2 Apple 的 FLAC，苹果生态专用

4.2 MP3：老大哥

MP3 是 1993 年诞生的，今年（2024 年）已经 31 岁了。

在技术上，它早就被 AAC 和 Opus 超越了。但它有一个无人能敌的优势：兼容性。

任何设备都能播放 MP3：你的手机、电脑、车载音响、老款 MP3 播放器、KTV 点歌机……只要是能放音乐的东西，就一定支持 MP3。

另外，MP3 的专利已经在 2017 年全部过期了，现在完全免费。

什么时候用 MP3？

  • 需要最大兼容性的时候（比如给长辈分享音乐）
  • 不确定对方设备支持什么格式的时候

建议码率：256kbps 或 320kbps

4.3 AAC：流媒体的主力

AAC 是 MP3 的官方继任者，1997 年发布。

同样码率下，AAC 的音质比 MP3 更好。或者说，达到同样音质，AAC 需要的码率更低。

AAC 被 Apple 选中，成为 iTunes 和 Apple Music 的默认格式。YouTube 的音频轨道也是 AAC。可以说，你在网上听到的大部分音乐和视频，背后都是 AAC。

什么时候用 AAC？

  • Apple 生态用户
  • 在线视频的音频轨道
  • 需要比 MP3 更好一点音质的时候

建议码率：192kbps 或 256kbps

4.4 Opus：技术最强的全能选手

Opus 是 2012 年才发布的新一代编码器，技术上遥遥领先。

在几乎所有客观测试中，Opus 都能击败同码率的 MP3 和 AAC。特别是在低码率场景，优势更加明显——32kbps 的 Opus 语音清晰度超过 64kbps 的 MP3。

Opus 有一个很厉害的设计：它内部有两个「引擎」，一个专门针对人声优化（SILK，来自 Skype），一个专门针对音乐优化（CELT）。它会根据音频内容自动切换，语音用 SILK 压得更小，音乐用 CELT 保留更多细节。

另外，Opus 的延迟极低（最低只有 5ms），特别适合实时通话场景。这就是为什么微信、Zoom、Discord 都选择了 Opus。

而且最棒的是：Opus 完全免费开源，没有任何专利费。

什么时候用 Opus？

  • 语音通话、视频会议
  • 低带宽场景（需要省流量）
  • 追求极致效率的时候

建议码率：语音 32-64kbps，音乐 128-256kbps

4.5 FLAC：无损之王

FLAC = Free Lossless Audio Codec（免费无损音频编码）。

顾名思义，两个关键词：免费 + 无损。

FLAC 能把音频文件压缩到原来的 50% 左右，同时保证 100% 无损——解压之后的数据和原始数据完全一模一样，一个字节都不差。

FLAC 是开源的，任何人都可以免费使用，这让它成为了无损音频的事实标准。绝大部分音乐下载网站提供的无损格式都是 FLAC。

什么时候用 FLAC？

  • 收藏音乐（作为「母版」保存）
  • 对音质有追求的发烧友
  • 需要后期编辑的音频素材

4.6 WAV：原始无压缩

WAV 是微软在 1991 年搞出来的格式，本质上就是给 PCM 数据套了一个文件头。

它完全不压缩，所以文件巨大。一首 5 分钟的歌就是 50MB。

但正因为没有任何压缩，它也没有任何「损耗」，是最「纯净」的格式。专业录音棚都用 WAV 来存储和编辑音频，只有在最后发布的时候才会转成其他格式。

什么时候用 WAV？

  • 专业音频制作（录音、混音、母带）
  • 中间过程文件（避免反复压缩带来的累积损失）

4.7 选择建议

场景 推荐格式 码率建议
日常听歌 MP3 或 AAC 256kbps+
语音通话 Opus 32-64kbps
在线视频 AAC 128-192kbps
收藏音乐 FLAC -
专业制作 WAV -

五、VoIP：用网络打电话

5.1 什么是 VoIP？

VoIP = Voice over IP = 通过互联网传输语音。

简单说就是：不走电话线，走网络的语音通话。

你每天都在用 VoIP，只是可能没意识到：

  • 微信语音/视频通话
  • Zoom / 腾讯会议 / 钉钉会议
  • Discord 语音频道
  • WhatsApp 通话
  • FaceTime

这些全都是 VoIP。它们不通过传统的电话网络，而是通过互联网来传输你的声音。

VoIP 的好处是便宜（基本上就是流量费）和灵活（可以跨国通话、多人通话、视频通话），所以现在越来越流行。

5.2 最大的挑战：延迟

打电话和听音乐不一样。听音乐的时候，缓冲 10 秒钟再开始播也无所谓。但打电话的时候，如果你说「喂」，对方 2 秒钟后才听到，那就没法正常对话了。

所以 VoIP 对延迟的要求极高。

延迟 体验
< 150ms 感觉不到延迟，体验流畅
150-300ms 有点延迟，但还能忍
> 300ms 经常不小心打断对方，很难受

那延迟都来自哪儿呢？

采集(10ms) + 编码(20ms) + 网络(50ms) + 解码(20ms) + 播放(20ms) ≈ 120ms

每个环节都会贡献一点延迟。好在现代技术已经可以把整体延迟控制在 100-150ms 左右，基本感觉不到。

5.3 为什么不用 MP3 打电话？

你可能会想：既然 MP3 压缩效果那么好，为什么不用 MP3 来打电话呢？

原因是：MP3 不是为实时通话设计的。

MP3 的设计目标是「音质优先」，它需要攒一大段音频数据，然后一起分析、一起压缩。这个过程本身就需要几十到一百多毫秒。对于听音乐来说无所谓，但对于打电话来说，这个延迟是不可接受的。

所以 VoIP 需要专门的「低延迟」编码器。最常用的就是前面提到的 Opus——它可以做到 5ms 的编码延迟，专门为实时通信设计。

5.4 通话和听歌的本质区别

对比项 听音乐 打电话
最重要的是 音质 延迟
可接受延迟 几秒都行 必须 < 150ms
典型码率 128-320 kbps 16-64 kbps
采样率 44.1 kHz 8-16 kHz
频率范围 20-20000 Hz 300-3400 Hz

注意最后一行：人说话的频率主要集中在 300-3400 Hz，远低于音乐的频率范围。所以电话只需要传输这个范围的声音，就足够听清楚说话了。这也是为什么电话的采样率可以低很多——不需要录那么高的频率。

你有没有发现，老式座机电话的声音听起来有点「闷」？那就是因为它只传输 300-3400 Hz 的声音，把高频都砍掉了。现在的高清语音（VoLTE、微信语音等）会传输更宽的频率范围（50-7000 Hz 甚至更高），所以听起来更清晰、更自然。

六、音频传输协议：不同的「快递方式」

声音变成数据之后，怎么在网络上传输？这就涉及到「传输协议」的选择。

不同的场景需要不同的协议，就像不同的包裹需要选择不同的快递方式。

6.1 先理解 TCP 和 UDP

所有的网络传输协议，底层都是基于 TCP 或 UDP 这两种方式。你可以把它们理解成两种快递服务：

TCP = 顺丰签收

  • 保证送达：丢了会重发
  • 保证顺序：先发的先到
  • 有确认机制：收到了要回复「收到」
  • 缺点：慢，因为要等确认

UDP = 直接扔信箱

  • 不保证送达：丢了就丢了
  • 不保证顺序：可能后发的先到
  • 没有确认：发完就不管了
  • 优点：快，不用等

你可能会想：那肯定用 TCP 啊，谁想丢包啊？

但对于实时语音来说，UDP 反而更合适。

为什么？想象一下：你在和朋友视频聊天，网络突然丢了一个数据包。

  • 如果用 TCP：系统会暂停一切，等丢失的包重传回来，然后再继续。这会导致画面/声音突然卡住一两秒。
  • 如果用 UDP：丢了就丢了，直接播下一个包。可能会有一瞬间的「卡顿」或「破音」，但马上就恢复了，整体流畅性更好。

对于实时通信来说，流畅性比完整性更重要。你宁愿听漏一个字，也不愿意整个画面卡住两秒。

6.2 主流协议介绍

RTP：实时传输协议

RTP 是 VoIP 的基础协议。它建立在 UDP 之上，给每个数据包加上了「时间戳」和「序号」，这样接收方就知道这些包的先后顺序，可以按正确的顺序播放。

延迟：< 50ms 用于：VoIP 电话、视频会议

WebRTC：浏览器内置的实时通信

WebRTC 是个很厉害的东西。它让浏览器原生支持实时音视频通信，不需要安装任何插件。

你用 Google Meet 开会、用 Discord 语音聊天、用 Zoom 网页版，背后都是 WebRTC。

WebRTC 还内置了很多「黑科技」：自动处理 NAT 穿透（让两个内网设备能直接通信）、自动加密、自动回声消除、自动降噪……

延迟：< 500ms 用于：网页视频通话、Discord、Google Meet

RTMP：直播推流协议

RTMP 是 Adobe 开发的，主要用于直播场景的「推流」环节。

当你用 OBS 开直播时，你的电脑会把音视频数据通过 RTMP 协议推送到直播平台的服务器。RTMP 基于 TCP，所以稳定可靠，不会丢帧。

延迟：1-3 秒 用于：直播推流（OBS → B站/斗鱼/虎牙）

HLS：HTTP 直播流

HLS 是 Apple 发明的，思路很聪明：把视频切成一小段一小段（通常 2-10 秒一段），然后用普通的 HTTP 协议来传输这些小片段。

这样做的好处是兼容性极好——任何能上网的设备都支持 HTTP。而且可以充分利用 CDN 缓存，支持海量观众同时观看。

缺点是延迟比较高（10-30 秒），因为需要先缓冲几个片段才能开始播放。

延迟：10-30 秒 用于：直播观看、视频点播（YouTube、Netflix、B站）

6.3 直播的完整链路：推流 vs 拉流

看到这里你可能有点懵：RTMP、HLS 都是直播用的，到底什么区别？

关键是要理解：直播分成两个阶段，用的协议完全不同。

┌─────────────────────────────────────────────────────────────────────┐
│                         直播的完整链路                                │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   【阶段一：推流】              【阶段二：拉流】                         │
│    主播 → 服务器                服务器 → 观众                          │
│                                                                     │
│   ┌──────┐  RTMP   ┌──────────┐  HLS   ┌──────┐                     │
│   │ 主播 │ ──────▶ │ 直播服务器 │ ──────▶ │ 观众A │                    │
│   │ OBS  │         │ 转码+CDN  │ ──────▶ │ 观众B │                   │
│   └──────┘         └──────────┘ ──────▶ │ 观众C │                    │
│      │                  │               └──────┘                    │
│      │                  │                  │                        │
│    1个人上传         服务器转换格式      百万人同时观看                   │
│    延迟要低          分发到全国CDN       兼容性要好                      │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

阶段一：推流（主播 → 服务器）

  • 谁在做：主播
  • 用什么：RTMP
  • 特点：只有 1 个人在上传，追求低延迟，让主播能实时看到自己的画面

阶段二：拉流（服务器 → 观众）

  • 谁在做：观众
  • 用什么：HLS
  • 特点：可能有几百万人同时看，需要 CDN 分发，追求兼容性

为什么要用两套协议？

因为它们解决的问题不一样：

协议 优势 劣势 适合场景
RTMP 延迟低（1-3秒） 浏览器不支持，CDN 不友好 主播推流
HLS 兼容性好，CDN 友好，支持海量观众 延迟高（10-30秒） 观众拉流

所以直播平台的做法是：主播用 RTMP 推上去，服务器转成 HLS 分发给观众。

这也解释了一个现象：你看直播发弹幕，主播要十几秒后才能看到并回复——这个延迟主要就是 HLS 造成的。主播那边其实是实时的，但观众看到的画面已经延迟了。

6.4 WebSocket 能不能用来打电话？

有同学可能会问：WebSocket 不是可以做双向实时通信吗？能不能用来做语音通话？

答案是：可以，但不推荐。

WebSocket 基于 TCP，而 TCP 有个致命问题叫「队头阻塞」：

假设你发了 10 个数据包（1, 2, 3, … 10），其中第 5 个包在网络上丢了。TCP 会怎么做？它会暂停一切，等第 5 个包重传回来，然后才继续处理 6, 7, 8, 9, 10。

这对于语音通话来说是灾难性的——声音会突然卡死，然后快速快进。

而 WebRTC 基于 UDP，第 5 个包丢了？无所谓，扔掉，继续播第 6 个。虽然可能会有一瞬间的「跳帧」，但绝不会卡顿。

所以 WebSocket 更适合做：

  • 文字聊天（实时消息推送）
  • 游戏状态同步
  • IoT 设备控制

而语音/视频通话，还是老老实实用 WebRTC。

七、音频硬件：声音的「物理旅程」

聊了这么多软件层面的东西，最后来看看硬件。声音从你嘴里出来，到对方耳朵里，要经过哪些物理设备？

7.1 完整的硬件链路

声波 → 麦克风 → ADC → 处理器 → DAC → 功放 → 扬声器 → 声波

每个环节都有专门的硬件来负责：

麦克风：声波 → 电信号

麦克风的工作原理是把空气的振动转换成电信号的振动。不同类型的麦克风原理不太一样：

  • 动圈麦克风：里面有个线圈在磁场中振动，产生电流。皮实耐用不怕摔，演唱会、KTV 用这种。
  • 电容麦克风：振膜振动改变电容值，产生电信号。灵敏度高，能捕捉更多细节，录音棚用这种。
  • MEMS 麦克风：微机电系统，把整个麦克风做到比米粒还小。你手机里的麦克风就是这种。

MEMS 麦克风现在特别火，因为它体积小、功耗低、成本低，而且很多型号直接输出数字信号（省掉了外部 ADC）。你手机里可能有 2-4 个 MEMS 麦克风，用来做降噪和定向录音。

ADC：模拟 → 数字

ADC（模数转换器）就是前面说的「给声波拍照」的那个芯片。它按照设定的采样率和位深，把连续的模拟电信号转换成离散的数字信号（PCM）。

ADC 的质量直接决定了录音质量。好的 ADC 信噪比高、失真低，能更准确地「还原」声音。

DAC：数字 → 模拟

DAC（数模转换器）是 ADC 的逆过程：把数字信号还原成模拟电信号。

发烧友口中的「解码器」说的就是 DAC。他们会花几千甚至几万块买一个独立 DAC，就为了更好的音质。

你手机、电脑里都内置了 DAC，但质量参差不齐。外接一个好的 DAC 确实能提升音质，特别是用高端耳机的时候能感受到区别。

功放：放大信号

DAC 输出的电信号很微弱，直接接扬声器根本推不动。功放（功率放大器）的作用就是把信号放大几十到几百倍，让它有足够的「力气」推动扬声器的振膜。

功放分很多种，最常见的是「D 类功放」，效率高（> 90%），发热少，体积小，现在手机、蓝牙音箱里都是这种。

扬声器：电信号 → 声波

扬声器是麦克风的逆过程：把电信号转换成振膜的振动，振膜推动空气，产生声波。

扬声器的大小和声音质量有很大关系。大扬声器能推动更多空气，低频更有力；小扬声器推不动那么多空气，低频就比较弱。这就是为什么手机外放听歌总是缺少「低音」，而一个大音箱就能「嗵嗵」地响。

7.2 I2S：芯片之间的「普通话」

你可能注意到了，上面提到的 ADC、DAC、处理器都是独立的芯片，它们之间怎么传输数字音频呢？

答案是 I2S（Inter-IC Sound）。这是一个专门为数字音频设计的接口标准，只需要 3 根线：

  • 时钟线：告诉大家什么时候发数据
  • 字选择线：区分左声道和右声道
  • 数据线：实际传输的音频数据

几乎所有的音频芯片都支持 I2S，它就像芯片世界的「普通话」，让不同厂家的芯片能无障碍地交流。

7.3 DIY 一个最简单的音频系统

如果你是个动手爱好者，想自己搭一个能录音、能播放的小设备，其实很简单。

以 ESP32 开发板为例，你只需要买这几个模块：

  • INMP441：I2S 数字麦克风模块，约 ¥8-15
  • MAX98357A：I2S 功放模块（自带 DAC），约 ¥10-20
  • 一个小喇叭，约 ¥5-10

总共不到 50 块钱，就能做出一个能录音、能播放、甚至能做语音识别的设备。

这也是为什么现在智能音箱、智能门铃这些产品能做到那么便宜——音频硬件已经非常成熟且廉价了。

总结

好了，这篇文章从声波怎么变成数字，聊到了压缩编码、格式对比、实时通话、传输协议、物理硬件。如果你耐心看到了这里，应该对「声音的数字之旅」有了一个相当完整的认识。

最后再总结一下几个核心要点：

  1. 数字化：声音通过「采样」变成数字。采样率决定能录多高的频率，位深决定音量的精细度。

  2. 压缩：原始音频太大，必须压缩。有损压缩（MP3/AAC/Opus）利用人耳的缺陷，删掉你听不到的部分；无损压缩（FLAC）保留所有信息。

  3. 格式选择：日常听歌用 MP3/AAC，追求效率用 Opus，收藏音乐用 FLAC，专业制作用 WAV。

  4. 实时通话：延迟是关键，必须控制在 150ms 以内。Opus 是目前最强的实时音频编码器。

  5. 传输协议：实时通信用 UDP（WebRTC），因为流畅性比完整性重要；直播推流用 RTMP，观看用 HLS。

  6. 硬件链路：麦克风 → ADC → 处理器 → DAC → 功放 → 扬声器。现代智能设备普遍使用 MEMS 麦克风和 I2S 接口。

希望这篇文章对你有所帮助。下次你打电话或者听音乐的时候，也许会想起这背后有多少技术在默默工作。

本文配套的网页讲解可点击跳转到：数字音频科普指南