1. 从“听不清”到“看得见”全局字幕机到底解决了什么问题线上会议听不清对方说话、看没有字幕的外语视频只能靠猜、录屏教程时自己的解说和系统声音混在一起没法分离——这些场景我猜你多少都遇到过。传统做法要么是事后用剪辑软件手动加字幕要么是单独开一个录音软件再跑一遍离线识别流程割裂、延迟感人。而所谓“全局字幕机”核心思路就是把实时语音识别ASR做成一个常驻后台的系统级服务同时抓取麦克风和电脑内部播放的声音把两路音频混合后实时转写成文字再以悬浮窗或字幕条的形式叠加在屏幕最上层。这件事在 Windows 上之所以以前不好做是因为音频采集这一层一直比较割裂。麦克风属于输入设备走的是常规的录音接口而电脑正在播放的声音属于输出设备的“回环”需要额外的虚拟声卡或者系统级的回环采集能力才能拿到。Wisp 这个开源项目之所以让人觉得“狠”就是它把这两路音频的采集、混音、送入 ASR 引擎、再把结果实时渲染成字幕这一整条链路全部在 Windows 上跑通了而且不依赖额外的虚拟声卡驱动。它适合谁用我梳理了一下大致是这几类人经常参加跨语言线上会议、需要实时看字幕的职场人做视频教程、需要给自己录屏配实时字幕的创作者听力有轻微障碍、需要文字辅助理解音频内容的用户以及想研究 Windows 音频采集和实时 ASR 集成的开发者。不管你是哪一类理解它背后的技术链路都能帮你更好地配置它、排查它的问题甚至基于它做二次开发。这篇文章我会从音频采集的底层机制讲起把 WASAPI 回环、麦克风采集、混音、ASR 推理、字幕渲染这几个环节逐一拆开再给出可复现的配置步骤和我自己踩过的坑。你不需要是音频工程师但读完应该能自己把这套东西跑起来并且知道出问题时该往哪个方向查。2. WASAPI 回环采集为什么它是 Windows 全局字幕的关键一环2.1 麦克风和系统声音的本质区别先把这个概念理清楚不然后面全是糊涂账。在 Windows 的音频体系里麦克风是捕获设备Capture Device系统播放的声音是渲染设备Render Device。你平时用录音软件录麦克风走的是捕获设备的接口这个很直观。但你想录“电脑正在播放的声音”问题就来了——渲染设备的数据是往扬声器或耳机送的系统默认并不提供一条“把正在播放的声音再复制一份出来”的通道。早期大家怎么解决装一个虚拟声卡把系统输出重定向到虚拟声卡再从虚拟声卡的捕获端把声音录下来。这个方案能用但多了一层驱动延迟增加而且虚拟声卡本身可能引入爆音、采样率不匹配等问题。WASAPI 从 Windows Vista 开始引入了一个叫回环采集Loopback Capture的机制允许应用程序直接对某个渲染设备做捕获拿到它正在播放的音频数据不需要虚拟声卡。这就是 Wisp 能在不装额外驱动的前提下同时抓两路声音的根本原因。2.2 WASAPI 回环的工作模式与采样参数WASAPI 回环采集在代码层面和普通捕获很像都是通过IAudioClient初始化一个流然后从IAudioCaptureClient里读数据。区别在于初始化时传入的设备是渲染设备并且要设置AUDCLNT_STREAMFLAGS_LOOPBACK标志。这里有几个参数必须注意参数说明常见取值采样率回环流的采样率必须和渲染设备当前的混音格式一致44100 Hz 或 48000 Hz位深通常为 16 位或 32 位浮点16-bit PCM / 32-bit float通道数跟随系统混音格式通常为 2 声道2共享模式回环采集必须用共享模式AUDCLNT_SHAREMODE_SHARED缓冲时长影响延迟太短容易丢数据100ms 左右较稳我实测下来最容易出问题的是采样率不匹配。比如你的系统混音格式设的是 48000 Hz但 ASR 引擎期望 16000 Hz 单声道中间就需要做重采样和声道下混。Wisp 内部应该是做了这一步转换的但如果你自己写采集代码这一步漏了送进 ASR 的数据就是错的识别结果会乱七八糟。2.3 麦克风采集与回环采集的同步难题两路音频各自采集时间戳对不齐怎么办这是全局字幕机的一个隐藏难点。麦克风采集和回环采集是两个独立的音频流它们的启动时间、缓冲节奏、时钟源都可能不同。如果直接把两路数据按到达顺序混在一起会出现“人声比系统声音早半秒”或者“字幕和声音对不上”的情况。常见的处理方式是给每路数据打上基于性能计数器的时间戳然后在混音前做时间对齐。Wisp 这类项目通常会在采集回调里记录QueryPerformanceCounter的值换算成音频帧位置再按帧对齐混合。如果你只是做字幕对同步的要求没有做音乐那么苛刻几十毫秒的偏差人耳和阅读都还能接受但超过 200ms 就会明显觉得字幕滞后。提示如果你发现字幕总是比声音慢一截先别急着怪 ASR 模型慢很可能是采集缓冲设太大了。把回环和麦克风的缓冲时长从默认的 200ms 降到 100ms 甚至 50ms延迟会明显改善但要注意丢帧风险。2.4 为什么不用虚拟声卡方案有人会问虚拟声卡方案不是更成熟吗为什么 Wisp 要用 WASAPI 回环我的理解是三点第一零额外依赖用户不用装驱动开箱即用第二延迟更低少一层驱动转发第三更干净虚拟声卡有时会把系统提示音、其他应用的声音一起混进来而回环采集可以针对特定渲染设备。当然回环方案也有代价比如某些独占模式的音频应用可能抓不到或者蓝牙耳机切换设备时回环流会断这些后面排错章节会细说。3. 两路音频混合把麦克风和系统声音揉成一条 ASR 能吃的流3.1 混音不是简单相加拿到两路 PCM 数据之后最直觉的做法是逐样本相加。但这里有个坑如果麦克风音量很大系统声音也很大直接相加会溢出削波波形被削平之后 ASR 识别率会下降。正确的做法是先做增益控制再相加最后做限幅。我一般会这样处理麦克风增益设 0.7 左右系统声音增益设 0.5 左右相加之后如果绝对值超过 1.0 就做软限幅。具体系数要根据你的实际环境调安静环境下麦克风可以高一点嘈杂环境或者系统声音本身很大的话就要压低。Wisp 的配置里应该有类似的增益选项如果没有你可以通过系统音量先做粗调。3.2 重采样与声道下混的必要性ASR 引擎通常期望16kHz、单声道、16位 PCM的输入。而 WASAPI 回环拿到的往往是 48kHz、双声道、32位浮点。这中间要做两步转换重采样48kHz 降到 16kHz比例是 3:1。可以用简单的抽取但更稳的是用带抗混叠滤波的重采样库比如 libsamplerate 或 speex 的 resampler。声道下混双声道变单声道通常是把左右声道取平均。但要注意如果系统声音里左右声道内容差异很大比如某些立体声音效直接平均可能丢失信息不过对语音识别来说影响不大。这两步的顺序建议先下混再重采样因为下混的计算量小先做可以减少重采样的数据量。当然如果你用 GPU 做重采样就无所谓了。3.3 音频帧的切分与送入 ASR 的节奏ASR 模型不是一次性吃一整段音频而是按帧或块处理的。常见的做法是每次送 20ms 到 40ms 的音频数据模型输出一个中间结果再通过流式解码拼成完整句子。这里的关键是送入节奏要和采集节奏匹配不能采集了 1 秒才送一次那样延迟就爆炸了。我的经验是采集回调里每攒够 320 个样本16kHz 下就是 20ms就送一次 ASR。如果 ASR 推理速度跟不上可以适当加大到 40ms 或 60ms但延迟会相应增加。Wisp 应该是用了类似的流式策略具体块大小可以在配置里看。3.4 回声消除要不要做如果你同时开麦克风和系统声音而系统声音又从扬声器放出来麦克风会二次采集到系统声音造成回声ASR 会把同一句话识别两遍。解决办法有两个一是戴耳机物理隔绝二是做回声消除AEC。AEC 算法比较复杂WebRTC 的 AEC 模块是常用的开源方案。如果你戴耳机用这一步可以省掉如果必须外放那 AEC 基本是刚需。注意回声消除会引入额外的计算延迟而且对双讲场景你说话的同时系统也在放声音处理不好会吃掉一方。全局字幕机场景下如果主要是听会议内容、自己很少说话AEC 的副作用可以接受。4. ASR 引擎选型与流式识别Wisp 背后可能用的方案4.1 离线模型和在线服务的取舍做实时字幕ASR 引擎的选择直接决定体验。大致分两派离线本地模型和在线云服务。离线模型的优势是隐私好、不依赖网络、没有调用费用缺点是首次加载慢、占用内存和 CPU/GPU 资源、小模型准确率有限。在线服务准确率高、模型大但有网络延迟、隐私顾虑和费用问题。Wisp 作为开源项目大概率是走离线路线可能集成了 Whisper 系列的小模型或者用 sherpa-onnx、Vosk 这类专为流式识别优化的引擎。Whisper 的准确率很好但原生 Whisper 不是流式的需要配合滑动窗口做伪流式延迟会偏大。sherpa-onnx 支持真正的流式识别延迟可以做到几百毫秒以内更适合字幕场景。4.2 流式识别的分块策略流式 ASR 的核心是把连续音频切成块每块独立推理再把结果拼接。这里有个上下文窗口的问题如果每块完全独立块与块之间的词会被切断识别结果会出现断字。解决办法是让相邻块有重叠比如每块 1 秒重叠 200ms解码时把重叠部分对齐合并。另一种方案是用带状态的流式模型模型内部维护一个隐状态每次输入新块时状态延续不需要重叠。sherpa-onnx 的流式模型就是这种。Wisp 如果用这类引擎延迟和准确率的平衡会更好。4.3 中文识别的特殊处理中文 ASR 和英文有个明显区别中文没有空格词与词之间没有天然分隔所以分词和标点恢复对可读性影响很大。很多流式引擎输出的是一串没有标点的汉字直接显示成字幕会很难读。Wisp 如果做了标点恢复那体验会好很多如果没做你可能需要自己接一个轻量的标点模型。另外中文的同音字问题在短句上更明显流式识别因为上下文短错误率会比整句识别高。这是流式方案的固有代价只能通过加大上下文窗口或者用更好的模型来缓解。4.4 资源占用与实时性的平衡离线 ASR 在 CPU 上跑实时率RTF是关键指标。RTF 小于 1 表示处理速度比实时快大于 1 就跟不上。Whisper tiny 在普通 CPU 上 RTF 大概 0.3 到 0.5base 模型可能到 0.8 左右再大就跟不上了。sherpa-onnx 的流式模型优化得比较好CPU 上 RTF 可以做到 0.2 以下。如果你机器有独立显卡可以用 GPU 推理RTF 会大幅下降但要注意显存占用和驱动兼容性。我的建议是如果只是做字幕优先选小模型加流式引擎把延迟压下来比追求极致准确率更重要。字幕嘛能看懂就行偶尔错一两个字不影响理解。5. 字幕渲染与悬浮窗让文字稳稳叠在最上层5.1 悬浮窗的实现方式字幕要显示在所有窗口之上Windows 下通常用分层窗口Layered Window加WS_EX_TOPMOST和WS_EX_TRANSPARENT扩展样式。WS_EX_TOPMOST保证窗口置顶WS_EX_TRANSPARENT让鼠标点击穿透不影响你操作下面的应用。Wisp 的字幕条应该就是这么做的。渲染方式有两种用 GDI 直接画或者用 Direct2D 做硬件加速。GDI 简单但文字多了会闪Direct2D 流畅但代码复杂。对于字幕这种低频更新的场景GDI 其实够用只要做好双缓冲避免闪烁。5.2 字幕的排版与可读性字幕可读性有几个要点背景半透明、字体够大、行数限制、自动换行。纯文字叠在复杂背景上会看不清加一个半透明黑底能大幅提升可读性。字体建议用无衬线体字号根据屏幕分辨率调1080p 下 24 到 32 像素比较合适。行数一般限制在两到三行超过就滚动或截断不然会挡住太多屏幕内容。还有一个细节是字幕更新频率。如果 ASR 每 20ms 出一个中间结果字幕每 20ms 刷新一次会闪得没法看。通常的做法是稳定显示当前识别结果先显示等下一个稳定结果出来再整体替换中间用淡入淡出过渡。Wisp 如果做了这个处理观感会好很多。5.3 多显示器与 DPI 缩放多显示器场景下悬浮窗要能正确出现在你指定的那块屏幕上并且跟随 DPI 缩放。Windows 的 DPI 处理一直是个坑不同显示器不同缩放比例时窗口坐标和字体大小都要做相应换算。如果 Wisp 在高 DPI 屏上显示模糊或者位置偏移大概率是没处理好 DPI 感知。提示可以在程序的 manifest 里声明PerMonitorV2的 DPI 感知级别这样窗口在不同显示器间移动时能自动适配缩放。如果项目没做你可以手动在显示设置里把缩放调成 100% 临时规避。5.4 字幕的保存与导出实时字幕除了看有时候还需要保存下来做记录。Wisp 如果支持把识别结果写入文本文件那就很方便。我一般会建议按时间戳分段保存格式类似[00:01:23] 识别内容这样事后回看能快速定位。如果项目没这功能你可以用 AutoHotkey 之类的工具监听剪贴板或者窗口文本做二次保存但稳定性不如原生支持。6. 实战配置从零把 Wisp 跑起来的完整步骤6.1 环境准备与依赖检查先把基础环境确认一遍。Windows 10 或 11 都行但建议 1903 以上WASAPI 回环的支持更完整。需要安装的运行时通常包括Visual C 运行库很多开源项目依赖缺了会报 DLL 找不到。.NET 运行时如果项目是 C# 写的需要对应版本。Python 环境如果 ASR 部分用 Python需要 3.8 以上并装好 onnxruntime 或 torch。音频驱动确保你的声卡驱动是厂商最新版Windows 自带的高清音频驱动有时回环采集会有问题。检查音频设备是否正常右键任务栏音量图标打开声音设置确认输入设备麦克风和输出设备扬声器/耳机都能正常识别并且采样率设置一致。我建议把输入和输出的采样率都设成 48000 Hz减少重采样环节。6.2 获取与编译 Wisp如果项目提供预编译包直接下载解压最省事。如果需要自己编译一般流程是git clone 项目仓库地址 cd wisp mkdir build cd build cmake .. cmake --build . --config Release编译时注意几个常见问题CMake 找不到依赖库时检查CMAKE_PREFIX_PATH是否指向了正确的库路径如果用了 vcpkg 管理依赖记得先vcpkg install相关包。Windows 上编译 C 音频项目MSVC 版本和 Windows SDK 版本要匹配不然会出一堆链接错误。6.3 配置音频设备与 ASR 参数配置文件通常是 JSON 或 INI 格式重点看这几项配置项作用建议值capture_device麦克风设备 ID用工具列出设备后选具体 IDloopback_device回环采集的渲染设备 ID选你实际在用的输出设备sample_rateASR 输入采样率16000chunk_ms每次送入 ASR 的音频块时长20 到 40model_pathASR 模型文件路径指向下载好的模型gain_mic麦克风增益0.5 到 0.8gain_loopback系统声音增益0.3 到 0.6设备 ID 的获取可以用 Windows 自带的“声音”控制面板查看或者用 PowerShell 命令Get-PnpDevice -Class AudioEndpoint列出。配置改完记得重启程序生效。6.4 首次运行与延迟调优第一次跑起来先别急着看识别准不准先确认音频有没有进来。很多项目有电平指示或者日志输出看采集到的样本数是否在增长。如果一直是零说明设备选错了或者权限没给。确认有音频后看字幕延迟。如果延迟超过 1 秒按这个顺序排查先降 chunk_ms再降采集缓冲然后看 ASR 模型的 RTF 是不是大于 1。如果 RTF 大于 1说明模型太大跑不动换小模型。如果 RTF 正常但延迟还是大可能是字幕渲染的刷新策略问题检查是不是攒了很多结果才一次性显示。6.5 常见启动报错与快速修复报错信息可能原因修复方法找不到 xxx.dll运行库缺失装 VC 运行库无法初始化音频客户端设备被独占关掉独占模式的应用模型加载失败路径错误或文件损坏检查路径重新下载模型识别结果为空采样率不匹配统一设成 16000 或 48000字幕窗口不显示置顶失败检查是否有其他置顶窗口冲突7. 踩坑实录那些让我折腾半天的诡异问题7.1 蓝牙耳机切换导致回环流中断我用蓝牙耳机的时候遇到一个很烦的问题耳机一断开重连回环采集流就断了字幕直接停住。原因是蓝牙设备切换时渲染设备的 ID 会变原来绑定的回环流失效了。解决办法是监听设备变更事件在设备切换后重新初始化回环采集。如果 Wisp 没做这个处理你只能手动重启程序或者干脆用有线耳机。7.2 独占模式应用抓不到声音有些播放器或者游戏会申请独占模式音频输出这时候 WASAPI 回环是抓不到声音的。表现就是系统声音那一路一直是静音。解决办法是在那个应用的音频设置里关掉独占模式或者改用共享模式输出。这个坑比较隐蔽因为麦克风那路正常你会以为是混音出了问题其实是回环根本没数据。7.3 采样率不一致导致的“机器人音”有一次我把系统输出设成 44100 Hz但 ASR 配置里写的是 48000 Hz结果识别出来的文字全是乱的听起来像机器人音。原因是重采样比例算错了音频被拉伸或压缩。后来我把所有环节的采样率统一成 48000 Hz 输入、16000 Hz 送 ASR问题消失。采样率统一这件事怎么强调都不为过。7.4 字幕闪烁与残影早期版本的字幕条在快速更新时会闪烁还有残影。排查下来是 GDI 绘制没有双缓冲每次重绘先清空再画中间那一帧被看到了。加上双缓冲之后就好了。如果你自己写渲染记得用CreateCompatibleDC和CreateCompatibleBitmap做离屏绘制最后一次性 BitBlt 到窗口。7.5 CPU 占用飙高的排查跑了一段时间发现 CPU 占用很高风扇狂转。用任务管理器看ASR 推理占了大头。这时候有几个优化方向换更小的模型、降低推理频率比如每 40ms 送一次而不是 20ms、开多线程但限制线程数、如果有 GPU 就切 GPU。我最后是把模型从 base 换成 tinyCPU 占用从 40% 降到 15% 左右识别准确率下降有限字幕场景完全够用。8. 进阶玩法把全局字幕机用出更多花样8.1 会议记录自动归档实时字幕跑起来之后把识别结果按时间戳写入文件会议结束就得到一份完整的文字记录。如果再接一个简单的脚本把记录按段落整理、去掉重复的中间结果就能得到一份可读性不错的会议纪要。我用 Python 写了个小脚本监听字幕输出文件每 5 分钟做一次去重和分段效果还行。8.2 双语字幕的可行性如果你需要中英双语字幕可以并行跑两个 ASR 引擎一个识别中文一个识别英文然后把结果按时间对齐显示。不过这样资源占用翻倍而且两种语言的识别结果时间戳要对齐比较麻烦。更实际的做法是先用一个引擎识别再用翻译模型做离线翻译但翻译延迟会让字幕滞后体验不如单语。8.3 结合录屏做实时字幕视频录屏的时候开全局字幕机字幕直接叠在画面上录出来的视频自带字幕省去后期加字幕的步骤。注意录屏软件要能捕获悬浮窗有些录屏工具默认不录置顶窗口需要在设置里勾选。另外字幕的字体和背景要调得和视频风格协调不然会很突兀。8.4 给字幕加个历史回看面板实时字幕看完就没了有时候想回看前面说了什么。可以做一个简单的历史面板把最近几分钟的字幕列出来支持滚动。实现上就是把识别结果存到一个环形缓冲区面板定时刷新。这个功能对会议场景特别有用走神了还能补看。9. 我个人在实际操作中的几点体会折腾这套东西前前后后花了不少时间最大的感受是音频采集这一层的坑比 ASR 本身还多。模型选型、参数调优这些都有文档可查但 WASAPI 回环的设备切换、独占模式、采样率匹配这些问题往往要靠实际踩一遍才知道。所以如果你刚开始搞建议先把音频链路跑通用示波器或者音频分析工具确认两路声音都正常进来了再去调 ASR。另一个体会是延迟和准确率永远在打架。想要低延迟就得用小模型、短音频块但准确率会降想要高准确率就得大模型、长上下文延迟就上去了。字幕场景我的建议是优先保延迟准确率够用就行毕竟字幕是辅助理解不是法律文书。最后开源项目的好处是遇到问题能看源码、能改。Wisp 如果某个环节不符合你的需求完全可以 fork 一份自己改。比如你想换 ASR 引擎、想改字幕样式、想加历史面板代码都在那里改起来比闭源方案自由得多。这也是我愿意花时间研究它的原因。