企业官网建设流程全解析

你有没有遇到过这种情况：手机或电脑正常外放时声音挺足的，一切到投屏，画面是流畅了，可你想顺便内录取点素材，比如录个网课笔记、给直播做垫片、给后期配音找参考，录出来的声音却明显小了一截，甚至发闷发虚。

这个现象在投屏相关的音频问题里被问过无数次：为什么投屏内录的声音会比正常 speaker 播放的声音小？先说结论——这不是某一台设备的个例，而是投屏音频链路里的“系统性差异”，涉及链路取点、系统音量策略、编码器处理三个层面。这篇文章我会把原因一层层拆开，再给你一套可复现的测量方法和补救方案，读完你基本能自己诊断。

1. 先对齐场景：把“内录声音小”这个结论定义准确

1.1 三种典型的投屏内录场景

讨论任何问题前，得先把场景钉死。同样是“投屏内录”，取音频的位置完全不同，诊断方向也跟着变：

• 场景A：源端内录。手机或电脑一边投屏到电视/显示器，一边用系统录屏功能勾选了“录制系统声音”，录下来的文件里音频偏小。
• 场景B：接收端内录。手机投屏到电脑软件（比如系统的“无线显示器”功能、AirServer、LetsView），电脑这边再把接收到的画面和声音用 OBS 或电脑系统自带的内录通道录制。
• 场景C：转接端内录。无线投屏器或有线 HDMI 分配器负责传信号，另一路用采集卡录制，音频在采集卡里被重新解码/重采样。

这三个场景的信号路径不一样，“声音小”的成因侧重点也不一样。比如场景A可能是源端虚拟音频设备音量没拉满，场景B可能是接收端软件的输入音量太低，场景C则多半是投屏器把音频做了二次编码。所以第一步不是急着找“万能解法”，而是确定你属于哪一种。

1.2 对比是否公平：先回答四个问题

在继续往下读之前，先自己核对四件事，因为很多“声音小”其实是对比方式本身有问题：

• 对比的是同一段音频内容吗？不同内容的峰值和平均响度差很多，用一首安静的钢琴曲和一段电音比音量，结论没意义。
• 对比时源端音量和接收端设备音量是否保持一致？很多人外放时手机音量是80%，投屏后电视音量只有20%，这时拿电视外放的“听感”跟内录文件的“电平”比，当然会得出“小了很多”的结论。
• 你在对比“数字电平”还是“人耳听到的响度”？这两个根本不是一回事，后面会详细讲。
• 内录走的是哪条路径？同一台电脑上，“录制立体声混音”和“录制某个应用的单独音频流”得到的电平都可能差出6dB以上。

这四点里最容易被忽略的是第三点，它也是整篇文章的核心钥匙。

2. 链路取点不同：内录天然就比扬声器音量矮一截

2.1 Speaker 外放时声音经过了什么

一段音频从应用播放到你的耳朵，要经过一串很长的链路：

应用 → 媒体会话 → 系统混音器 → 效果处理（均衡、响度增强等DSP）→ 数字音量调节 → DAC数模转换 → 模拟信号放大 → 功率放大器 → 扬声器振膜 → 空气传播到耳膜。

其中最关键的是最后那几步。数字信号从DAC出来时，电平很低，只有毫伏级别的电压。要让扬声器发出能听见的声音，必须经过功率放大器，功放通常会给信号增加20到30dB的增益，再叠加扬声器自身的灵敏度（每瓦多少分贝声压、腔体设计、喇叭口径），最后你听到的才是那个“震天响”。

换句话说，你耳朵听到的响度，包含了整个功放系统和扬声器声学设计的巨大贡献，这部分完全发生在数字域之后。

2.2 内录的时候取的是哪一段

现在反过头来看投屏内录。无论你在源端还是接收端录制，能录到的都是数字域的PCM信号：

• 源端内录：一般是系统混音器输出的PCM，或者投屏虚拟音频设备的输出，发生在编码器之前。
• 接收端内录：是解码器输出的PCM，同样在DAC和功放之前。

一句话：录音是从水管中间接了个龙头，而外放是龙头末端又加了个增压泵。你录到的是没有经过功率放大的数字信号，而对比的对象却是加了功放、加了扬声器的声音，这个起点就不公平。

打个生活化的比方：你把自来水龙头开一半，用杯子接出来的水量，和把水浇满整个浴缸后再用手捧一捧水，两者根本不是同一个量级。内录文件听起来小，不代表它“坏了”，只是它没有计入后级的物理增益。

