Skip to content

[audio] 支持可选的播放回声抑制，在保留系统声音的同时进行语音输入 #1223

Open
#1228
Open
[audio] 支持可选的播放回声抑制，在保留系统声音的同时进行语音输入#1223
#1228

Description

@chesha1
chesha1
opened on Oct 17, 2026

现象与使用场景

我希望在电脑播放视频时，同时使用 OpenLess 语音输入。目前遇到的问题是，视频中的人声也会混入识别结果。

我已经尝试了“录音时静音”，它确实会关闭系统声音，但这会打断观看体验，不符合我的需求。

希望增加一个可选设置，在系统声音继续正常播放的情况下，尽量抑制播放声音混入录音，让 ASR 主要识别我本人说的话。可以接受实际效果受设备和环境影响，不要求完全消除所有背景声音。

现有功能的不足

  • 关闭“录音时静音”可以同时播放和录音，但没有解决视频人声混入的问题。
  • “轻量麦克风增强”目前明确不包含回声消除。
  • 相关的 #269 关注录音期间暂停背景音频，本需求希望保留播放声音。

建议接受标准

  • 提供可选的回声消除或播放声音抑制功能，用户可以根据设备和实际效果开启或关闭。
  • 启用时，系统音量和媒体播放保持原状。
  • 在视频人声与本人讲话同时存在时，减少视频内容混入转写，并尽量保留本人讲话的完整性。
  • 说明支持的平台、设备条件及效果限制。

待确认信息

系统、OpenLess 版本、输入和输出设备待补充；目前尚未确认视频声音具体通过哪条音频路径进入录音。

Activity

  1. HKLHaoBin commented on Oct 17, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 17, 2026
    Collaborator

    先前没有实现回声抑制功能，原因有两点：第一，它的性能消耗比较大；第二，它需要的依赖更多，实现也更复杂。因此，为了那个 PR，我做了两点考虑：一是缩小它的职责范围，二是让 PR 更好维护、更好合并。所以最终没有做回声抑制。不过，既然你需要，我可以尝试为你开发一个。

  2. chesha1 commented on Oct 17, 2026

    @chesha1
    chesha1
    on Oct 17, 2026
    Author

    再提供一个信息，我在转到 OpenLess 之前用的竞品是闪电说，他们有这个功能。在看视频放着背景语音的时候，也可以实现语音输入，而且没有像现在的 OpenLess 一样把系统输出给关掉，也没有把背景说话的音识别出来，效果非常好，不知道他们是怎么实现的，可惜他们好像是闭源的

  3. HKLHaoBin commented on Oct 18, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 18, 2026
    Collaborator

    @chesha1 播放回声抑制功能已完成，PR 已提交：
    #1228

    请协助使用真实硬件测试 issue 中的场景：播放视频/背景语音时保持系统声音可听，同时进行语音输入，并确认背景人声不会被识别、自己的近端语音仍能正常识别。

    已通过的构建与产物 Action：

    请从对应 Action 页面下载产物进行测试，并反馈操作系统、音频设备/路由、播放内容、是否启用 Playback echo cancellation、测试结果及异常。该功能是 best effort，蓝牙、驱动、受保护内容、Linux ALSA 和输出路由限制可能会回退到普通麦克风录音。

  4. chesha1 commented on Oct 18, 2026

    @chesha1
    chesha1
    on Oct 18, 2026
    Author

    在Windows下试用没什么问题。在背景有视频人声播放的时候，大致还能正常使用

  5. chesha1 commented on Oct 18, 2026

    @chesha1
    chesha1
    on Oct 18, 2026
    Author

    等一下，好像出了点问题，现在特别容易出现这个，我找找日志

    Image

  6. chesha1 commented on Oct 18, 2026

    @chesha1
    chesha1
    on Oct 18, 2026
    Author

    @HKLHaoBin 使用本 issue 提供的回声消除开发测试包时，遇到了「原本可以正常使用，随后连续录音启动失败」的问题，想请你帮忙看一下。

    以下反馈由 AI 根据我提供的真实原始日志，以及对应构建提交的源码辅助生成。 日志中的现象与源码分析已分开列出；原因分析仍是待验证假设，未经开发者确认，请审阅。悬浮窗里的错误被截断，无法完整看到，因此把原始日志和关键片段一并提供。

    测试包与设备

    • 测试包来源：本 issue 中的开发包回复，关联 PR feat(audio): add optional playback echo cancellation #1228。
    • 构建记录：Actions run 39082199143。
    • 提交：5519c6e2434eb276638485c56f1ea97c66f7b6f0，分支 feat/issue-1223-echo-cancellation。
    • 该提交源码声明的版本：2.0.2-Beta.1+build.20261017。原始日志没有记录版本号，版本对应关系来自我确认的开发包来源与构建信息。
    • 平台：Windows，具体系统版本和音频驱动版本未在这份日志中确认。
    • 输入：麦克风 (2- USB Audio Device)，48000 Hz / 2 channels / F32。
    • 回声参考输出设备：扬声器 (HECATE G1500 BAR)，同样为 48000 Hz / 2 channels / F32。

    日志里能确认的现象

    原始日志时间带 Z，为 UTC；下表另列北京时间（UTC+8），日期均为 2026-10-18。文件还包含 10 月 17 日的历史记录；这里聚焦 10 月 18 日的故障段，不将所有历史记录都归属于同一测试包。

    UTC 北京时间 日志现象
    07:04:30 起 15:04:30 起 首次观察到主麦克风 stream error: A buffer underrun or overrun occurred.；再次启动前累计 15 次同类错误。
    08:57:28 16:57:28 出现热键线程退出记录。
    09:09:22 17:09:22 再次出现 === OpenLess 启动 ===。
    再次启动后至 09:51:45 再次启动后至 17:51:45 共 19 次 phase=completed outcome=PasteSent，说明这段时间输入能够完成。
    09:51:59–09:55:16 17:51:59–17:55:16 连续 11 次同类主麦克风流错误，随后取消录音；日志末尾未看到恢复成功。

    全文件共 26 次 [recorder] stream error。这里统计的是日志事件次数；「19 次成功」以 PasteSent 完成事件计数，不代表验证了每次插入内容的准确性。重新启动后曾恢复一段时间，但尚无稳定复现步骤。

    两段关键原始日志

    1. 最后一轮连续失败的开始（原文件第 8702–8712 行）

    2026-10-18T09:51:59.557663Z [INFO] [hotkey] Windows trigger pressed vk=165
