
FluidVoice 流式转写架构解析StreamingTask 与实时字幕上屏原理【免费下载链接】FluidVoiceFastest and only macOS Dictation app with on-device STT and custom trained AI enhancement model. Windows pre-build available! A local Wispr Flow alternative. DM us on X exclusive model access! - https://x.com/fluidvoiceapp项目地址: https://gitcode.com/GitHub_Trending/fl/FluidVoiceFluidVoice 是一款面向 macOS 的本地流式听写应用主打 on-device 实时语音转写STT无需上传云端靠StreamingTask驱动每一小段音频转成文字并实时上屏是 Wispr Flow 的本地替代方案。本文拆解它的流式转写架构从音频分块调度、增量转写到智能 diff 让字幕平滑打字机式出现。为什么流式转写体验更好传统听写是说完再转你必须停顿、等待才能得到一长段文字。FluidVoice 走的是**流式Streaming**路线麦克风持续采集转写器每隔一小段就输出当前能听到的文字字幕像打字机一样逐字浮现。这种体验的核心在于边说边转其好处是低延迟不用等整句说完说话的同时文字就开始出现可观察随时能看到系统听到了什么出错能立刻察觉可打断说错可即时纠正最终文本以最后一次完整转写为准整体架构三大核心组件流式转写由三个角色协作完成全部集中在 ASRService.swift 与 ParakeetRealtimeProvider.swift 中。组件职责所在位置StreamingTaskLifecycle管理空闲延时与进行中任务的生命周期ASRService.swift第 251 行processStreamingChunk每到一个周期取音频分块并转写、上屏ASRService.swift第 5259 行ParakeetRealtimeProvider真正的增量转写引擎消费新增 PCM独立文件StreamingTaskLifecycle是整个流式调度器的心脏。它区分两种状态scheduler空闲延时任务和active真正在转写的任务。这样设计的关键价值是——停止录音时只取消空闲延时而不会粗暴地打断正在计算中的转写任务让它在后台善后完成。scheduler ──(延迟到期)── active ──(转写完成)── 完成回调 (等待下一周期) (正在转写) (释放等待者)StreamingTask 的调度原理调度入口在 ASRService.swift 第 5183 行 的startStreamingTranscription。它启动一个自循环的调度器scheduleNextStreamingChunk() └─ streamingTaskLifecycle.schedule(delay) └─ 延迟到期 ─ processStreamingChunk() └─ streamingChunkDidFinish() └─ 再次 scheduleNextStreamingChunk()这个跑完一块 → 重新排下一块的链式结构保证了串行不堆积同一时刻只有一个转写任务在跑schedule方法里guard self.scheduler nil, self.active nil确保不会开第二个调度器会话隔离每个任务都绑定sessionID旧会话的任务返回时若sessionID已变会被识别为迟到完成并安全丢弃超时排空停止录音时通过drain给进行中的任务一个截止时间默认 30 秒既不让它无限占用也不中途打断调度间隔来自所选模型的streamingPreviewIntervalSeconds见 第 1490 行即每多少秒出一次预览。增量转写只喂新增的音频每到一个周期processStreamingChunk第 5259 行执行核心逻辑。它有几个重要的防抖判断忙碌跳过若上一块还没转写完isProcessingChunk直接跳过本块防止队列堆积最短音频门槛多数模型至少需要 1 秒16000 个采样点音频才有效不够就等待增量 delta对 FluidAudio 这类支持增量的引擎只喂新增的 PCM而不是从头重喂整段音频大幅降低重复计算真正消费增量音频的是 ParakeetRealtimeProvider.swift 的consumeDelta第 179 行// 记录上次已喂到第几个采样点本次只取增量 let delta Array(samples.dropFirst(self.streamedSampleCount)) self.streamedSampleCount samples.count这种记住进度、只送增量的做法让转写引擎能像人一样接着听而不是每 500 毫秒把前面说的全部重听一遍。实时字幕上屏智能 diff 让文字不跳转写结果不能直接覆盖显示否则前文会频繁闪动。FluidVoice 用smartDiffUpdate第 5495 行做智能差异更新对新旧两版文字按词拆分比对只把真正新增的单词追加到末尾结果写入partialTranscription驱动 UI 刷新上屏前还会经过一道文本流水线第 5438 行去除填充词 → 应用自定义词典 → 应用口语标点格式化让实时字幕更接近干净的成文。最终partialTranscription作为ObservableObject的发布属性被订阅它的浮层视图如底部通知条、刘海区视图实时读取并渲染于是你看到的就是字幕随语音逐字增长的效果。收尾停止与善后当你停止录音流式转写并不会戛然而止。drainActiveStreamingWork第 5853 行会若调度器处于空闲没在转写直接同步返回零延迟若有真正在跑的转写给它一个截止时间等待完成确保最后一块音频不丢完成后会调用引擎的finish()得到最终完整文本并reset()清空增量状态为下一次录音做好准备。这套排空屏障保证了你说的话一定被完整记录一个字都不少。小结FluidVoice 的流式转写架构本质是一套精心编排的异步任务生命周期管理StreamingTaskLifecycle负责何时转串行 会话隔离 超时排空⚡增量 PCM 消费负责转多少只喂新增音频避免重复计算智能 diff 上屏负责如何显示让字幕平滑浮现不跳字三者配合实现了边说边出字的低延迟本地听写体验。若你想深入源码可从 ASRService.swift 的processStreamingChunk与 ParakeetRealtimeProvider.swift 两个文件入手配合 DirectAudioReliabilityTests.swift 中的生命周期测试用例能更快理解这套调度器在各种边界场景下的行为。【免费下载链接】FluidVoiceFastest and only macOS Dictation app with on-device STT and custom trained AI enhancement model. Windows pre-build available! A local Wispr Flow alternative. DM us on X exclusive model access! - https://x.com/fluidvoiceapp项目地址: https://gitcode.com/GitHub_Trending/fl/FluidVoice创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考