2.3 dBFS 和 dB SPL 是两套单位，不能直接换算

这里必须把两个dB说清楚，因为它们经常被混为一谈：

• dBFS：数字域满刻度电平，0dBFS代表采样值到达最大可表示范围。内录软件显示“-18dBFS”，意思是当前采样的振幅比满刻度低了18dB，纯属数字域概念。
• dB SPL：声压级，描述声波作用在耳膜上的压力，90dB SPL已经是嘈杂街道的级别。

一个-12dBFS的数字信号，通过不同的外放设备播放，可能产生70dB SPL，也可能到95dB SPL，中间差出来的部分完全由DAC基准、功放增益、扬声器灵敏度决定。

所以当你拿“外放主观响度”和“内录文件电平”对比时，你其实是在拿两种不同物理量的结果互相比较，结论自然永远是“内录声音小”。搞懂这一点，很多人的焦虑能消掉一半：只要把内录文件按照正常监听标准拉回合适电平，它和外放听感之间的差距本来就是个正常现象。

3. 虚拟设备、音量漂移与绝对音量：投屏特有的“系统音量陷阱”

3.1 投屏会让系统悄悄切换到一个新的音频设备

解决了“单位差异”，接下来看真正的异常来源。最常见的一个坑，发生在投屏动作本身触发的系统设备切换。

以Windows投屏到电视或无线显示器为例，一旦建立Miracast连接，系统会自动把默认播放设备切换到一个虚拟声卡，名字类似“英特尔无线显示音频控制器”或“Realtek HD Audio (Miracast)”。现象就是投屏后扬声器没声了，声音全跑去电视那边。

问题在于：这个虚拟音频设备有自己独立的音量，跟主音量滑竿不是一回事。很多人投屏后发现音量小，去系统托盘把主音量拉满，结果那个虚拟设备的音量其实还停在30%。这时候无论你内录还是推流，录到的都是被这个虚拟设备衰减过的信号，声音自然小。

印象里十次有八次，用户反馈“投屏内录音量小”，最终都是在这个虚拟设备的音量合成器里找到问题的。Windows下排查时，右键托盘音量图标打开“音量合成器”，把所有可见的滑块都拉满，再试试。

Android也类似。部分手机投屏时会把“媒体音量”和“投屏音量”分开调节，设置里的媒体音量看着是满的，实际投放出去的信号却受了单独限制。

3.2 绝对音量协议会把音量控制权交给显示端

第二个容易被忽视的原因是音量控制权转移。蓝牙、AirPlay、Chromecast、部分Miracast实现都支持“绝对音量”协议：源端认为自己输出的音量应当由接收端决定。

于是出现一个荒唐但常见的场景：手机音量100%，电视音量只有20%，源端按照协议“读到”接收端处于低音量状态，就自动把送给编码器的信号整体压低。你在源端录屏内录，录到的就是这个被压低后的信号。

这类问题的特征是：怎么调源端音量都没用，但调低显示端/电视的音量，内录反而会变大（听起来很反直觉）。想彻底解决，Android开发者选项里可以尝试关闭“停用绝对音量”开关，Windows上则多在投屏设备的驱动属性里找相关选项。

3.3 接收端内录时，接收端系统音量同样参与

如果你是在电脑接收端内录，也就是场景B，还要多查一环：接收端自己的主音量。

用WASAPI loopback或“立体声混音”录制时，录到的信号往往包含了系统混音器和输出设备的音量衰减。也就是说，接收端电脑主音量设成30%，即使电视、音箱那边听着够响，内录出来仍然只有很低的电平。

我遇到过用“笔记本声音投屏到显示器”的情况：显示器自带音箱声音不小，可电脑内录出来声音特别弱，最后发现显示器本身有个独立的音量设置，它把HDMI音频输入电平也一起拖低了。记住这个规律：数字音量调到多低，内录就能被衰减多少。

4. 编码器、采样率与音频处理：投屏在幕后偷偷压音量

4.1 编解码前的“安全余量”会让电平损失几个dB

排除系统音量因素后，还剩一类纯协议层面的影响。投屏传输通常要经过音频编码，Miracast常见用AAC-LC、48kHz双声道，AirPlay用AAC-ELD，Google Cast则可能是Opus或AAC。