2026-10-18T09:51:59.5701262Z [INFO] [recorder] echo reference outputDevice=扬声器 (HECATE G1500 BAR) sampleRate=48000 channels=2 fmt=F32
2026-10-18T09:51:59.5741775Z [WARN] [recorder] echo reference stream stopped: A buffer underrun or overrun occurred.
2026-10-18T09:51:59.5814573Z [INFO] [recorder] inputDevice=麦克风 (2- USB Audio Device) inputFormat sampleRate=48000 channels=2 fmt=F32
2026-10-18T09:51:59.5942793Z [ERROR] [recorder] stream error: A buffer underrun or overrun occurred.
2026-10-18T09:51:59.6296586Z [INFO] [hotkey] Windows trigger released vk=165
2026-10-18T09:51:59.8864775Z [INFO] [recorder] echo reference stream dropped
2026-10-18T09:51:59.8865258Z [INFO] [recorder] cpal Stream dropped (mic released)
2026-10-18T09:51:59.8867311Z [INFO] [recorder] audio processor stopped (accepted frames drained)
2026-10-18T09:51:59.8894501Z [INFO] [insert-diagnostics] session_id=980bdb37-216f-4c95-adfe-3f8f7a53f134 operation=cancel attempts=0 result=Ok(())
2026-10-18T09:51:59.9345478Z [WARN] [coord] core dictation press failed: voice capture was cancelled

    2. 后续没有出现回声参考流启动记录的一次失败（原文件第 8724–8731 行）

    2026-10-18T09:52:12.3048036Z [INFO] [hotkey] Windows trigger pressed vk=165
