Scribe v3 升级实时转写，采集延迟仍需自解

ElevenLabs 的 Scribe v3 Live 宣称将实时语音识别的语义错误率降低 43%，但作者关心的是另一个问题：在 Windows 上做私人通话翻译，换更好的模型，为什么仍然不够快、不够私密？

文章的结论是，模型只处理送到它面前的音频。远端声音和本地麦克风怎么分开采集、回调怎么避免卡顿、字幕怎么避开屏幕共享，都得由桌面应用解决。对于做语音工具的程序员，这篇更值得读的部分是整条链路的工程取舍。

错误率下降 43%，改善的是哪一段

据原文，ElevenLabs 于 2026 年 11 月 10 日发布 Scribe v3 和 Scribe v3 Live。批处理模型宣称覆盖 102 种语言，相比 Scribe v2，词错误率降低 27%；实时版本则宣称，相比上一代实时模型，语义词错误率降低 43%。

这两组数字对应不同指标，不能合并成一个「准确率提升」。

实时版本还新增了实时说话人分离、基于上下文的轮次检测，以及句中切换语言。轮次检测解决的是「对方究竟说完没有」：它不再只靠静音语音活动检测（VAD）判断，而是结合上下文决定何时结束一轮发言。

模型 ID 分别是 scribe_v3、scribe_v3_live，实时服务沿用原有语音转文字 WebSocket 端点，原文没有给出具体 URL。实时端点价格维持在约每音频小时 $0.22，公开延迟宣传约为 150 ms 级别。

这些都是原文转述的产品指标，没有附测试集和复现过程。尤其是 150 ms，不能直接理解为「对方说话到中文字幕出现」的耗时。

为什么识别出说话人，还要保留两条音轨

云端语音识别（STT）只能看到应用上传的音频。它不会替应用访问 Windows 音频设备，也不会自动建立一条独立的麦克风处理链路。

作者为此采用双轨 WASAPI 采集：

• 在播放设备上做 loopback 回环采集，获取通话应用播放的远端声音。
• 在输入设备上采集本地麦克风，获取用户自己的声音。

两边各开一个 IAudioClient，都使用共享模式 AUDCLNT_SHAREMODE_SHARED。作者给出的周期目标约为 10 ms，实际会受音频引擎和混音格式约束；格式通常选择 48 kHz float32，或通过 GetMixFormat 获取设备混音格式。

双轨的价值是可以分别处理双方声音：远端音轨配置对方的语言，本地音轨配置自己的语言；两侧也可以采用不同模型，或者只用麦克风能量判断用户是否开始插话。

说话人分离是在混合音频里判断「谁在说话」。双轨则在输入阶段就把来源分开，后续的模型选择和数据去向都能独立控制。

这里有个边界：独立采集麦克风，不等于通话应用停止发送麦克风声音。文章讨论的是翻译工具自己的处理链路，不能据此理解为它自动改变了通话软件的输入。

回调里少做事，比宣传延迟更接近工程问题

作者反复强调，采集回调只负责搬运数据：调用 IAudioCaptureClient::GetBuffer 取出音频包，复制到无锁环形缓冲区，释放缓冲区，再通知工作线程处理。

内存分配、日志和 STT 请求都不要放进这条路径。回调执行时间一旦不稳定，音频就可能出现缺口或额外等待。

下面的伪代码展示了两个客户端如何初始化：

// Pseudocode outline — real code needs COM init, error handling, format negotiation
IAudioClient* loopbackClient = nullptr;
IAudioClient* captureClient = nullptr;
// ... ActivateAudioInterface / GetDefaultAudioEndpoint ...

// Loopback
loopbackClient->Initialize(
    AUDCLNT_SHAREMODE_SHARED,
    AUDCLNT_STREAMFLAGS_LOOPBACK | AUDCLNT_STREAMFLAGS_EVENTCALLBACK,
    hnsPeriod, 0, &mixFormat, nullptr);

// Capture
captureClient->Initialize(
    AUDCLNT_SHAREMODE_SHARED,
    AUDCLNT_STREAMFLAGS_EVENTCALLBACK,
    hnsPeriod, 0, &mixFormat, nullptr);

// Start both, then in the event callback:
// GetBuffer -> copy to ring -> ReleaseBuffer
// Signal worker thread that owns STT submission

重点看 AUDCLNT_STREAMFLAGS_LOOPBACK：它只出现在播放设备客户端上。代码省略了 COM 初始化、错误处理和格式协商，不能直接作为完整实现使用。

两路数据还需要按设备时钟或共享单调时间戳对齐。作者建议用少量丢帧、补帧修正漂移，只有测量证明需要时，才在关键路径加入重采样。具体调整哪一侧、阈值怎么定，原文没有展开。

作者将共享模式音频引擎和缓冲的开销列为 10–40 ms，并称这是测量所得，但没有提供设备配置和延迟分布。之后还要加上音轨对齐、必要的重采样、网络 RTT、模型计算、翻译和 UI 绘制。

云端模型的延迟，只是字幕总延迟中的一段。

测量工具方面，原文提到 IAudioClient::GetCurrentPadding、ETW 的 Microsoft-Windows-Audio 提供程序、回调周围的高精度计时，以及 Process Lasso 的 LatencyTest。实际排查时，应结合缓冲状态和时间记录判断，不能把单个读数直接当成整条链路延迟。

我的判断

我赞同作者把采集链路放回讨论中心。对于 Windows 通话翻译工具，双轨确实提供了混合流不容易获得的控制能力；共享模式也更符合用户同时运行通话软件和其他应用的使用方式。独占模式可能降低延迟，却会带来设备占用和驱动兼容问题。

但文章的证据强度有限。作者正在开发 Talkaside，并说明文章由项目代码和日志辅助起草，却没有给出 Scribe v3 Live 与本地模型的同条件对照。因此，「云端更擅长口音、噪声和专业术语」「本地延迟更低且更稳定」，都应视为带前提的经验判断。

原文列出的本地方案包括 faster-whisper、Whisper.cpp、Qwen3-ASR GGUF 变体，以及通过 Ollama 运行的 LFM3-audio。它们能去掉网络传输这一环，但实际延迟仍取决于硬件、模型大小和处理策略。

私密悬浮窗同样需要验证。作者建议在 Windows 10+ 上，对分层窗口调用 SetWindowDisplayAffinity 并设置 WDA_EXCLUDEFROMCAPTURE。这是文章提出的实现路径，原文没有展示各类共享方式下的兼容测试，不能直接扩大成「任何录屏都看不到」。

能拿来做什么

• 如果正在做 Windows 通话字幕或翻译，先分别记录采集、排队、识别、翻译和绘制耗时，再决定是否更换模型，避免只优化服务商公布的那个数字。
• 如果用前端或 Node 编排桌面语音应用，把原生采集回调保持为短路径，让后续线程消费音频，避免把日志、网络请求和界面工作塞进回调。
• 如果需要双方使用不同语言或模型，优先评估双轨；如果只处理单一混合流，再评估实时说话人分离能否满足需求。
• 如果要做本地与云端混合方案，可以参考作者「本地处理即时结果、网络良好时云端处理完整轮次」的思路，同时实测结果切换和悬浮窗共享效果。