编码器为了防止解码后出现削波和预回声，普遍会在编码前预留一定余量。有些实现在编码前会做峰值归一化处理，直接把信号压到-3dBFS甚至-6dBFS，再进编码器。这部分损失是刻意的、也是后级难以察觉的，但内录如果取的是编码前信号，就会比原始录音少几个dB。

还有一些情况更隐蔽：有些投屏协议在传输时会做动态范围压缩或响度归一化，目的是让不同内容的响度更一致。压缩器会把大动态素材的峰值压下来，主观听感自然就“小”了。

4.2 采样率转换与声道映射的隐性衰减

投屏两端采样率不一致时，比如源端是44.1kHz音频、接收端按48kHz处理，中间必然经过重采样。正规的重采样器只损失零点几分贝，但如果投屏器或软件实现得粗糙，滤波器在通带边缘的衰减会更明显，高频能量丢失后听感上会“闷”一些，冷冰冰的电平表反而看不出多大差别。

声道映射也值得留意。5.1声道降混成双声道、或者立体声合并为单声道时，为了防止相加后削波，标准的降混算法通常会对每个声道施加约3dB的衰减。如果你内录的是降混后的信号，跟原始立体声比，电平自然又矮了一截。

4.3 回声消除、降噪与ducking有时会误伤信号

视频类投屏场景，比如把网课视频通话投到电视上，系统通常会开启回声消除。回声消除器需要识别并抑制“远端信号”，如果算法把回采的自身播放声音也判断成远端回波，幅度就会被一起砍掉，录制的声音就变得忽大忽小或者整体偏小。

还有“ducking”机制，接收端播放提示音、来电或系统通知时，会暂时压低媒体音量。如果在投屏过程中录到了这种压低段落，你会看到波形中间出现一段明显的“凹陷”。这类问题通常表现为“一下大一下小”，而不是整体平稳地小。

4.4 老式无线投屏器的低码率重编码特别伤

如果你的投屏器是几年的老款，尤其是只支持DLNA的型号，它往往没有真正处理音频的能力，而是把源端音频按很低的码率重编码，比如MP3 64kbps甚至更低的AAC。低码率编码会首先抹掉环境声、混响尾音和高频细节，听感就是“声音变小且发闷”。

这种情况和单纯的电平小不同，单纯电平小只要拉增益就能恢复，而低码率损失的信息是补不回来的。遇到类似“无线投屏器不支持怎么办”的问题，我的建议通常很直接：别折腾软件了，换成HDMI采集卡做有线内录，或者换支持音频直通的投屏器。

5. 实证测量：用Audacity把“小了多少dB”测出来

5.1 做一个能复现的对照实验

你不需要靠耳朵猜，十分钟就能量化。工具就用免费开源的Audacity，配合系统内录通道（Windows下WASAPI loopback，macOS下用BlackHole这类虚拟声卡）。

操作步骤：

1. 在Audacity里生成测试信号：菜单“生成 → 生成音调”，频率选1000Hz，振幅设0.1（即-20dBFS，留足余量避免失真），时长10秒。
2. 先在本地正常播放这个测试音，同时用WASAPI loopback录制一段，命名为“本地参考”。
3. 开启投屏，让声音走投屏链路（无论走源端内录还是接收端内录），录制同样10秒的测试音，命名为“投屏内录”。
4. 导入两段录音，分别框选后点击“效果 → 音量与压缩 → 振幅统计”，记录各自的RMS电平和峰值电平。
5. 两者RMS电平相减，就得到实际衰减了多少dB。

举例：本地参考是-20.1dBFS RMS，投屏内录是-27.5dBFS RMS，差值就是7.4dB。这个数字就是你要解决的问题量级。

5.2 按差值大小判断是正常还是异常

不同差值对应的成因不同，我通常按下面的标准判断：

还要注意：主观听感上，-6dB的差异听上去只是“明显小了一截”，-10dB才会让人觉得“轻了一半”。所以如果你的实测差值在3dB左右，很可能正常人根本听不出问题，不用为此焦虑。

5.3 波形和频谱能告诉你更多

量化数字之外，我还习惯看一眼波形和频谱图，因为它们的表现能帮你区分问题类型：

• 波形整体变小、但轮廓不变，细节依然清晰——纯电平问题，后期拉增益即可。
• 波形变小且高频变暗，在频谱图上看高频滚降明显——编码码率太低或采样率设置有问题，需要考虑换传输方式。
• 波形中出现突然的凹陷段——ducking或通知音干扰。
• 波形出现顶部平头——削波失真，这回不是“声音小”而是“声音破”了，要反方向降低增益。

