Repository navigation
[recording] macOS 录音提示音与试听在多次听写后静音，重启后恢复 #934
Description
Activity
@appergb 你有Mac你来解决这个问题
ok
骗你的，其实我也有这个问题，修了几次都修不好。
已完成根因定位与逻辑验证，正在继续集成测试。
根因不是设置状态，也不只是 closed / suspended / interrupted。现有两轮恢复逻辑仍信任 AudioContext.state 等于 running；但 WebKit 存在状态仍为 running、currentTime 仍前进、实际输出已永久静音的退化态。OpenLess 的全局热键长期在后台或其他 App 中使用，正好会让这个长期复用的单例 context 命中该路径，因此开始提示音与设置页试听会一起静音，且之前按 state 重建的修复无法触发。
修复策略：保留预热 context 供首次播放使用；一个 context 一旦排期过提示音，下一次播放就主动丢弃并新建，不再仅依赖 state 判断健康度。这样每次后续听写或试听都会从新的输出 context 开始，同时保留原有 resume、迟到丢弃和单次重试逻辑。
逻辑验证已完成：
- 新增 12 轮真实 playRecordStartCue / stopAudioCue 生命周期回归测试；旧逻辑稳定失败：期望 12 个 context，实际仅 1 个。
- 应用修复后，同一测试验证 12 轮均排期成功，共 24 个 oscillator，且使用 12 个 context。
- 原有 audioCue.test.ts 状态分类和恢复决策测试继续通过。
接下来按计划执行完整前端测试、TypeScript/Vite 生产构建，并检查最终影响范围。
集成验证结果更新：
- npm run build 通过：TypeScript 与 Vite 生产构建成功。
- 除 Rust 热键注入门禁外，其余 43/43 个前端与契约测试全部通过；其中包含新增 audioCueLifecycle.test.ts，验证 12 轮提示音共排期 24 个 oscillator、创建 12 个 context，并关闭被替换的 11 个旧 context，避免资源泄漏。
- 原有 audioCue.test.ts 全部通过。
- GitNexus 最终变更映射为 low risk，生产改动只落在 audioCue.ts；录音状态机、设置存储、IPC 与 Rust 代码均未修改。
未完成项：完整 npm test 中的 scripts/check-hotkey-injection.mjs 会首次全量编译 Rust/Tauri，已在补齐 qwen-asr 子模块后重试，但本机仅剩约 2.2 GiB 空间，编译以 No space left on device 退出。该门禁与本次纯前端音频 context 生命周期改动无直接关系；失败发生在编译依赖阶段，未进入测试断言。
真实 macOS 26.6.1 上连续 15 分钟及至少 10 次听写的听感验收仍需用包含此补丁的安装包执行。自动化逻辑与前端集成路径现已验证。
Reacted by ab76所以到底修好没 @appergb
@appergb 想确认一下这个还在跟吗？看 beta 上
audioCue.ts自 8-10 之后没有相关改动，也没找到对应 PR。我这边是 macOS 26 / Apple M5，可以跑源码版做实机复现和长时间验证。如果你已经不在跟，我可以接手：沿用你 8-10 定位的根因（WebKit 下
AudioContext.state仍为 running 但输出已静音），先按 issue 里的步骤复现，再按「排期过提示音的 context 下次播放即替换」的思路提 PR，署上你的分析。如果你手上已经有分支，也可以直接推上来，我帮忙在真机上测。好的
现象
环境
复现步骤
当前表现
已核对的源码事实
在 v1.3.16 中：
playRecordStartCue()。AudioCueListener在capsule:state进入recording状态时调用同一个playRecordStartCue()。相关文件：
openless-all/app/src/lib/audioCue.tsopenless-all/app/src/components/AudioCue.tsxopenless-all/app/src/pages/settings/RecordingInputSection.tsx影响
建议接受标准
TODO / 不确定项