写这个 Building a Simple Engine 系列的时候音频子系统是我唯一拖到最后才动工的部分。引擎里渲染、输入、资源管理都有了雏形之后我才发现一个只会画画面却发不出任何声音的引擎在调试时会让人多难受你想用一声提示音告诉自己某个事件到底有没有触发只能低头看日志效率低得让人抓狂。这次总算把音频基础部分补上了趁热把思路整理出来。这篇聊的范围就是“简单引擎的音频基础”里最必要的那一坨音频输出设备怎么抽象、WAV怎么加载、混音和空间化怎么落地、并发播放怎么限制以及我实测中踩过的爆音和断流问题。目标是让引擎能稳定播放音效和背景音乐能控制音量能有基本的左右声像和距离衰减。我不会碰HRTF、卷积混响这类高阶DSP那是后面慢慢加的东西。1. 声音进耳朵前必经的链路采样、缓冲、设备回调1.1 采样率、位深和声道先把音频的“分辨率”定下来接触音频子系统绕不开三个数字采样率、位深、声道数。采样率决定了每秒记录多少个瞬间的声波振幅位深决定了每个瞬间的振幅能细分到什么程度声道数决定了你可以让声音从几个方向出来。你可以把采样率理解成摄像头的分辨率把位深理解成每个像素的颜色位深后者决定动态范围和信噪比。常见的组合是 44100 Hz、16-bit、立体声也就是 CD 音质“游戏常用 48000 Hz”的原因主要是和视频帧率对齐以及某些硬件以 48kHz 为原生频率。我第一版直接选了 48000 Hz、16-bit所有素材都在导入时转成这个格式。这样引擎内部只有一个采样率避免后面混音时还要到处做重采样。位深这里尤其要注意引擎内部混音时我统一使用 32 位浮点也就是 float 样本取值范围在 [-1.0, 1.0]。为什么不用 16-bit 整数直接在内部算因为混音要加法两段波叠加后瞬时值很容易超过 int16 的范围表现为削波失真而且后期做淡入淡出、距离衰减、多普勒浮点中间过程的精度损失远小于整数。float 只是工作区最后交付给声卡前再量化回 16-bit PCM。1.2 设备回调不是“推”而是“拉”缓冲区大小就是延迟音频输出和很多人想的不一样引擎不是主动“推”数据给声卡而是声卡到时间了会“拉”数据。设备驱动按固定周期来找你要一段样本这段样本称为一个缓冲块。声卡求数据的方式可以理解成站在窗口前喊给我下一批午饭。你如果没提前把菜盛好就只能给他空碗结果就是咔哒声和断断续续。缓冲区大小直接决定延迟延迟 缓冲区大小 / 采样率。拿 48000 Hz 来算一个 512 样本的缓冲块是 10.67 毫秒256 样本是 5.33 毫秒。这个延迟对射击音效、脚步声这种需要精确对帧的音效很关键背景音乐延迟几十毫秒基本听不出来。我第一版设置了 512 样本稳定优先。等把线程模型做稳了再往 256 压。这里要记住一个出发点实时游戏音效的延迟主要来自缓冲块大小而不是混音算法的复杂度。所以音频线程的每一帧都要在极短时间内算完否则下一次回调就要等一等就是爆音。1.3 引擎内部统一用 float32最后一步才转 PCM数据流整体是这样走的磁盘上的音频文件 → 解码为 float32 样本 → 按需重采样成引擎统一的采样率 → 混音核心把所有音源同步相加 → 写入平台设备缓冲区 → 设备回调把缓冲区提交给声卡。这条链路我建议在最开始就画清楚。因为很多引擎是在中途决定“内部统一用 float32”的结果会发现所有加载代码都得改一遍空间化也没处安放。如果一开始就把 float32 定为内部标准加载器只需要在导入时转一次后面所有 DSP 和混音都在同一套数据上做思路会非常干净。实际动手时我先做了一个最小工具把 WAV 读进来并转成 float32 数组再用一个模拟回调把数组打印成波形文件。这一步没接任何平台音频 API但把链路的两头固定住了后面接设备只是把最终的 float 数组转成平台格式的问题。2. 音频模块划分从资源到播放实例再到输出设备2.1 五个核心对象一个都不能少我第一版音频子系统的类不多但每个职责都很清晰AudioDevice最底层封装平台设备负责打开设备、启动回调、把混音后的样本数组交给驱动。Sound代表一份已经加载进内存的音频资源核心是一个 float32 样本数组外加采样率、声道数、时长这些元数据。它本身不可播放。Voice有些引擎叫 SoundInstance代表一次正在进行的播放会话包含当前播放位置、音量、声像、播放速度、循环标记、是否已暂停。同一个 Sound 可以被好几个 Voice 同时引用比如两个爆炸声同时响起。AudioManager引擎层的主要入口维护 Voice 列表负责混音、空间化、资源缓存和释放。Listener表示听者所在的位置和朝向空间化的所有计算都以它作为参考点。如果你熟悉渲染系统这套类比很好理解。Sound 就像是顶点数据和贴图Voice 就像是 draw call 的实例状态同一个 Sound 被多个 Voice 引用就好比同一个网格在场景中出现在多个位置。2.2 挂在引擎生命周期里的正确顺序引擎启动时音频子系统要跟着主循环走一遍固定顺序创建 AudioManager加载初始资源打开默认输出设备启动回调线程注册 Listener 为默认位置通常跟随相机每帧主循环里更新 Listener 和 Voice 的参数输出回调在后台线程里只做一件事混音并写进缓冲。关键点是第 4、5 步不要搞混。我在最早版本犯过将“每帧更新 Voice”和“混音写缓冲”放在同一个函数里的错误导致主线程只要卡一帧音频就跟着断。后来我强制把两块逻辑拆开主线程只负责“告诉音频系统你想做什么”后台音频线程只负责“把当前需要输出的一小段算出来”。关闭顺序比初始化更容易被忽略先停回调再销毁 Voice再卸载资源最后关设备。如果主线程已经被卡到无法响应至少保证音频线程不会在设备关闭后还在写数据。2.3 平台抽象做多厚够用就好桌面平台和移动平台的音频接口差别很大。如果游戏逻辑里到处都是平台 API 类型后面移植会非常痛苦。抽象层的核心原则就两个引擎业务代码只面对 AudioDevice 接口不出现任何平台类型时间驱动方式也要隔离比如回调函数签名不一致就用统一的音频线程加环形缓冲做适配层。但抽象不要做过头。我见过有人把音量曲线管理、淡入淡出调度全部塞进设备层最后设备层变成一个自成一体的“声音管理器”引擎上层反而变成空壳。正确的粗细程度是设备层只负责“有没有声音出来”引擎层负责“出来的是什么声音”。3. 混音、空间化和播放配额耳朵里的一切其实都是累加3.1 混音就是求和削波才是第一个敌人混音的原理非常简单把所有 Voice 在同一个时间点的采样值相加得到这个时间点设备的输出值。每个 Voice 先乘自己的音量总线再乘总音量。如果好几个声音叠在一起瞬时值超过范围就会削波。削波有两种常见对策。第一种是硬削波超出范围就直接截断简单有效但声音大起来会有点硬。第二种是给整个输出乘一个固定增益比如 0.8给后续空间化留出余量。我实际用下来的经验是每个音源在编辑器里就把基础音量压住UI 反馈 0.5普通音效 0.6背景音乐 0.3混音总线再乘 0.8这样大多数情况下不会炸。你听的不是某个单独音源响不响而是整体输出有没有超过 1.0。混音的时候还要注意顺序。我先把活跃 Voice 的 float 样本按时间对齐到同一个数组然后循环所有出手的 Voice 加到临时 buffer 上。是不是先做距离衰减、再做声像、最后混音这里顺序要一致否则同一个声音在不同帧听起来会有突兀的感觉。3.2 3D 空间化从距离衰减和声像开始空间化就是根据 Listener 和 Voice 的空间关系动态调整音量与左右声道分配。第一版不需要做 HRTF也不需要精确的声场渲染只需要两个东西距离衰减和声像。距离衰减我用最简单直观的线性衰减音量 clamp(1 - (距离 - 最小距离) / (最大距离 - 最小距离), 0, 1)。最小距离之内不衰减超过最大距离就听不见。你也可以用倒数衰减 1 / (1 a * 距离)衰减更自然但公式里那个 a 要调。我建议第一版用线性但把距离衰减函数抽成一个可替换的接口后面换曲线查表很方便。声像就是把一个单声道音源分配到左右两个声道。简单做法是先算出 Listener 朝向与 Listener 到 Voice 方向向量之间的夹角 θ然后 left cos(θ/2)right sin(θ/2)。这样 Voice 在正前方时左右各 0.5在右侧时右声道更响。素材最好用单声道立体声素材做声像容易相位出错。多普勒效应第一版我建议先不做。虽然听起来很酷但它涉及动态改变播放速率而且和 Voice 的步进逻辑耦合很深。先把距离衰减和声像跑稳定后面再单独开一个版本加多普勒。3.3 Voice 配额并发播放数量必须有限如果你不做任何限制玩家在场景里扔十个手雷、踩十个音效Voice 数量就会爆炸。所以我给 AudioManager 设了一个最大并发数默认 32。当新 Voice 申请时超过配额就按策略踢掉一个。踢谁我第一版用的策略是“最旧优先”结合一条惩罚规则被踢的先看音量音量太低的更可能留下来低音量的新 Voice 也可能直接被拒绝。其实更合理的是“类别优先”语音和重要音效永远保留普通音效按最旧踢。但那样要么引入优先级要么做类别预留我第一版没搞直接 FIFO够用。4. 声音资源的最小闭环从 WAV 文件到内存中的样本4.1 WAV 头解析绕不开的 RIFF 和两个 chunkWAV 是我建议的第一种支持格式因为结构简单、无压缩、解析容易。它整体是一个 RIFF 文件前 12 个字节是头然后是一堆 chunk。核心只要看两个 chunkfmt 和 data。我用一个表把 WAV 主要字段列出来方便对照偏移字段大小说明0RIFF4固定标志4文件总长度4剩余文件大小8WAVE4固定格式类型12fmt 4格式块起始16fmt 块长度4通常为 1620音频格式21 表示 PCM22声道数21 单声道2 立体声24采样率4如 4410028字节率4采样率 × 声道数 × 位深 / 832块对齐2声道数 × 位深 / 834位深2常见 16一个简单的解析流程先读 RIFF 头验证标志然后循环读取 chunk找到 fmt 就把参数记录下来找到 data 就记录数据首地址和长度。数据块的位置可能不在文件末尾后面可能还有别的 chunk所以循环扫描 chunk 比直接按固定偏移读到 data 更可靠。4.2 字节序、内存占用和流式预留WAV 常见的样本格式是 16-bit signed PCM小端存储。如果字节序搞错播放出来就是一片噪声。解析完 data 块后我会先把每个采样的小端字节转成 int16再除以 32767 变成 float32。这段代码很无趣但值得单独写一个函数并用已知素材测一次后面所有版本都靠这个基础。内存占用目测一下很快就知道为什么要考虑流式加载44.1kHz、16-bit、单声道的一秒大约是 88KB一段两分钟的立体声背景音乐大约要 21MB。游戏音效普遍短全量驻留内存没问题但长音乐如果也全量塞进内存很快就会打爆资源预算。第一版我没有做流式解码只在 Sound 结构里留了一个 bStreaming 标志和分块预留位置。因为流式要涉及后台解码线程和环形缓冲属于另一个复杂话题。建议你也这样先让静态 WAV 播放跑通给流式留出扩展位不要在初期就让加载器分成两条分支。4.3 上一套带引用计数的资源缓存音频资源和纹理资源一样需要防止重复加载。引擎的资源系统通常已经有一张全局表音频资源直接塞进同一个表但有一个额外要求引用计数不能只看“有没有人持有 Sound 句柄”还要看“有没有 Voice 正在播放它”。如果一段音效还在播放资源就被换掉音频线程下次读取就可能崩溃。所以我在 Sound 上维护了一个 voiceRefCount每次创建 Voice 时 1Voice 销毁时 -1。卸载模块检查这个计数只要不是 0 就不允许释放资源。这个保护机制不是给正常流程准备的是给切场景、热加载这些边界情况兜底的。5. 实测最容易翻车的地方爆音、断流、循环咔哒5.1 爆音的两种真凶缓冲欠载和直流偏移爆音是最常见的音频问题但原因往往完全不同。第一种是缓冲欠载混音线程来不及在回调前填满缓冲设备读到一半没有数据只能在缺口处补零补零的瞬间就出现 click。排查时我在回调里加了一个统计变量记录每次回调实际写入的样本数。如果连续几次都小于请求长度基本可以断定是主线程拖累了音频线程。第二种爆音来自素材本身。有些 WAV 的第一帧不是从 0 开始的带着明显直流偏移直接播放会让设备在第一帧瞬间跳变听起来就是“啪”的一声。解决方式是在每个 Voice 的起始位置预留几毫秒淡入比如前 10 毫秒线性从 0 升到目标音量。这会影响音效的“攻击感”所以淡入越短越好只要能把直流跳变抹平即可。5.2 音频回调线程里的线程地狱音频回调要实时性。平台设备给回调的时间窗口非常短你必须在几毫秒内返回否则下一次回调的调度会受到干扰。所以回调里禁止做三件事加锁、分配内存、做文件 IO。我一开始在回调里用了 Mutex 保护 Voice 列表结果音乐一变多就开始断续。后来改成“主线程只更新一个原子变量和简单数组回调读取时若发现版本号变化则跳过一帧更新”本质就是 producer-consumer 的思想主线程写、音频线程读中间不做同步锁只靠原子变量保证可见性。Voice 的增删则利用主线程的空闲帧到一个 deferred list 里做这样回调永远不会去管理内存。这里还要警惕一个隐藏问题回调里也不要轻易调用平台日志函数。某些平台上日志实现会内部加锁或做格式化一样会造成卡顿。调试时可以先用一个宽松的无锁日志环最后看时间戳。5.3 循环点与素材边界的咔哒声背景音乐做循环播放时循环点如果恰好落在一个波形幅度很高的位置重新从头播放的瞬间就会跳变听感就是咔哒。这个问题的本质是循环点两端波形不连续。第一版我给循环 Voice 加了很简单的处理在循环即将发生的那一帧做一个 1-2 毫秒的交叉淡出把旧位置的音量降下来再把新位置音量升上去。交叉很短暂大多数音乐听不出副作用。更讲究的引擎会在导入素材时自动搜索离循环点最近的过零点并调整循环位置但那是编辑器工具层面的优化不是第一版该做的事。5.4 声音发闷、噪声大逐项确认数值如果你听完发现发闷或者噪声大先别急着换播放算法按顺序排查播放出来是噪声而不是音效十有八九是字节序或位深解析出错打印第一个 data 块的几个样本对照十六进制验证。明显削波看混音到的最终值有没有大量超过 ±1.0降低每个音源的基础音量。只有一边响或左右不对确认声道数是否解析正确检查 data 块是否把左右声道交错存储的样本拆错了。听起来很闷或高频缺失看看是不是素材本身采样率太低或者你哪步把样本错误地压缩了。这些我都踩过几乎都和算法无关都是基础解析、类型转换的问题。6. 不用玄学调音用波形和数据验证音频子系统6.1 先用 Python 造一批可控的测试音频耳朵的主观判断容易掩盖问题尤其是刚开始做的时候。我的做法是先用一小段脚本生成几组标准测试 WAV1kHz 正弦波、440Hz 正弦波、扫频、静音。比如生成一段 1kHz 正弦波import math import struct import wave sample_rate 44100 duration 2.0 freq 1000.0 n_samples int(sample_rate * duration) with wave.open(tone_1k.wav, wb) as w: w.setnchannels(1) w.setsampwidth(2) w.setframerate(sample_rate) for i in range(n_samples): t i / sample_rate val int(32767 * 0.5 * math.sin(2 * math.pi * freq * t)) w.writeframes(struct.pack(h, val))1kHz 正弦波可以直接验证播放速度和音高是否对如果播放时长不是两秒或者听感音高明显不对那采样率处理就有问题。扫频音频可以快速检查整个频带有没有明显断裂。静音音频则用来排查噪声底如果静音文件播放出来有杂音说明样本转换或混音链路上引入了直流偏置。6.2 最小自动化测试清单我把第一版音频子系统的自动化测试收敛成了下面这份清单每项都可以在无人工听音的情况下跑加载 WAV 后采样数、采样率、声道数与源文件一致。创建 Voice 后状态能从“等待”变成“播放”播放位置按每帧样本数前进。混音函数输入两个同频率正弦波数组输出振幅等于两者之和的近似值。移动 Listener 与 Voice 的相对位置左右声道的增量和距离衰减曲线符合预期。资源释放前存在活跃 Voice 时引用计数阻止卸载。每次改完混音和空间化代码我都先跑自动化测试再亲自带上耳机做主观试听。自动化测试证明没跑偏主观试听决定好不好听两者都不能缺。这套基础做完之后我心里对引擎整体结构终于踏实了。如果你也在做自己的简单引擎我的建议是先让音频“能响、不断、能控制音量”再去追求空间化和高级效果稳定性永远比特效优先级高。先把这个最小闭环跑通后面加的 HRTF 之类才找得着地方挂。 
长河君 · 2026/10/17 17:43:40 · 阅读 1.2k 游戏引擎音频子系统入门：采样、混音、空间化与稳定播放实践
写这个 Building a Simple Engine 系列的时候音频子系统是我唯一拖到最后才动工的部分。引擎里渲染、输入、资源管理都有了雏形之后我才发现一个只会画画面却发不出任何声音的引擎在调试时会让人多难受你想用一声提示音告诉自己某个事件到底有没有触发只能低头看日志效率低得让人抓狂。这次总算把音频基础部分补上了趁热把思路整理出来。这篇聊的范围就是“简单引擎的音频基础”里最必要的那一坨音频输出设备怎么抽象、WAV怎么加载、混音和空间化怎么落地、并发播放怎么限制以及我实测中踩过的爆音和断流问题。目标是让引擎能稳定播放音效和背景音乐能控制音量能有基本的左右声像和距离衰减。我不会碰HRTF、卷积混响这类高阶DSP那是后面慢慢加的东西。1. 声音进耳朵前必经的链路采样、缓冲、设备回调1.1 采样率、位深和声道先把音频的“分辨率”定下来接触音频子系统绕不开三个数字采样率、位深、声道数。采样率决定了每秒记录多少个瞬间的声波振幅位深决定了每个瞬间的振幅能细分到什么程度声道数决定了你可以让声音从几个方向出来。你可以把采样率理解成摄像头的分辨率把位深理解成每个像素的颜色位深后者决定动态范围和信噪比。常见的组合是 44100 Hz、16-bit、立体声也就是 CD 音质“游戏常用 48000 Hz”的原因主要是和视频帧率对齐以及某些硬件以 48kHz 为原生频率。我第一版直接选了 48000 Hz、16-bit所有素材都在导入时转成这个格式。这样引擎内部只有一个采样率避免后面混音时还要到处做重采样。位深这里尤其要注意引擎内部混音时我统一使用 32 位浮点也就是 float 样本取值范围在 [-1.0, 1.0]。为什么不用 16-bit 整数直接在内部算因为混音要加法两段波叠加后瞬时值很容易超过 int16 的范围表现为削波失真而且后期做淡入淡出、距离衰减、多普勒浮点中间过程的精度损失远小于整数。float 只是工作区最后交付给声卡前再量化回 16-bit PCM。1.2 设备回调不是“推”而是“拉”缓冲区大小就是延迟音频输出和很多人想的不一样引擎不是主动“推”数据给声卡而是声卡到时间了会“拉”数据。设备驱动按固定周期来找你要一段样本这段样本称为一个缓冲块。声卡求数据的方式可以理解成站在窗口前喊给我下一批午饭。你如果没提前把菜盛好就只能给他空碗结果就是咔哒声和断断续续。缓冲区大小直接决定延迟延迟 缓冲区大小 / 采样率。拿 48000 Hz 来算一个 512 样本的缓冲块是 10.67 毫秒256 样本是 5.33 毫秒。这个延迟对射击音效、脚步声这种需要精确对帧的音效很关键背景音乐延迟几十毫秒基本听不出来。我第一版设置了 512 样本稳定优先。等把线程模型做稳了再往 256 压。这里要记住一个出发点实时游戏音效的延迟主要来自缓冲块大小而不是混音算法的复杂度。所以音频线程的每一帧都要在极短时间内算完否则下一次回调就要等一等就是爆音。1.3 引擎内部统一用 float32最后一步才转 PCM数据流整体是这样走的磁盘上的音频文件 → 解码为 float32 样本 → 按需重采样成引擎统一的采样率 → 混音核心把所有音源同步相加 → 写入平台设备缓冲区 → 设备回调把缓冲区提交给声卡。这条链路我建议在最开始就画清楚。因为很多引擎是在中途决定“内部统一用 float32”的结果会发现所有加载代码都得改一遍空间化也没处安放。如果一开始就把 float32 定为内部标准加载器只需要在导入时转一次后面所有 DSP 和混音都在同一套数据上做思路会非常干净。实际动手时我先做了一个最小工具把 WAV 读进来并转成 float32 数组再用一个模拟回调把数组打印成波形文件。这一步没接任何平台音频 API但把链路的两头固定住了后面接设备只是把最终的 float 数组转成平台格式的问题。2. 音频模块划分从资源到播放实例再到输出设备2.1 五个核心对象一个都不能少我第一版音频子系统的类不多但每个职责都很清晰AudioDevice最底层封装平台设备负责打开设备、启动回调、把混音后的样本数组交给驱动。Sound代表一份已经加载进内存的音频资源核心是一个 float32 样本数组外加采样率、声道数、时长这些元数据。它本身不可播放。Voice有些引擎叫 SoundInstance代表一次正在进行的播放会话包含当前播放位置、音量、声像、播放速度、循环标记、是否已暂停。同一个 Sound 可以被好几个 Voice 同时引用比如两个爆炸声同时响起。AudioManager引擎层的主要入口维护 Voice 列表负责混音、空间化、资源缓存和释放。Listener表示听者所在的位置和朝向空间化的所有计算都以它作为参考点。如果你熟悉渲染系统这套类比很好理解。Sound 就像是顶点数据和贴图Voice 就像是 draw call 的实例状态同一个 Sound 被多个 Voice 引用就好比同一个网格在场景中出现在多个位置。2.2 挂在引擎生命周期里的正确顺序引擎启动时音频子系统要跟着主循环走一遍固定顺序创建 AudioManager加载初始资源打开默认输出设备启动回调线程注册 Listener 为默认位置通常跟随相机每帧主循环里更新 Listener 和 Voice 的参数输出回调在后台线程里只做一件事混音并写进缓冲。关键点是第 4、5 步不要搞混。我在最早版本犯过将“每帧更新 Voice”和“混音写缓冲”放在同一个函数里的错误导致主线程只要卡一帧音频就跟着断。后来我强制把两块逻辑拆开主线程只负责“告诉音频系统你想做什么”后台音频线程只负责“把当前需要输出的一小段算出来”。关闭顺序比初始化更容易被忽略先停回调再销毁 Voice再卸载资源最后关设备。如果主线程已经被卡到无法响应至少保证音频线程不会在设备关闭后还在写数据。2.3 平台抽象做多厚够用就好桌面平台和移动平台的音频接口差别很大。如果游戏逻辑里到处都是平台 API 类型后面移植会非常痛苦。抽象层的核心原则就两个引擎业务代码只面对 AudioDevice 接口不出现任何平台类型时间驱动方式也要隔离比如回调函数签名不一致就用统一的音频线程加环形缓冲做适配层。但抽象不要做过头。我见过有人把音量曲线管理、淡入淡出调度全部塞进设备层最后设备层变成一个自成一体的“声音管理器”引擎上层反而变成空壳。正确的粗细程度是设备层只负责“有没有声音出来”引擎层负责“出来的是什么声音”。3. 混音、空间化和播放配额耳朵里的一切其实都是累加3.1 混音就是求和削波才是第一个敌人混音的原理非常简单把所有 Voice 在同一个时间点的采样值相加得到这个时间点设备的输出值。每个 Voice 先乘自己的音量总线再乘总音量。如果好几个声音叠在一起瞬时值超过范围就会削波。削波有两种常见对策。第一种是硬削波超出范围就直接截断简单有效但声音大起来会有点硬。第二种是给整个输出乘一个固定增益比如 0.8给后续空间化留出余量。我实际用下来的经验是每个音源在编辑器里就把基础音量压住UI 反馈 0.5普通音效 0.6背景音乐 0.3混音总线再乘 0.8这样大多数情况下不会炸。你听的不是某个单独音源响不响而是整体输出有没有超过 1.0。混音的时候还要注意顺序。我先把活跃 Voice 的 float 样本按时间对齐到同一个数组然后循环所有出手的 Voice 加到临时 buffer 上。是不是先做距离衰减、再做声像、最后混音这里顺序要一致否则同一个声音在不同帧听起来会有突兀的感觉。3.2 3D 空间化从距离衰减和声像开始空间化就是根据 Listener 和 Voice 的空间关系动态调整音量与左右声道分配。第一版不需要做 HRTF也不需要精确的声场渲染只需要两个东西距离衰减和声像。距离衰减我用最简单直观的线性衰减音量 clamp(1 - (距离 - 最小距离) / (最大距离 - 最小距离), 0, 1)。最小距离之内不衰减超过最大距离就听不见。你也可以用倒数衰减 1 / (1 a * 距离)衰减更自然但公式里那个 a 要调。我建议第一版用线性但把距离衰减函数抽成一个可替换的接口后面换曲线查表很方便。声像就是把一个单声道音源分配到左右两个声道。简单做法是先算出 Listener 朝向与 Listener 到 Voice 方向向量之间的夹角 θ然后 left cos(θ/2)right sin(θ/2)。这样 Voice 在正前方时左右各 0.5在右侧时右声道更响。素材最好用单声道立体声素材做声像容易相位出错。多普勒效应第一版我建议先不做。虽然听起来很酷但它涉及动态改变播放速率而且和 Voice 的步进逻辑耦合很深。先把距离衰减和声像跑稳定后面再单独开一个版本加多普勒。3.3 Voice 配额并发播放数量必须有限如果你不做任何限制玩家在场景里扔十个手雷、踩十个音效Voice 数量就会爆炸。所以我给 AudioManager 设了一个最大并发数默认 32。当新 Voice 申请时超过配额就按策略踢掉一个。踢谁我第一版用的策略是“最旧优先”结合一条惩罚规则被踢的先看音量音量太低的更可能留下来低音量的新 Voice 也可能直接被拒绝。其实更合理的是“类别优先”语音和重要音效永远保留普通音效按最旧踢。但那样要么引入优先级要么做类别预留我第一版没搞直接 FIFO够用。4. 声音资源的最小闭环从 WAV 文件到内存中的样本4.1 WAV 头解析绕不开的 RIFF 和两个 chunkWAV 是我建议的第一种支持格式因为结构简单、无压缩、解析容易。它整体是一个 RIFF 文件前 12 个字节是头然后是一堆 chunk。核心只要看两个 chunkfmt 和 data。我用一个表把 WAV 主要字段列出来方便对照偏移字段大小说明0RIFF4固定标志4文件总长度4剩余文件大小8WAVE4固定格式类型12fmt 4格式块起始16fmt 块长度4通常为 1620音频格式21 表示 PCM22声道数21 单声道2 立体声24采样率4如 4410028字节率4采样率 × 声道数 × 位深 / 832块对齐2声道数 × 位深 / 834位深2常见 16一个简单的解析流程先读 RIFF 头验证标志然后循环读取 chunk找到 fmt 就把参数记录下来找到 data 就记录数据首地址和长度。数据块的位置可能不在文件末尾后面可能还有别的 chunk所以循环扫描 chunk 比直接按固定偏移读到 data 更可靠。4.2 字节序、内存占用和流式预留WAV 常见的样本格式是 16-bit signed PCM小端存储。如果字节序搞错播放出来就是一片噪声。解析完 data 块后我会先把每个采样的小端字节转成 int16再除以 32767 变成 float32。这段代码很无趣但值得单独写一个函数并用已知素材测一次后面所有版本都靠这个基础。内存占用目测一下很快就知道为什么要考虑流式加载44.1kHz、16-bit、单声道的一秒大约是 88KB一段两分钟的立体声背景音乐大约要 21MB。游戏音效普遍短全量驻留内存没问题但长音乐如果也全量塞进内存很快就会打爆资源预算。第一版我没有做流式解码只在 Sound 结构里留了一个 bStreaming 标志和分块预留位置。因为流式要涉及后台解码线程和环形缓冲属于另一个复杂话题。建议你也这样先让静态 WAV 播放跑通给流式留出扩展位不要在初期就让加载器分成两条分支。4.3 上一套带引用计数的资源缓存音频资源和纹理资源一样需要防止重复加载。引擎的资源系统通常已经有一张全局表音频资源直接塞进同一个表但有一个额外要求引用计数不能只看“有没有人持有 Sound 句柄”还要看“有没有 Voice 正在播放它”。如果一段音效还在播放资源就被换掉音频线程下次读取就可能崩溃。所以我在 Sound 上维护了一个 voiceRefCount每次创建 Voice 时 1Voice 销毁时 -1。卸载模块检查这个计数只要不是 0 就不允许释放资源。这个保护机制不是给正常流程准备的是给切场景、热加载这些边界情况兜底的。5. 实测最容易翻车的地方爆音、断流、循环咔哒5.1 爆音的两种真凶缓冲欠载和直流偏移爆音是最常见的音频问题但原因往往完全不同。第一种是缓冲欠载混音线程来不及在回调前填满缓冲设备读到一半没有数据只能在缺口处补零补零的瞬间就出现 click。排查时我在回调里加了一个统计变量记录每次回调实际写入的样本数。如果连续几次都小于请求长度基本可以断定是主线程拖累了音频线程。第二种爆音来自素材本身。有些 WAV 的第一帧不是从 0 开始的带着明显直流偏移直接播放会让设备在第一帧瞬间跳变听起来就是“啪”的一声。解决方式是在每个 Voice 的起始位置预留几毫秒淡入比如前 10 毫秒线性从 0 升到目标音量。这会影响音效的“攻击感”所以淡入越短越好只要能把直流跳变抹平即可。5.2 音频回调线程里的线程地狱音频回调要实时性。平台设备给回调的时间窗口非常短你必须在几毫秒内返回否则下一次回调的调度会受到干扰。所以回调里禁止做三件事加锁、分配内存、做文件 IO。我一开始在回调里用了 Mutex 保护 Voice 列表结果音乐一变多就开始断续。后来改成“主线程只更新一个原子变量和简单数组回调读取时若发现版本号变化则跳过一帧更新”本质就是 producer-consumer 的思想主线程写、音频线程读中间不做同步锁只靠原子变量保证可见性。Voice 的增删则利用主线程的空闲帧到一个 deferred list 里做这样回调永远不会去管理内存。这里还要警惕一个隐藏问题回调里也不要轻易调用平台日志函数。某些平台上日志实现会内部加锁或做格式化一样会造成卡顿。调试时可以先用一个宽松的无锁日志环最后看时间戳。5.3 循环点与素材边界的咔哒声背景音乐做循环播放时循环点如果恰好落在一个波形幅度很高的位置重新从头播放的瞬间就会跳变听感就是咔哒。这个问题的本质是循环点两端波形不连续。第一版我给循环 Voice 加了很简单的处理在循环即将发生的那一帧做一个 1-2 毫秒的交叉淡出把旧位置的音量降下来再把新位置音量升上去。交叉很短暂大多数音乐听不出副作用。更讲究的引擎会在导入素材时自动搜索离循环点最近的过零点并调整循环位置但那是编辑器工具层面的优化不是第一版该做的事。5.4 声音发闷、噪声大逐项确认数值如果你听完发现发闷或者噪声大先别急着换播放算法按顺序排查播放出来是噪声而不是音效十有八九是字节序或位深解析出错打印第一个 data 块的几个样本对照十六进制验证。明显削波看混音到的最终值有没有大量超过 ±1.0降低每个音源的基础音量。只有一边响或左右不对确认声道数是否解析正确检查 data 块是否把左右声道交错存储的样本拆错了。听起来很闷或高频缺失看看是不是素材本身采样率太低或者你哪步把样本错误地压缩了。这些我都踩过几乎都和算法无关都是基础解析、类型转换的问题。6. 不用玄学调音用波形和数据验证音频子系统6.1 先用 Python 造一批可控的测试音频耳朵的主观判断容易掩盖问题尤其是刚开始做的时候。我的做法是先用一小段脚本生成几组标准测试 WAV1kHz 正弦波、440Hz 正弦波、扫频、静音。比如生成一段 1kHz 正弦波import math import struct import wave sample_rate 44100 duration 2.0 freq 1000.0 n_samples int(sample_rate * duration) with wave.open(tone_1k.wav, wb) as w: w.setnchannels(1) w.setsampwidth(2) w.setframerate(sample_rate) for i in range(n_samples): t i / sample_rate val int(32767 * 0.5 * math.sin(2 * math.pi * freq * t)) w.writeframes(struct.pack(h, val))1kHz 正弦波可以直接验证播放速度和音高是否对如果播放时长不是两秒或者听感音高明显不对那采样率处理就有问题。扫频音频可以快速检查整个频带有没有明显断裂。静音音频则用来排查噪声底如果静音文件播放出来有杂音说明样本转换或混音链路上引入了直流偏置。6.2 最小自动化测试清单我把第一版音频子系统的自动化测试收敛成了下面这份清单每项都可以在无人工听音的情况下跑加载 WAV 后采样数、采样率、声道数与源文件一致。创建 Voice 后状态能从“等待”变成“播放”播放位置按每帧样本数前进。混音函数输入两个同频率正弦波数组输出振幅等于两者之和的近似值。移动 Listener 与 Voice 的相对位置左右声道的增量和距离衰减曲线符合预期。资源释放前存在活跃 Voice 时引用计数阻止卸载。每次改完混音和空间化代码我都先跑自动化测试再亲自带上耳机做主观试听。自动化测试证明没跑偏主观试听决定好不好听两者都不能缺。这套基础做完之后我心里对引擎整体结构终于踏实了。如果你也在做自己的简单引擎我的建议是先让音频“能响、不断、能控制音量”再去追求空间化和高级效果稳定性永远比特效优先级高。先把这个最小闭环跑通后面加的 HRTF 之类才找得着地方挂。