6. 从链路每一端分别找补：一套直接的补救方案

6.1 源端调整：把能看到的音量全部拉满

先说源端内录（场景A）的处理顺序：

• 打开系统的音量合成器，把包括投屏虚拟设备在内的所有滑块全部拉满。
• 媒体音量与投屏音量分别设置的情况下，确保两者都在最高。
• Android开发者选项里尝试关闭“停用绝对音量”后重测。
• 录屏软件本身的“系统声音”采集如果带音量滑条，也一并拉满。

这套操作做完再测一次，大概率能找回3到6dB。如果还差，再进行下一步。

6.2 接收端内录：先把输入电平和主音量分开处理

处理接收端内录（场景B）时，要分清两件事：接收端设备的物理外放音量和录制输入电平。

• 把接收端电脑/软件的主音量拉到100%，实际听感大小交给音箱或电视自己的音量旋钮控制。
• 检查系统“录制设备 → 立体声混音 → 属性 → 级别”，确认录音输入电平在100%。
• OBS里如果单独添加了投屏窗口的音频源，在混音器里把该源音量适当提高，同时加一个限幅器（Limiter）防止峰值爆音。

这里有个小技巧：先用100%音量录一遍，再用50%音量录一遍，对比两段录音的电平差。如果差值和音量调节幅度一致，说明问题就是出在这一层音量控制上，直接固定到100%即可。

6.3 后期补偿：响度标准化比盲目放大更靠谱

如果现场已经录完，没法重录，再靠后期补。两种思路：

• 简单场景：Audacity里框选全部音频，用“效果 → 音量与压缩 → 放大”，目标峰值设为-1dB。差值6dB左右就填6dB，差值10dB就填10dB，填完检查有没有削波。
• 规范场景：用“响度标准化”按LUFS处理。比如视频平台常以-14 LUFS为目标，播客常用-16 LUFS。响度标准化是依据人耳响度感知来调整的，比单纯按峰值放大更符合听觉习惯。

处理完别忘了通篇听一遍，重点听有没有句子被压坏、有没有爆音。如果增益后出现明显的失真，说明原始信号在数字域就没有余量了，这时要考虑重新走有线采集，而不是继续加增益。

7. 实操心得与避坑提醒：这些年踩过的坑

7.1 几句话讲完我的真实经历

第一个印象深刻的坑是在Windows 10上做投屏内录。当时投屏正常，扬声器没声了，我在托盘把主音量拉到100%，内录还是小，后来才发现“音量合成器”里多了一个WiDi虚拟音频设备，它自己的音量只有28%。把它拉满后，问题秒解。

第二个坑是用手机投屏到电脑软件时，接收端软件（某个第三方投屏接收工具）自带一个“扬声器音量”滑块，默认在50%。我一度以为是手机编码的问题，排查了半天，最后发现只要把这个滑块拉到100%，OBS录出来的电平立刻正常。这个例子特别能说明问题：出现“声音小”时，先别怀疑编码器，先怀疑音量控制。

第三个坑是给一台很老的无线投屏器做内录，那个投屏器只支持DLNA，音频码率低得离谱，录出来的声音又小又闷。这种属于硬件瓶颈，软件调什么都白搭，后来换了一条“笔记本 → HDMI采集卡”的路径，声音立刻干净了。

7.2 快速自查清单

最后送上一份从症状出发的自查表，可以直接抄走：

7.3 什么情况下可以“不用管它”

不是所有内录音量小都值得修复。如果你录这段音频只是为了给后期配音对齐口型、做剪辑参考、记录网课笔记，那么-18dBFS甚至更低都完全够用，后期一声“放大”就解决了。

真正需要较真的是交付给用户的成品，或者音质直接影响内容的场景。那种情况下，我的原则是：宁可选择有线链路（HDMI采集卡、外置声卡），也不要依赖无线投屏内录。无线方案能解决“能用”，但解决不了“稳定”。

根据我个人经验，最省事的做法是每次开工前花30秒做个声音检查：源端音量拉满，接收端所有能看到的音量拉满，用上面说的1000Hz测试音录10秒，看一眼电平表是否落在-12dBFS到-6dBFS之间。只要这一步过了，后面基本不会再被“投屏内录音量小”折磨。