2026-10-18T09:52:12.3175629Z [INFO] [recorder] inputDevice=麦克风 (2- USB Audio Device) inputFormat sampleRate=48000 channels=2 fmt=F32
2026-10-18T09:52:12.3303526Z [ERROR] [recorder] stream error: A buffer underrun or overrun occurred.
2026-10-18T09:52:12.3827672Z [INFO] [hotkey] Windows trigger released vk=165
2026-10-18T09:52:12.5199935Z [INFO] [recorder] cpal Stream dropped (mic released)
2026-10-18T09:52:12.5201137Z [INFO] [recorder] audio processor stopped (accepted frames drained)
2026-10-18T09:52:12.5228056Z [INFO] [insert-diagnostics] session_id=6316e0e7-57e7-45ba-a73c-de233d987cf0 operation=cancel attempts=0 result=Ok(())
2026-10-18T09:52:12.6805007Z [WARN] [coord] core dictation press failed: voice capture was cancelled

    第二段只能证明该次日志中没有参考流启动记录，不能单凭它确认设置开关状态。失败链路首先出现在本地音频采集；voice capture was cancelled 是后续取消结果，不能作为最初错误原因。

    源码排查假设，请开发者确认

    优先怀疑 CPAL 升级后，新增的缓冲异常通知被统一当作致命录音故障处理。 本次 PR 将 CPAL 从 0.15.3 升到 0.18.2；测试包提交中的 Cargo.toml 第 78–80 行 明确使用 0.18.2。CPAL 0.18.2 更新记录也列出了新增的 WASAPI capture Xrun 通知。

    1. CPAL 0.18.2 的 WASAPI 采集路径在检测到 AUDCLNT_BUFFERFLAGS_DATA_DISCONTINUITY 时通过错误回调发出 ErrorKind::Xrun，随后仍会走到数据回调。也就是说，这个事件本身不等同于底层音频流已永久停止。CPAL 源码第 819–855 行
    2. 测试包的主麦克风错误回调在 accepting_audio 为真时，将收到的流错误统一包装为 RecorderError::EngineFailed，没有单独区分 Xrun。recorder.rs 第 1804–1812 行
    3. 运行时错误随后被映射并上报为 RecordingEvent::Fatal，调用 report_recording_fault。core_adapters.rs 第 2777–2794 行

    这条代码路径与「缓冲异常 → 流释放 → 录音取消」的日志顺序吻合，但尚不能证明缓冲异常最初由什么触发，也不能排除 USB 设备、驱动、系统调度或程序负载的影响。关闭回声消除也不会回退底层 CPAL 版本，因此仅切换该开关未必能隔离这类兼容问题。

    另外有两点容易误判：

    • echo reference stream stopped 对应的错误回调实际只执行 log::warn!，没有在该回调中停止或销毁参考流。最后一次成功输入也出现过同样警告，因此不能把这条文案直接视为参考流已停止，更不能单独据此认定 AEC 导致录音失败。recorder.rs 第 1948–1950 行
    • CPAL 0.18.2 已有 device_position != 0 的首包保护。虽然错误多发生在启动附近，现有证据不足以断言是「首包 discontinuity 被误报」的已知问题；仍需记录实际位置和标志验证。

    希望协助检查

    • 是否应对 Xrun 单独分类，在确认数据回调仍正常时记录告警和计数，而不是立即取消整次录音；对持续断流、设备失效等情况保留恢复或失败处理。
    • 能否在测试包里增加 err.kind()、设备、采样格式、首次/最近数据回调时间及异常计数，帮助判断启动瞬间异常与持续无法采集的区别。
    • 如需对照验证，可在相同设备上比较本开发包、原版本，以及 AEC 开/关。当前尚未完成这些对照，不能宣称原因已经证实。
    • 能否让悬浮窗错误支持展开或复制，并保留最初音频错误，而不仅显示后续的「录音已取消」；导出日志同时记录完整版本/提交也会有帮助。

    完整原始日志与摘录

    原始日志附件将由我随后手动上传到本 issue。已准备好 openless-1223-logs.zip，内含：

    • openless-2026-10-18T09-56-30.log：完整原始日志源文件。
    • openless-recording-failure-excerpt.log：关键日志摘录及原文件行号。

    完整日志为用户导出的源文件，大小 1,795,830 字节，SHA-256：

    673ae8bfb17b4c352918695ba2731133a7332f9d2e16eb017376553e83fdfb26

    摘录仅用于快速定位，包含对应原文件行号；完整上下文请以原始日志为准。麻烦帮忙看一下上述错误处理方向是否合理，谢谢。

  7. chesha1 commented on Oct 18, 2026

    @chesha1
    chesha1
    on Oct 18, 2026
    Author

    openless-1223-logs.zip

  8. HKLHaoBin commented on Oct 18, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 18, 2026
    Collaborator

    请从以下 GitHub Actions 页面下载测试包，协助验证本 issue 的播放回声抑制场景。以下构建均已完成且成功，来自分支 feat/issue-1223-echo-cancellation、提交 5519c6e2434eb276638485c56f1ea97c66f7b6f0：

    请优先使用 Windows 或 macOS 桌面端测试：

    1. 保持系统媒体声音正常播放；
    2. 开启 Playback echo cancellation，播放包含人声的视频或背景语音，并连续进行多次语音输入；
    3. 确认背景人声是否减少、自己的讲话是否仍能完整识别，以及是否出现连续录音启动失败；
    4. 如方便，再关闭该设置进行同设备对照。

    反馈时请注明：操作系统、OpenLess 版本、输入设备、输出设备/音频路由、播放内容类型、AEC 开关状态、测试次数、识别效果和是否出现错误。若再次出现录音启动失败，请保留并上传完整应用日志，特别是最初的 [recorder] stream error，不要只提供后续的“录音已取消”提示。该功能目前是 best effort，蓝牙、驱动、受保护内容和部分输出路由可能回退为普通麦克风录音。

  9. HKLHaoBin commented on Oct 18, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 18, 2026
    Collaborator

    这个产物并不负责解决问题，而是收集问题。所以报错是在预期范围内的。

  10. chesha1 commented on Oct 19, 2026

    @chesha1
    chesha1
    on Oct 19, 2026
    Author

    用这个新的构建产物，不知道为啥，现在我不能复现原来的报错了。你有什么建议能让这个错误更容易出现一点吗？

  11. chesha1 commented on Oct 19, 2026

    @chesha1
    chesha1
    on Oct 19, 2026
    Author

    @HKLHaoBin 补充更新：之前低频试用时暂时无法复现，继续使用和尝试后，现在又复现了原来的报错。

    目前还不能确定是哪一步操作触发的，也没有整理出稳定的复现步骤，因此前面“暂时无法复现”的反馈不能视为问题已经消失。

    这次的录音诊断事件和故障摘录已经整理成 openless-1223-repro-20261020.zip，我会随后在网页端手动上传，供进一步分析。该附件是诊断摘录，完整原始日志也已在本地保留。

  12. chesha1 commented on Oct 19, 2026

    @chesha1
    chesha1
    on Oct 19, 2026
    Author

    openless-1223-repro-20261020.zip

  13. HKLHaoBin commented on Oct 20, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 20, 2026
    Collaborator

    @chesha1 感谢补充复现日志。我核对了这次附件：本次启动后有 17 次 PasteSent 完成事件，随后连续 4 次出现主麦克风 A buffer underrun or overrun occurred.，接着释放流并取消录音。暂时无法复现不能视为故障消失；目前也不能直接断言是 AEC 算法导致了这些缓冲异常。

    这次准备了一个新的诊断包，用于确认具体 CPAL 错误类别，以及错误之后是否仍有音频数据回调。它还不是修复版，原有错误处理行为保持不变，因此仍可能报错。

    请使用本次新包，不要重复下载旧包

    分支：feat/issue-1223-echo-cancellation
    提交：986526faa741061d0066cf1607c04cad6818f0a6

    以下 Actions 均已成功，并已核验产物存在且未过期：

    版本号仍可能显示为 2.0.2-Beta.1+build.20261017，不能仅凭版本号区分新旧包。请确认来自上述本次 Actions；新包运行后应能在日志中找到 [DEBUG-ISSUE1223]。

    请你复现 bug

    1. 完全退出旧 OpenLess，包括托盘中的后台进程；安装并启动上面的 Windows 新诊断包。
    2. 保持与之前相同的 USB 麦克风和 HECATE 输出设备，沿用平时播放视频/背景人声并语音输入的使用方式。先确认日志中出现 [DEBUG-ISSUE1223]；如果没有，请反馈，不要把旧包日志当成本次诊断结果。
    3. 先在 AEC 开启时使用，记录播放内容类型、输入/输出设备、是否开启低延迟录音以及错误发生的时间。如要做 AEC 关闭对照，请单独记录切换时间，不要把两组结果混在一起。不需要故意制造高负载或修改系统音频驱动。
    4. 出现原来的录音失败后，保留最初错误及前后的日志。如果始终未复现，也请说明实际使用时长和大致录音次数；一次暂时成功不等于已修复。
    5. 请从日志中提供所有 [DEBUG-ISSUE1223] 行，以及失败前后相关的 recorder/watchdog/取消/完成事件，保留原始时间和顺序；压缩上传到本 issue。完整原始日志请先在本地保留，不要清空。上传前请检查并去除转写正文、密钥等敏感内容。

    新探针为：P1（AEC 请求与参考流建立结果）、P2（主麦克风错误类别/计数）、P3（参考流错误类别/计数）、P4（队列或 watchdog 故障）、P5（首次/错误后的下一次数据回调）。不是每次都会出现所有探针；请提供实际出现的全部事件，不用补造缺失行。尤其需要同一 run_id 下的 P2 与后续 P5，才能判断 xrun 后数据是否仍在到达。收到这些证据后再验证针对性的修复。

  14. chesha1 commented on Oct 20, 2026

    @chesha1
    chesha1
    on Oct 20, 2026
    Author

    @HKLHaoBin 已安装你上一条回复中的新诊断包，并再次触发了原来的录音失败。这次日志已确认出现 [DEBUG-ISSUE1223]，也捕获到了你需要的同一 run_id 下 P2 → P5 记录。

    以下反馈由 AI 根据本机实际日志辅助整理。日志事实与尚未确认的原因分开列出，请协助审阅。

    设备与诊断范围

    • 平台：Windows。
    • 输入：麦克风 (2- USB Audio Device)；参考输出：扬声器 (HECATE G1500 BAR)；两者均为 48000 Hz / 2 channels / F32。
    • 这次带诊断标志的 10 个 capture 中，P1 均为 aec_requested=true、reference_available=true。本次没有 AEC 关闭对照。
    • 低延迟录音开关、当时播放内容类型和具体触发步骤，暂未确认，不从日志推断。
    • 统计限定于 2026-10-20 的新诊断记录；原文件还含更早的历史日志，没有把它们混入本次统计。

    已捕获的结果

    共 45 条 [DEBUG-ISSUE1223]，覆盖 10 个 run_id：P1=10、P2=5、P3=10、P5=20；没有 P4。

    5 次 P2 主麦克风错误均为 error_kind="xrun"，且每次随后都有同一 run_id、stream_role="microphone" 的 P5：outcome="after_error"、callback_count=1、error_count=1、frames=480。之后均出现流释放及 voice capture was cancelled。

    错误时间如下，日期均为 2026-10-20：

    run_id UTC 北京时间（UTC+8）
    pid-21904-capture-1 04:08:06 12:08:06
    pid-21904-capture-2 04:08:12 12:08:12
    pid-21904-capture-3 04:08:14 12:08:14
    pid-6216-capture-6 12:03:03 20:03:03
    pid-6216-capture-7 12:03:16 20:03:16

    这段诊断记录期间另有 5 个 phase=completed outcome=PasteSent 完成事件。这只是事件计数，不代表验证了每次转写的准确性，也不能把上述时间跨度视为连续测试时长。

    下面是 20:03:03 那次的关键原始行（中间有省略，完整诊断顺序见待上传附件；时间戳为 UTC）：

    2026-10-20T12:03:03.7217455Z [INFO] [DEBUG-ISSUE1223] {"schema":"diagnosing-bugs.v1","session_id":"s1223-20261019","run_id":"pid-6216-capture-6","probe_id":"P2","hypothesis_ids":["H1","H2","H3"],"event":"microphone_stream_error","outcome":"xrun_candidate","safe":{"stream_role":"microphone","error_kind":"xrun","accepting_audio":true,"error_count":1,"callback_count":0},"ts":1792497783721}
