游戏音频、空间环境与动态混音

1. 游戏语义与音频实体#

audNorthAudioEngine 是游戏侧总入口。naAudioEntity : fwAudioEntity 及大量专用 entity 把车辆、角色、武器、爆炸、门、玻璃、天气、前端、脚本和过场状态转为音频请求。

设计重点是持续维护“声音与世界的关系”：车辆转速、移动速度、环境遮挡、角色动画事件和战斗强度都随时间变化。它不是仅在事件发生时调用一次 PlaySound 的薄封装。

2. 一帧中的异步组织#

FinishUpdate 2116 行附近明确等待 semaphore，再完成 environment object list、车辆类别、audio controller、occlusion；未暂停时处理 conductor、缓存武器事件和延迟碰撞；随后处理 deferred sounds、batched requests、动态混音和音乐，最后标记 mixer 命令缓冲 ready。

这使游戏实体更新与音频计算有重叠，同时在安全点统一提交效果。AudioWait 耗时可能反映音频工作未完成，不应直接等同于声音设备输出延迟。

3. 延迟声音与对象引用#

CreateDeferredSound 有 name/hash/metadata ref 等重载，支持 entity、environment group、tracker、invalidate entity 和 persist across clears 等参数。注释说明声音加入延迟列表，随后在 FinishUpdate 触发。

延迟意味着触发者必须考虑实体在请求与消费之间的生命周期。entity tracker、删除对象列表与注册关系用于把声音位置和对象有效性衔接起来；直接缓存未经管理的实体指针会绕开这些约定。

处理 batched sound requests 时传入 0 timestep，注释解释这是同一帧第二次更新。这个细节避免把新增请求的处理误当作额外经过一整帧，从而重复推进计时。

4. 空间音频与环境#

geometry、audio zones、environment、async probes 提供空间环境信息，FinishUpdate 又有 occlusion 收敛步骤。声音是否被遮挡、是否处于室内/水下以及环境组选择，会影响最终听感。

游戏侧“可见”与音频侧“可听”不是同一集合。看不见的车辆和墙后的枪声仍可能需要声音；相反大量视觉对象未必都值得独立音源。音频需要自身兴趣范围和对象列表，不能简单复用渲染剔除结论。

这些文件证明遮挡与环境处理存在，但本次未检查全部混音算法和资源配置，不据此断言采用某一种完整声学传播模型。

5. 车辆、武器与动态混音#

车辆按 car/boat/heli/plane/train 等拆音频实体，并有 vehicleengine 和 vehicle reflections。动力学参数、类型和环境都参与声音塑造；只改变引擎 pitch 不能概括车辆音频。

weapon/gunfire/collision/explosion audio entities 把高频事件缓存、合并或在安全阶段处理。gunfight conductor、vehicle conductor、superconductor 与 dynamic mix modules 表明系统根据情境调节混音，而不让所有音源始终以固定音量竞争。

这种设计提升信息层次，但事件/类别/混音配置需要一起维护：枪声丢失可能是请求未产生、资源未就绪、被调度限制或被混音压低，需要分层定位。

6. 电台、语音、过场与回放#

radio station、track、history、streamslot 和 user radio manager 将连续音频内容与世界对象分离。speech manager 和 police scanner 又处理语义序列，通常不能与瞬态碰撞音效采用完全相同的抢占和恢复方式。

过场需要音画时间线同步，回放导出也涉及 mixer 时间与 video 时间追赶。Core/app.cpp 的回放分支会按总音频/视频时间推进额外音频更新，证明固定帧导出有特殊节奏；不能拿正常实时游戏帧的更新假设直接解释离线导出。

7. 性能与维护边界#

成本维度包括活动音源、语音/曲目 streaming、环境探测、事件峰值、混音命令量与等待。对象数量和播放声音数不是一对一关系。

后续验证应覆盖实体删除后尾音、暂停与恢复、电台切换、过场跳过、多人语音进入/退出、回放定位和导出。本次仅分析源码，未播放音频或执行资源工具。

8. 源码依据#

关联：动画、战斗、回放。