SoundCompass：从立体声定位到 FPS 声源罗盘 HUD

SoundCompass 从系统立体声中提取有边界的方位线索，并以全圆 360° HUD 呈现。

问题与定位

SoundCompass 面对的不是“把声音显示在屏幕上”这么简单，而是如何从系统输出的双声道信号中提取稳定、可解释的方位线索，再把结果叠加到游戏窗口。

资料将它定位为 Windows 桌面工具：通过 WASAPI loopback 采集输出设备的立体声流，不需要虚拟声卡；随后用 ILD（左右电平差）和 ITD（左右时间差）估计声源方位，并以全圆 360° 罗盘 HUD 呈现。

信号与前后方向的限制

脚步等窄带低频声音的时域互相关峰值滞后接近零：低频波长相对头部尺度更大，ITD 在这类信号上难以提供有效区分。若仍让低频信号主要走 ITD，已经得到的左右方向会被重新拉回正前。

不同事件的频段和持续形态不同，统一阈值很难同时解释脚步、枪声、爆炸和底噪。前后方向也不能在资料不足时被包装成确定答案。

核心方案：ILD 主导、ITD 微调

左右方位主要经过 Mid/Side 分解、频域掩码和幂次映射展开；脚步定位重点关注 1500~4000Hz 频段。

ITD 不再作为所有声音的默认主导，而只在宽带信号或高频瞬态中参与微调。这样做的目标不是制造“全方向都精确”的错觉，而是让适合用电平差解释的信号保留其可用信息。

前后方向采用条件化表达：只有匹配 ABI Profile 时才进行判定；在泛 FPS 环境或匹配失败时，后方保持 Unknown。这一规则把算法能力和环境先验分开，避免 HUD 用看似精确的图标掩盖不可辨识的情况。

按声源类型拆分检测与渲染

点声源使用固定幅宽的小扇形；颜色浓度随置信度变化，径向深度随音量变化。渲染层因此不只显示一个角度，还把事件类别、可信程度和相对强弱放在同一套视觉语义中。

关键工程实现

采集与信号处理链路

采集入口是 WASAPI loopback，监听系统音频输出而不是读取游戏进程。资料明确强调无需虚拟声卡，这使工具的输入边界更直接。

信号处理以双声道为基础，先通过 Mid/Side 分解组织左右信息，再针对定位段使用频域掩码，最后通过幂次映射展开角度。对宽带声音，ITD 可作为补充；对低频窄带脚步，则保留 ILD 的主导地位。

HUD 与窗口对齐

HUD 跟随前台窗口，并按 DPI 换算物理像素来对齐。已有资料特别列出 125% 和 150% 缩放下的自适应要求，说明叠加层不能只依赖逻辑坐标。

指针还会根据帧质量自动隐藏或淡出，避免低质量输入持续制造视觉噪声。

配置、调试与数据准备

托盘菜单提供采集设备切换、灵敏度调节和四个方位解析参数，灵敏度范围为 0.25~4.0，配置实时生效。

工具还包含自动样本采集与事后标注，用于为后续 ABI Profile 训练储备数据。这里能确认的是“准备数据”的能力，资料没有给出训练集大小、模型形式或已完成的 Profile 数量，因此不能把它描述为已经完成的通用识别模型。

项目资料给出的技术栈是 C#、.NET、WASAPI 与 DSP。但当前可见资料没有展开具体类、线程模型、采样率、帧长、FFT 实现或渲染框架，文章只保留已被资料直接支持的工程链路。

边界与验证

SoundCompass 的边界是设计的一部分：

• 只监听系统音频，不读取、不修改游戏进程。
• 后方在缺少匹配 ABI Profile 时显示 Unknown。
• 低质量帧会隐藏或淡出指针。

资料还记载，ILD 主导的决策经过多轮实测验证，但没有提供测试场景清单、样本数量、误差统计或对比基线。因此本文只能把它写成已有的设计验证依据，不能进一步声称准确率、延迟、帧率、资源占用或兼容游戏数量。

从可复核的行为看，验证重点包括：

1. 低频脚步不被 ITD 权重拉回正前。
2. 五类声源按照各自频段与时域特征进入不同渲染语义。
3. 前后判定遵守 ABI Profile 条件。
4. 采集设备、灵敏度、解析参数和 DPI 缩放变化能够反映到运行中的 HUD。

至于是否已经正式发布、服务过多少用户、覆盖多大规模环境，现有本地资料均未说明。

总结

SoundCompass 的价值在于把一个容易被“空间音频”宣传带过的问题拆开：先承认不同频段的物理线索并不等价，再用 ILD 主导和 ITD 微调组织定位链路。

同时，它把五类声源拆成独立检测与渲染规则，并用 ABI Profile 约束前后方向的可用范围。它最终呈现的不是一张替代判断的“透视图”，而是一个有置信边界、可调试、可以看见声音的桌面 HUD 原型。