2026-10-20T12:03:03.7218722Z [ERROR] [recorder] stream error: A buffer underrun or overrun occurred.
2026-10-20T12:03:03.7219274Z [INFO] [DEBUG-ISSUE1223] {"schema":"diagnosing-bugs.v1","session_id":"s1223-20261019","run_id":"pid-6216-capture-6","probe_id":"P5","hypothesis_ids":["H1","H2","H3"],"event":"data_callback","outcome":"after_error","safe":{"stream_role":"microphone","accepting_audio":true,"callback_count":1,"error_count":1,"frames":480},"ts":1792497783721}
2026-10-20T12:03:04.0872604Z [WARN] [coord] core dictation press failed: voice capture was cancelled

    这些记录确认了 xrun 错误之后仍有麦克风数据回调到达，随后本次录音被取消。目前仍不能仅凭这些记录确定最初是什么触发了 xrun，也没有据此认定 AEC 算法或音频驱动是根因。请看看这些 P2/P5 证据是否足以继续验证针对性的错误处理修复。

    附件

    已准备 openless-1223-debug-20261020.zip，我会随后在网页端手动上传到本 issue。压缩包包含：

    • openless-1223-diagnostic-timeline.log：全部 45 条诊断标志，以及相关录音、取消、完成和热键触发记录，共 159 条，保留原始时间、顺序和源文件行号。
    • manifest.json：统计范围、计数及 SHA-256，便于核对。

    附件仅含诊断摘录，已核对未包含转写正文或密钥。完整原始日志已在本地保留，不包含在该压缩包内。

  15. chesha1 commented on Oct 20, 2026

    @chesha1
    chesha1
    on Oct 20, 2026
    Author

    openless-1223-debug-20261020.zip

  16. HKLHaoBin commented on Oct 20, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 20, 2026
    Collaborator

    @chesha1 已核验你这次附件的 SHA-256 与 P2→P5 顺序。5 次主麦克风 xrun 后都仍有非空数据回调，证据足以支持一次针对性的修复验证：CPAL Xrun 不再立即上报为 Fatal 并取消录音，而是记录警告后继续接收音频。 设备失效等其他错误仍走原来的失败路径，无数据回调 watchdog 也保留原阈值；xrun 不会刷新其时间戳，因此不会用该改动掩盖真正断流。

    修复已通过 Review Bugbot，结论为 No bugs found。提交：8005a171ec476ba26c7241cb4f809be5ff7a85b5，分支 feat/issue-1223-echo-cancellation。

    新修复测试包（不是上一轮仅加日志的诊断包）

    桌面端 Action 完整链接：
    https://github.com/HKLHaoBin/openless/actions/runs/39467293641

    Windows、macOS ARM/Intel 构建均已成功，以下安装包已上传且未过期：

    请下载对应安装包 artifact，不要选仅包含签名或更新元数据的 -updater 包。GitHub 下载 Actions 产物可能需要登录。

    Windows recorder 模块测试已通过；CI 中其他平台的 macOS checks 被标为 cancelled，整轮 CI 尚未全绿，我会继续查日志并补跑。这不影响上述桌面安装包已经构建成功，但尚不能宣称原设备问题已彻底解决。

    请你用修复版复现 bug

    1. 完全退出旧版本（包括托盘后台进程），从上述本次 Action 安装并启动修复版。版本号可能仍相同，请以 Action/提交为准。
    2. 保持原 USB 麦克风、HECATE 输出设备和之前的视频/背景人声使用场景；先保持 AEC 开启。记录低延迟录音开关、播放内容类型、大致使用时长与录音次数。如果关闭 AEC 作对照，请分别记录切换时间和结果。
    3. 再次触发原来的条件。修复版若出现 xrun，P2 的 outcome 应为 xrun_recoverable，并应有后续同 run_id 的 P5 数据回调，不再仅因这次 xrun 就立刻取消录音。还请确认能完成转写/输入、本人讲话是否完整、系统播放是否保持正常。
    4. 无论再次失败还是正常，请保留这轮 [DEBUG-ISSUE1223] 全部事件，以及附近的 recorder/watchdog/取消/完成事件和时间顺序，压缩后发到本 issue。若一直没再触发 xrun，请说明实际使用情况；这只能说明暂未复现，不等于已验证该恢复分支。
    5. 完整原始日志请在本地保留，不要清空；公开上传前检查并去除转写正文、密钥等敏感内容。现有诊断探针会保留到修复效果确认后再清理。

  17. HKLHaoBin commented on Oct 20, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 20, 2026
    Collaborator

    @chesha1 补充自动验证结果：修复代码未变，后续提交 9d34723c1a128c869bfe7b20b8da9771161f362c 仅增加 CI 手动选择 Intel macOS runner 的回退及契约测试，也经 Review Bugbot 审查无 Bug。

    复测请继续使用上一条评论提供的 8005a171 修复包，该提交 Windows、macOS ARM/Intel 三种桌面包均已构建成功，产物仍未过期，且音频修复代码与最新提交一致：

    https://github.com/HKLHaoBin/openless/actions/runs/39467293641

    Windows 安装包直达：https://github.com/HKLHaoBin/openless/actions/runs/39467293641/artifacts/12286184559

    仍需原设备上的 xrun_recoverable → 后续数据回调 → 正常完成录音/输入的日志验证，自动测试通过不等于已确认硬件症状消失。无需为本轮 CI 更新重复安装；复测和隐私检查要求沿用上一条评论。

  18. chesha1 commented on Oct 22, 2026

    @chesha1
    chesha1
    on Oct 22, 2026
    Author

    经过两天的试用，这次的构建产物不会再出现录音报错的情况了，好像出现过一次，但那次只是悬浮窗有一个报错，没有影响正常使用

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions