游戏内语音
Category
system / 玩法系统（实时通信件）。节点定位：游戏内语音把「玩家的声音」变成「低延迟、可治理、可合规」的实时流——采集编码、房间拓扑、空间音频、内容合规四件事。传输底座与广播机制在 networking 树的广播与推送，房间与队伍的绑定关系在队伍匹配，本页只管语音链路本身。
Definition
游戏语音按拓扑分三种：房间制（小队/公会语音，服务端转发，主流）、P2P（点对点直连，省服务器但打洞失败率高）、空间语音（按听者与说者的游戏内位置衰减与定向，如大逃杀就近说话）。按触发分两种：常开（open mic）与按键说话（PTT）。共同链路：采集 → 回声消除/降噪 → 编码 → 传输 → 转发 → 解码 → 播放。
Problem
语音的坑按出现顺序：
- 延迟与抖动：游戏状态同步可以插值补偿，语音断续没有补偿手段——抖动缓冲设多大，是延迟与流畅的直接权衡。
- 回声与噪音：不开回声消除（AEC），外放玩家的麦克风把队友的声音回传，形成啸叫循环。
- 带宽失控：全员常开麦克风，房间内人人互发，带宽随人数平方增长——拓扑选错，服务器与客户端都扛不住。
- 滥用与审核：语音辱骂、外挂语音报点、广告——文本有敏感词过滤，语音的治理成本高一个量级。
- 合规：录音留存、未成年人保护、隐私授权，各发行地区要求不同，事后补做代价大。
Algorithm
链路与拓扑：转发制为主，编码自适应
text
发送端: 采集(16kHz~48kHz) → AEC/NS → Opus 编码(自适应码率)
传输: RTP/UDP（可靠层自行处理丢包：冗余包/FEC/重传协商）
转发: SFU（选择性转发单元）：收到各路流，按订阅关系转发，不混音
接收端: 抖动缓冲 → 解码 → 混音(客户端) → 播放三种拓扑的取舍：
| 拓扑 | 原理 | 优点 | 代价 | 适用 |
|---|---|---|---|---|
| P2P | 端到端直连 | 零服务器转发成本 | 打洞失败回落、N 人全互连带宽平方级 | 1 对 1、极小队 |
| MCU | 服务端混音后发一路 | 客户端带宽恒定 | 服务端混音算力贵、延迟增加 | 电话会议式、超小队 |
| SFU | 服务端只转发不混音 | 服务端算力省、客户端可按需订阅 | 客户端要解码多路并自行混音 | 游戏小队/公会主流 |
- 编码用 Opus（开放标准，公开规格文档）：码率自适应是它的内建能力，弱网自动降码率——与弱网对抗的降级思路同源
- 抖动缓冲自适应：起步小、监测到抖动再拉大——固定大缓冲延迟高，固定小缓冲断续多
- 语音对延迟的容忍高于游戏状态同步（几百毫秒可对话）、远低于异步消息——链路优化的预算按这个量级分配
房间模型：与游戏会话绑定，令牌准入
- 语音房间寄生于游戏会话：小队组建即建房、解散即销毁——不独立管理房间生命周期，避免「人在队外房里」的悬挂态
- 准入用短时令牌：加入语音房先向游戏服务端换令牌（校验队伍身份），拿令牌连语音网关——语音服务不直接信任客户端的房间号
- 定向语音（「只对某人说话」）是房间内订阅关系的粒度问题：SFU 按订阅转发，客户端 UI 控制订阅——服务端不需要「定向频道」这个概念
空间语音：衰减与定向在客户端
- 服务端只按 AOI 决定「谁订阅谁的流」（附近的人），衰减与声像定位全在客户端：距离衰减曲线、左右声道定位按本地坐标算——服务端转发原始流，不理解空间
- 订阅范围随移动动态变化：靠近加入、远离退订，判定复用 AOI 的视野口径——空间语音是「听觉版 AOI」
- 阵营隔离是订阅关系的过滤条件：敌我辨识在服务端的订阅过滤层做，不靠客户端自觉
治理与合规：采样审核 + 分级权限
| 手段 | 口径 |
|---|---|
| 举报 | 玩家举报绑定房间号 + 时间窗，审核回放取该窗口 |
| 抽样转写 | 语音采样转文字后机审（敏感词/模型判别），命中再人工 |
| 权限分级 | 队长可禁言成员；房间创建者可整体闭麦 |
| 留存 | 录音留存期限与用途按发行地区法规，默认最短化 |
| 授权 | 首次开麦前明示麦克风用途与录制口径（隐私合规） |
- 审核是事后抽查 + 事中举报，不做全员实时转写——成本与隐私双红线
- 队内语音与全队语音的开放策略随品类：竞技品类默认只开队内（信息泄漏防线），社交品类开放公共频道——开与不开是品类决策，不是默认能力
Used By
- Valorant / CS2（商业竞技 FPS，官方公开资料）：队内语音为核心协作件，公共频道默认收紧——「竞技品类默认队内」的参照。
- 王者荣耀 / 和平精英（商业手游腾讯）：小队语音常开 + 变声处理，是手游语音与社交玩法结合的公开参照。
- Discord（商业语音社区）：语音房间与游戏状态绑定的社区形态、按需订阅的房间模型，是「游戏外语音」的事实标准参照。
- WebRTC（开放标准与开源实现栈）：采集、编码、传输、抖动缓冲的完整开源参照，本页链路图的直接出处。
- Mumble（开源低延迟语音，公开项目）：低延迟定位与_positional audio_（空间音频）的开源实现参照。
- FF14（商业 MMO，官方公开形态）：不内置语音、社区用第三方语音工具——「MMO 可以不做游戏内语音」的品类反例参照。
可参考分析：WebRTC=可参考（链路与抖动缓冲直接落本页链路一节）；Mumble 空间音频=可参考（衰减在客户端的口径落空间语音）；腾讯系小队语音=可借鉴（手游形态与变声，落房间模型）；Discord=可借鉴（房间与游戏绑定的边界感，落点 design 树社交设计）；FF14 不内置=可借鉴（品类决策口径落治理一节末段）。
Related
关系链：链路编码 → 房间拓扑 → 空间订阅 → 治理合规。逐段回答「为什么需要下一个」：
- 链路定了传输成本，才谈拓扑——P2P/MCU/SFU 的取舍就是在链路成本上做分配。
- 拓扑定了房间边界，才谈订阅——空间语音是房间内订阅关系的动态化。
- 订阅清楚了才谈治理——举报与禁言都锚定「房间 + 时间窗」，没有房间模型就无处锚定。
- 治理立住了才敢默认开麦——语音的公共面风险与走马灯同类，先审后开是底线。
上游：networking 树的广播与推送（传输与弱网降级）、队伍匹配（语音房与队伍绑定）、AOI（空间语音的订阅范围）；下游：走马灯与公告（同类公共面治理口径）、运营合规节点（留存与授权的运营侧承接，待建）。
Reference
- 本页为机制归纳；Opus/WebRTC/Mumble 以各自公开标准与项目文档为准，不引私有接口。
- 语音合规（留存、转写、未成年人）以发行地区现行法规为准，本页只列通用口径。
- 术语对照：Voice Chat（游戏内语音）、PTT/Push-to-Talk（按键说话）、SFU/Selective Forwarding Unit（选择性转发）、MCU（多点混音）、Opus（开放音频编码）、AEC/Acoustic Echo Cancellation（回声消除）、Spatial Audio（空间音频）。