Web端高性能媒体采集与实时处理需绕开黑盒API，直触原始帧与样本：用WebCodecs替代MediaRecorder获取PCM数据，约束getUserMedia参数以减少冗余计算，结合WebAssembly加速推理，并用Worker隔离处理线程。
Web 端实现高性能媒体采集与实时处理，关键不在堆功能，而在选对层、控住流、压稳延迟。核心是绕开黑盒 API，直触原始帧与样本，同时兼顾浏览器兼容性与端侧算力边界。
用 WebCodecs 替代 MediaRecorder 做底层音频采集
MediaRecorder 封装过深，无法控制编码参数、无法获取原始 PCM 数据，也不支持自定义采样率或通道数。WebCodecs 提供 AudioData 接口，可直接拿到 16-bit PCM 样本：
- 调用 AudioContext.createMediaStreamSource() 获取音轨后，用 AudioWorklet 注入处理逻辑（如 VAD 检测、响度归一化）
- 通过 AudioDecoder 解码 Opus/WAV 流时，指定
sampleRate: 16000和numberOfChannels: 1匹配 Whisper 输入要求 - 避免使用
MediaRecorder.start()录制整段 WAV，改用 AudioData.copyTo() 分块提取 buffer，每 200ms 取一次 3200 样本（16kHz × 0.2s），送入推理 pipeline
约束采集质量，从源头减少冗余计算
getUserMedia 的 constraints 不只是“能用”，而是“只取所需”：
- 音频设
{ echoCancellation: true, noiseSuppression: true, sampleRate: 16000, channelCount: 1 }—— 关闭立体声、固定采样率，降低后续重采样开销 - 视频若用于辅助识别（如唇动同步），用
{ width: { max: 320 }, height: { max: 240 }, frameRate: { max: 15 } }，避免高分辨率帧挤占主线程 - 用 MediaStreamTrack.getSettings() 实时校验实际生效参数，某些安卓设备会降级采样率，需 fallback 到 8kHz 并调整模型输入尺寸
用 WebAssembly + TensorRT.js 加速端侧推理
Whisper small 模型在桌面 Chrome 上推理耗时约 800–1200ms/秒音频，纯 TF.js 易卡顿。可行路径是：
- 将 Whisper encoder 部分导出为 ONNX，用 ONNX Runtime Web + WebAssembly 后端加载，比 TF.js 快 2–3 倍
- 对 decoder 做 token-level 流式解码：不等整句结束，每生成 3–5 个 token 就触发一次 UI 更新，模拟“边说边转写”体验
- 启用 tf.setBackend('wasm') 并预热模型（warmup run），避免首次调用时 JIT 编译导致的 300ms+ 毛刺
用 Worker 隔离采集与处理线程
音频采集和解码必须在主线程（因涉及 getUserMedia 权限和 AudioContext 创建），但模型推理、文本后处理、网络上报应移出：
- 创建 AudioWorklet 处理前端音频特征（如 MFCC 提取），再通过 MessagePort 将 float32Array 发给 DedicatedWorker
- Worker 内运行 Whisper 推理 + punctuation restoration，完成后 postMessage 返回带时间戳的文本片段
- 主线程仅负责渲染和状态同步，避免因长推理阻塞 UI 响应或音频采集帧率
