Skip to content

功能建议：用语音替代按键来激活输入法 #1003

Open
Open
功能建议：用语音替代按键来激活输入法#1003

Description

@lededev
lededev
opened on Aug 26, 2026

按键占手还容易疲劳，希望能支持类似：

开始文字录入
（要转为文字的语音）
完成文字录入（或等待超时）

用录入这个关键词是因为比较书面，和日常口语不容易碰撞导致误激活，可自定义和本地识别更佳。

Activity

  1. HKLHaoBin commented on Aug 27, 2026

    @HKLHaoBin
    HKLHaoBin
    on Aug 27, 2026
    Collaborator

    也不是不能做，但我目前用不上这个功能。不知道哪位贡献者会需要这个功能并贡献代码。

  2. lededev commented on Aug 27, 2026

    @lededev
    lededev
    on Aug 27, 2026
    ContributorAuthor

    右Ctrl被占用很影响我的使用习惯，Ctrl+A Ctrl+C Ctrl+V这种形成肌肉记忆的操作失败让人抓狂，目前我的折衷方法是将默认键改为了ScrLock，按一下亮灯就是语音输入，按灭就停止并发送。

  3. HKLHaoBin commented on Aug 27, 2026

    @HKLHaoBin
    HKLHaoBin
    on Aug 27, 2026
    Collaborator

    因为我使用的是罗技鼠标，所以选择用侧键来激活。我采用的是最稳定的方式：这个软件支持加后缀，可以创建一个快捷方式，指向 Openless 软件本体路径并附加特定后缀(比如 F:\OpenLess\openless.exe --toggle-dictation），即可直接激活听写功能。这种底层实现方式不依赖任何快捷键，只需配置好罗技的配置文件即可。所以对我来说，目前没有太大影响。

  4. appergb commented on Sep 9, 2026

    @appergb
    appergb
    on Sep 9, 2026
    Collaborator

    eeeee 你有没有想过，如果增加这个功能——麦克风全天开启——第一是耗电问题，第二是你准备怎么解决它持续的性能占用问题，以及占用麦克风的问题呢？在 Windows 端，麦克风被占用后，其他 App 再去使用麦克风是比较困难的。

  5. linonetwo commented on Sep 14, 2026

    @linonetwo
    linonetwo
    on Sep 14, 2026

    既然要用语音，那你就全天开着就好了。你用开源的语音会议转录软件，你可以先做Demo。你看看全天开着对性能和输入占用的影响怎么样。然后再考虑把它简化，放回语音输入法。比如 https://github.com/Longt-audio/voxminutes 这个，我用的不多，就之前玩游戏的时候开了一次，它可以一直常驻后台。不过我没试过我也要说语音的时候会不会互相挤占，当时只是用它听游戏里面的对话。

  6. HKLHaoBin commented on Oct 13, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 13, 2026
    Collaborator

    我看一下 Windows 能不能支持吧。

  7. HKLHaoBin commented on Oct 14, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 14, 2026
    Collaborator

    语音激活模型引导更新（65afa352）

    语音激活设置中的模型缺失引导已经加入，代码位于分支 feat/issue-1003-voice-activation，最新提交为 65afa352。本次 Bugbot 复审结果为 No bugs found。

    工作流与 Windows 产物

    下载方式：打开上面的 Release Tauri workflow run，在页面底部 Artifacts 区域下载 openless-windows-x64，解压后运行 nsis/OpenLess_2.0.0-Beta.4+build.20260930_x64-setup.exe。这是未签名的测试构建，Windows SmartScreen 可能显示“未识别的发布者”。

    请重点测试模型缺失引导

    1. 在 Windows 桌面端打开设置 → 录音输入，启用“语音激活”。
    2. 在尚未准备本地 Zipformer 时，确认出现“本地 Zipformer 模型未安装”的提示和“前往 AI 服务与模型下载 Zipformer”按钮。
    3. 点击按钮，确认直接进入 AI 服务与模型 → 本地模型，并能看到 zipformer-bilingual-zh-en-streaming；点击跳转本身不应自动开始下载。
    4. 在本地模型页下载并准备 Zipformer，返回录音设置或重新配置语音激活，确认模型缺失提示消失，并进入等待唤醒状态。
    5. 说“开始语音录入”，说一段正文，再说“完成语音录入”，确认正文被插入且唤醒词/结束词不会进入正文；也请测试超时自动结束。
    6. 在 multimodal pipeline 下重复第 3 步，确认仍然能直接打开本地模型页。
    7. 权限拒绝、麦克风占用和其他普通运行时错误不应显示 Zipformer 下载按钮；原有热键/切换录音入口应保持可用。

    如果发现问题，请附上 Windows 版本、是否已准备 Zipformer、语音激活状态提示文本以及复现步骤。

  8. lededev commented on Oct 16, 2026

    @lededev
    lededev
    on Oct 16, 2026
    ContributorAuthor

    用语音控制启停均正常，不过停止时的断句，导致停止指令也被混入正文的情况时有出现。例如结束指令中间被加上逗号了。
    “完成，语音录入。”

  9. HKLHaoBin commented on Oct 16, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 16, 2026
    Collaborator

    好的 我将会及时修复这个问题。

  10. lededev commented on Oct 16, 2026

    @lededev
    lededev
    on Oct 16, 2026
    ContributorAuthor

    建议加个人声静音检测做前置过滤，没检测到人声时不要把音频交给Zipformer进行识别，否则CPU持续占用率有点高。

  11. HKLHaoBin commented on Oct 16, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 16, 2026
    Collaborator

    10. 建议加个人声静音检测做前置过滤，没检测到人声时不要把音频交给Zipformer进行识别，否则CPU持续占用率有点高。

    但你要知道，你不仅要加载一个本地的语音识别模型，还要加载一个人声模型。事实上，这不会让 CPU 的占用率变低，反而会更高。

  12. HKLHaoBin commented on Oct 16, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 16, 2026
    Collaborator

    比如你电脑的音乐声。很可能就会达到识别的门槛，然后交给 Zipformer 去进行识别。

  13. lededev commented on Oct 16, 2026

    @lededev
    lededev
    on Oct 16, 2026
    ContributorAuthor

    人声静音检测不需要大模型，用FFT做三阶高通级联状态滤波就行了，几乎不消耗CPU。

  14. lededev commented on Oct 16, 2026

    @lededev
    lededev
    on Oct 16, 2026
    ContributorAuthor

    放音乐的时候，肯定没必要开着语音录入吧。

  15. lededev commented on Oct 16, 2026

    @lededev
    lededev
    on Oct 16, 2026
    ContributorAuthor

    我让Qwen3.8-27b本地AI搓了个人声静音检测的例子，检测到四个字以上的人声之后回调，供参考

    vad-dll.zip

    。

  16. 7 remaining items

  17. HKLHaoBin commented on Oct 18, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 18, 2026
    Collaborator

    @
    Issue #1003 的评论需求修复已完成，以下是对应 GitHub Actions 构建结果，请进一步测试：

    测试重点：说完唤醒词后立即停顿、说完结束词后立即停顿，以及唤醒词后紧接着说正文时是否仍会丢失首段语音。若仍有问题，请附上复现步骤、平台和录屏/日志。

    测试分支：HKLHaoBin/1003-voice-activation
    提交：e40a3c271b8c7ef826f93b7a30d58416169d4a5b
    @

  18. lededev commented on Oct 19, 2026

    @lededev
    lededev
    on Oct 19, 2026
    ContributorAuthor

    现在录音与输入里的选项有点多，需要一个参考设置，测试在同一个基准下，才容易复现。

  19. lededev commented on Oct 19, 2026

    @lededev
    lededev
    on Oct 19, 2026
    ContributorAuthor

    现在依然是说完唤醒词之后不能停下等确认提示音，需要继续说话，提示音才会触发。
    遇到一次程序崩溃，发生在说完结束词不久。
    vs2026看到的调用堆栈：

    [0x00007FF93D97D5F9 (ntdll.dll) (openless.exe 中)处有未经处理的异常: 0xC0000374: 堆已损坏。 (参数: 0x00007FF93D9F48B0)。]	
>	ntdll.dll!00007ff93d97d5f9()	未知
ntdll.dll!00007ff93d97d5c3()	未知
ntdll.dll!00007ff93d98665a()	未知
ntdll.dll!00007ff93d98693a()	未知
ntdll.dll!00007ff93d992935()	未知
ntdll.dll!00007ff93d8aa34c()	未知
ntdll.dll!00007ff93d8ac374()	未知
ntdll.dll!00007ff93d8ab041()	未知
ntdll.dll!00007ff93d8b7cab()	未知
ntdll.dll!00007ff93d8b7b44()	未知
ntdll.dll!00007ff93d91dc96()	未知
ntdll.dll!00007ff93d8ab041()	未知
openless.exe!00007ff719e6d880()	未知
openless.exe!00007ff71a18d4b9()	未知
openless.exe!00007ff71a3828cd()	未知
openless.exe!00007ff71a471c99()	未知
openless.exe!00007ff71a2434e4()	未知
openless.exe!00007ff71a22826d()	未知
openless.exe!00007ff71a179394()	未知
openless.exe!00007ff71a997601()	未知
openless.exe!00007ff71bb2b401()	未知
openless.exe!00007ff71bb2f84c()	未知
openless.exe!00007ff71bb17c6f()	未知
openless.exe!00007ff71bb15c08()	未知
openless.exe!00007ff71bb1c197()	未知
openless.exe!00007ff71ba11a07()	未知
kernel32.dll!00007ff93bc3259d()	未知
ntdll.dll!00007ff93d8caf78()	未知
  20. HKLHaoBin
    added a commit that references this issue on Oct 19, 2026

    chore: instrument voice activation diagnosis

    e4660dc

  21. HKLHaoBin commented on Oct 19, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 19, 2026
    Collaborator

    @lededev 针对 #1003 (comment) 中的唤醒延迟和结束词后崩溃，Windows 诊断包现已构建成功，可开始测试。本轮用于收集证据，没有行为修复，尚不能宣称问题已解决。

    可立即测试的诊断包

    • 下载：openless-windows-x64（下载 Actions 产物通常需要登录 GitHub）
    • 对应构建：https://github.com/HKLHaoBin/openless/actions/runs/39205861741 ，已成功；Windows EXE/PDB 存在性检查和上传均通过。
    • 精确源码提交：73e39abcd8b1d54377bd3e0b508c9d16a42cb65c。
    • 产物 ZIP 的 GitHub SHA-256：6d31f2e62100d3b68fbb389523d0073dcf7cb609a45f858355285f49959957eb（不是 ZIP 内安装器的哈希）。
    • 包内含安装器、匹配的 openless.exe / openless.pdb，以及 P1–P6 诊断探针。

    首次 CI 的独立 recorder 测试工程缺少 JSON 依赖，已补齐。最新提交 73e39abcd8b1d54377bd3e0b508c9d16a42cb65c 的桌面端、CI、Android 三个工作流现已全部成功，Windows EXE/PDB 检查和上传也通过。上面的下载链接已更新到此最新产物。

    诊断记录

    唯一诊断日志：%TEMP%\openless-1003-3c02ffc1.ndjson。只记录状态、操作边界和计数，不记录音频、识别文本、模型路径或凭据。请保留原文件，不编辑、不清空；若再次崩溃，可另外提供用该包匹配 PDB 解析后的调用栈。不要公开包含内存内容的完整 dump。

    请你复现 bug

    1. 完全退出旧版程序，下载并解压上面的 openless-windows-x64，使用其中安装器安装诊断版；保留同包 EXE/PDB 供崩溃符号化使用。
    2. 启用本地语音激活，使用原来出现问题的麦克风、模型和唤醒/结束词配置。
    3. 说完唤醒词后立即停止讲话，观察是否出现确认提示音；不要补字来促发。如果仍未响应，到此停止本次测试并反馈结果，不必强行进入听写。
    4. 如果正常进入听写，说一小段非敏感测试内容，再说结束词并立即停说，观察是否正常结束或再次崩溃。
    5. 在 Issue 回复实际结果（唤醒是否仍需额外讲话、结束是否正常、有无崩溃），并提供未经编辑的 %TEMP%\openless-1003-3c02ffc1.ndjson。如果日志未生成，也请明确说明，不要用普通启动日志代替。

  22. lededev commented on Oct 19, 2026

    @lededev
    lededev
    on Oct 19, 2026
    ContributorAuthor

    openless-1003-3c02ffc1.zip

    说完唤醒词之后，还是不能停下来等UI出现激活提示，要继续说话才能出现激活提示音和胶囊界面。
    还有一个bug，30秒超时的实现不对，30秒不是从说最后一个字后的静音期间计算时长，而是总共只能说30秒就自动结束了。可以改短一点比如10秒，这样容易复现。
    这次是崩在已激活正在语音输入的过程中。

    [0x00007FFC4A93D5F9 (ntdll.dll) (openless.exe 中)处有未经处理的异常: 0xC0000374: 堆已损坏。 (参数: 0x00007FFC4A9B48B0)。]	
>	ntdll.dll!00007ffc4a93d5f9()	未知
ntdll.dll!00007ffc4a93d5c3()	未知
ntdll.dll!00007ffc4a94665a()	未知
ntdll.dll!00007ffc4a94693a()	未知
ntdll.dll!00007ffc4a952935()	未知
ntdll.dll!00007ffc4a86c3fc()	未知
ntdll.dll!00007ffc4a86b041()	未知
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
[内联框架] openless.exe!core::ptr::drop_in_place() 行 842	Rust
openless.exe!alloc::rc::Rc::drop_slow<tao::platform_impl::platform::event_loop::runner::EventLoopRunner<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>>,alloc::alloc::Global>() 行 406	Rust
[内联框架] openless.exe!alloc::rc::impl$34::drop() 行 2501	Rust
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
openless.exe!core::ptr::drop_glue<tauri_runtime_wry::DispatcherMainThreadContext<enum2$<tauri::EventLoopMessage>>>() 行 847	Rust
openless.exe!core::ptr::drop_glue<tauri_runtime_wry::Context<enum2$<tauri::EventLoopMessage>>>() 行 847	Rust
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
openless.exe!core::ptr::drop_glue<tauri::app::AppHandle<tauri_runtime_wry::Wry<enum2$<tauri::EventLoopMessage>>>>() 行 847	Rust
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
[内联框架] openless.exe!openless_lib::coordinator::capsule_focus::emit_capsule_payload_locked::closure$0() 行 370	Rust
[内联框架] openless.exe!openless_lib::tauri_coordinator_host::impl$2::run_on_main_thread::closure$0() 行 898	Rust
openless.exe!core::ops::function::FnOnce::call_once<openless_lib::tauri_coordinator_host::impl$2::run_on_main_thread::closure_env$0<openless_lib::coordinator::capsule_focus::emit_capsule_payload_locked::closure_env$0>,tuple$<>>() 行 250	Rust
[内联框架] openless.exe!alloc::boxed::impl$31::call_once() 行 2320	Rust
openless.exe!tauri_runtime_wry::handle_user_message<enum2$<tauri::EventLoopMessage>>() 行 3340	Rust
[内联框架] openless.exe!tauri_runtime_wry::handle_event_loop() 行 4383	Rust
[内联框架] openless.exe!tauri_runtime_wry::make_event_handler::closure$0() 行 3302	Rust
openless.exe!tao::platform_impl::platform::event_loop::impl$3::run_return::closure$0<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>,tauri_runtime_wry::make_event_handler::closure_env$0<enum2$<tauri::EventLoopMessage>,tauri::app::impl$16::make_run_event_loop_callback::closure_env$0<tauri_runtime_wry::Wry<enum2$<tauri::EventLoopMessage>>,openless_lib::run_desktop::closure_env$2>>>() 行 245	Rust
[内联框架] openless.exe!alloc::boxed::impl$32::call_mut() 行 2327	Rust
[内联框架] openless.exe!tao::platform_impl::platform::event_loop::runner::impl$3::call_event_handler::closure$0() 行 251	Rust
[内联框架] openless.exe!core::panic::unwind_safe::impl$25::call_once() 行 275	Rust
[内联框架] openless.exe!std::panicking::catch_unwind::do_call() 行 576	Rust
[内联框架] openless.exe!std::panicking::catch_unwind() 行 544	Rust
[内联框架] openless.exe!std::panic::catch_unwind() 行 359	Rust
openless.exe!tao::platform_impl::platform::event_loop::runner::EventLoopRunner::catch_unwind<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>,tuple$<>,tao::platform_impl::platform::event_loop::runner::impl$3::call_event_handler::closure_env$0<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>>>() 行 156	Rust
[内联框架] openless.exe!tao::platform_impl::platform::event_loop::runner::EventLoopRunner::call_event_handler() 行 243	Rust
openless.exe!tao::platform_impl::platform::event_loop::runner::EventLoopRunner::send_event<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>>() 行 225	Rust
[内联框架] openless.exe!tao::platform_impl::platform::event_loop::thread_event_target_callback::closure$0() 行 2396	Rust
[内联框架] openless.exe!core::ops::function::FnOnce::call_once() 行 250	Rust
[内联框架] openless.exe!core::panic::unwind_safe::impl$25::call_once() 行 275	Rust
[内联框架] openless.exe!std::panicking::catch_unwind::do_call() 行 576	Rust
[内联框架] openless.exe!std::panicking::catch_unwind() 行 544	Rust
[内联框架] openless.exe!std::panic::catch_unwind() 行 359	Rust
[内联框架] openless.exe!tao::platform_impl::platform::event_loop::runner::EventLoopRunner::catch_unwind() 行 156	Rust
openless.exe!tao::platform_impl::platform::event_loop::thread_event_target_callback<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>>() 行 2447	Rust
[外部代码]	
[内联框架] openless.exe!tao::platform_impl::platform::event_loop::EventLoop::run_return() 行 267	Rust
openless.exe!tao::platform_impl::platform::event_loop::EventLoop::run<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>,tauri_runtime_wry::make_event_handler::closure_env$0<enum2$<tauri::EventLoopMessage>,tauri::app::impl$16::make_run_event_loop_callback::closure_env$0<tauri_runtime_wry::Wry<enum2$<tauri::EventLoopMessage>>,openless_lib::run_desktop::closure_env$2>>>() 行 229	Rust
[内联框架] openless.exe!tauri::app::App::run() 行 1365	Rust
openless.exe!openless_lib::run_desktop() 行 968	Rust
openless.exe!openless_lib::run() 行 230	Rust
[内联框架] openless.exe!core::ops::function::FnOnce::call_once() 行 250	Rust
openless.exe!std::sys::backtrace::__rust_begin_short_backtrace<void (*)(),tuple$<>>() 行 166	Rust
openless.exe!std::rt::lang_start::closure$0<tuple$<>>() 行 206	Rust
[内联框架] openless.exe!std::rt::lang_start_internal::closure$0() 行 175	Rust
[内联框架] openless.exe!std::panicking::catch_unwind::do_call() 行 576	Rust
[内联框架] openless.exe!std::panicking::catch_unwind() 行 544	Rust
[内联框架] openless.exe!std::panic::catch_unwind() 行 359	Rust
openless.exe!std::rt::lang_start_internal() 行 171	Rust
[外部代码]

  23. HKLHaoBin commented on Oct 19, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 19, 2026
    Collaborator

    @lededev 已收到 #1003 (comment) 的日志和反馈。日志有 45,531 条有效记录、两次运行，没有缺失序号或已记录的通道丢弃。

    我们已基于这些证据做了一个单变量修复实验 A1，现在可测试。它只针对“说完唤醒词立即静音时，要继续讲话才触发”的问题：在 VAD 段 flush 的 input_finished() 前补入 Sherpa 官方示例使用的 0.66 秒零样本尾部上下文。此前的记录中，183 次 flush 有 181 次在 EOF 后没有继续 decode 就直接 reset。这个改动没有增加等待，也没有修改 VAD 阈值或 reset/停止策略。

    目前不能称为已修复，需用本轮包进行二次复现验证。堆损坏崩溃及“超时应按最后讲话后的静音计算”仍未解决；这两项不会被算作 A1 已完成。

    A1 实验包

    三个工作流均成功，匹配的 Windows EXE/PDB 已校验并上传。尾部补齐顺序和重复边界有界性的两项回归测试已在 CI 实际执行并通过，但不代替你的设备上的验证。

    仍使用同一个日志：%TEMP%\openless-1003-3c02ffc1.ndjson。请保留原日志，不编辑、不清空；本轮新增记录带 attempt_id=A1-tail-context、change_id=C1-nonterminal-padding，便于与上次对比。全部 P1–P6 探针保留。若再次崩溃，请使用本轮同包 PDB，并只分享符号化调用栈，不要公开完整内存 dump。

    请你用修复版复现 bug

    1. 完全退出旧版，下载并安装上面的 A1 Windows 包；保留同包 EXE/PDB，不使用前两轮诊断包代替。
    2. 保持上次出现问题时的麦克风、模型及唤醒/结束词配置，不同时更改超时等设置。
    3. 说完唤醒词后立即停说，不补字，观察是否直接出现提示音和胶囊。若仍不响应，请停止本次测试并反馈，不必用继续讲话来强行进入听写。
    4. 若成功进入听写，说一小段非敏感测试内容，再说结束词并停说；记录是否正常结束，以及是否崩溃。
    5. 在此回复唤醒和结束的实际结果，并提供未经编辑的 %TEMP%\openless-1003-3c02ffc1.ndjson；若崩溃，附本轮 PDB 解析的调用栈。请不要删除或清空诊断日志。

  24. lededev commented on Oct 19, 2026

    @lededev
    lededev
    on Oct 19, 2026
    ContributorAuthor

    唤醒词的启动反馈已经符合预期。结束词有时会部分截断，出现在正文中。
    程序在语音识别时的崩溃还是会出现。

    openless-1003-3c02ffc1.zip

    [0x00007FFC4A93D5F9 (ntdll.dll) (openless.exe 中)处有未经处理的异常: 0xC0000374: 堆已损坏。 (参数: 0x00007FFC4A9B48B0)。]	
>	ntdll.dll!00007ffc4a93d5f9()	未知
ntdll.dll!00007ffc4a93d5c3()	未知
ntdll.dll!00007ffc4a94665a()	未知
ntdll.dll!00007ffc4a94693a()	未知
ntdll.dll!00007ffc4a952935()	未知
ntdll.dll!00007ffc4a86c3fc()	未知
ntdll.dll!00007ffc4a86b041()	未知
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
[内联框架] openless.exe!core::ptr::drop_in_place() 行 842	Rust
openless.exe!alloc::rc::Rc::drop_slow<tao::platform_impl::platform::event_loop::runner::EventLoopRunner<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>>,alloc::alloc::Global>() 行 406	Rust
[内联框架] openless.exe!alloc::rc::impl$34::drop() 行 2501	Rust
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
openless.exe!core::ptr::drop_glue<tauri_runtime_wry::DispatcherMainThreadContext<enum2$<tauri::EventLoopMessage>>>() 行 847	Rust
openless.exe!core::ptr::drop_glue<tauri_runtime_wry::Context<enum2$<tauri::EventLoopMessage>>>() 行 847	Rust
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
openless.exe!core::ptr::drop_glue<tauri::app::AppHandle<tauri_runtime_wry::Wry<enum2$<tauri::EventLoopMessage>>>>() 行 847	Rust
[内联框架] openless.exe!core::ptr::drop_glue() 行 847	Rust
[内联框架] openless.exe!openless_lib::coordinator::capsule_focus::emit_capsule_payload_locked::closure$0() 行 370	Rust
[内联框架] openless.exe!openless_lib::tauri_coordinator_host::impl$2::run_on_main_thread::closure$0() 行 898	Rust
openless.exe!core::ops::function::FnOnce::call_once<openless_lib::tauri_coordinator_host::impl$2::run_on_main_thread::closure_env$0<openless_lib::coordinator::capsule_focus::emit_capsule_payload_locked::closure_env$0>,tuple$<>>() 行 250	Rust
[内联框架] openless.exe!alloc::boxed::impl$31::call_once() 行 2320	Rust
openless.exe!tauri_runtime_wry::handle_user_message<enum2$<tauri::EventLoopMessage>>() 行 3340	Rust
[内联框架] openless.exe!tauri_runtime_wry::handle_event_loop() 行 4383	Rust
[内联框架] openless.exe!tauri_runtime_wry::make_event_handler::closure$0() 行 3302	Rust
openless.exe!tao::platform_impl::platform::event_loop::impl$3::run_return::closure$0<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>,tauri_runtime_wry::make_event_handler::closure_env$0<enum2$<tauri::EventLoopMessage>,tauri::app::impl$16::make_run_event_loop_callback::closure_env$0<tauri_runtime_wry::Wry<enum2$<tauri::EventLoopMessage>>,openless_lib::run_desktop::closure_env$2>>>() 行 245	Rust
[内联框架] openless.exe!alloc::boxed::impl$32::call_mut() 行 2327	Rust
[内联框架] openless.exe!tao::platform_impl::platform::event_loop::runner::impl$3::call_event_handler::closure$0() 行 251	Rust
[内联框架] openless.exe!core::panic::unwind_safe::impl$25::call_once() 行 275	Rust
[内联框架] openless.exe!std::panicking::catch_unwind::do_call() 行 576	Rust
[内联框架] openless.exe!std::panicking::catch_unwind() 行 544	Rust
[内联框架] openless.exe!std::panic::catch_unwind() 行 359	Rust
openless.exe!tao::platform_impl::platform::event_loop::runner::EventLoopRunner::catch_unwind<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>,tuple$<>,tao::platform_impl::platform::event_loop::runner::impl$3::call_event_handler::closure_env$0<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>>>() 行 156	Rust
[内联框架] openless.exe!tao::platform_impl::platform::event_loop::runner::EventLoopRunner::call_event_handler() 行 243	Rust
openless.exe!tao::platform_impl::platform::event_loop::runner::EventLoopRunner::send_event<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>>() 行 225	Rust
[内联框架] openless.exe!tao::platform_impl::platform::event_loop::thread_event_target_callback::closure$0() 行 2396	Rust
[内联框架] openless.exe!core::ops::function::FnOnce::call_once() 行 250	Rust
[内联框架] openless.exe!core::panic::unwind_safe::impl$25::call_once() 行 275	Rust
[内联框架] openless.exe!std::panicking::catch_unwind::do_call() 行 576	Rust
[内联框架] openless.exe!std::panicking::catch_unwind() 行 544	Rust
[内联框架] openless.exe!std::panic::catch_unwind() 行 359	Rust
[内联框架] openless.exe!tao::platform_impl::platform::event_loop::runner::EventLoopRunner::catch_unwind() 行 156	Rust
openless.exe!tao::platform_impl::platform::event_loop::thread_event_target_callback<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>>() 行 2447	Rust
[外部代码]	
[内联框架] openless.exe!tao::platform_impl::platform::event_loop::EventLoop::run_return() 行 267	Rust
openless.exe!tao::platform_impl::platform::event_loop::EventLoop::run<enum2$<tauri_runtime_wry::Message<enum2$<tauri::EventLoopMessage>>>,tauri_runtime_wry::make_event_handler::closure_env$0<enum2$<tauri::EventLoopMessage>,tauri::app::impl$16::make_run_event_loop_callback::closure_env$0<tauri_runtime_wry::Wry<enum2$<tauri::EventLoopMessage>>,openless_lib::run_desktop::closure_env$2>>>() 行 229	Rust
[内联框架] openless.exe!tauri::app::App::run() 行 1365	Rust
openless.exe!openless_lib::run_desktop() 行 968	Rust
openless.exe!openless_lib::run() 行 230	Rust
[内联框架] openless.exe!core::ops::function::FnOnce::call_once() 行 250	Rust
openless.exe!std::sys::backtrace::__rust_begin_short_backtrace<void (*)(),tuple$<>>() 行 166	Rust
openless.exe!std::rt::lang_start::closure$0<tuple$<>>() 行 206	Rust
[内联框架] openless.exe!std::rt::lang_start_internal::closure$0() 行 175	Rust
[内联框架] openless.exe!std::panicking::catch_unwind::do_call() 行 576	Rust
[内联框架] openless.exe!std::panicking::catch_unwind() 行 544	Rust
[内联框架] openless.exe!std::panic::catch_unwind() 行 359	Rust
openless.exe!std::rt::lang_start_internal() 行 171	Rust
[外部代码]

  25. HKLHaoBin commented on Oct 19, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 19, 2026
    Collaborator

    @lededev 感谢回传日志。唤醒词启动反馈已按你确认的结果验证通过；结束词部分残留和识别期间的堆损坏崩溃仍未验收。

    这次提供 A2 结束词尾部上下文实验版，提交 e776f79824ada78baa8429ac2548c57a2167f489，分支 HKLHaoBin/1003-voice-activation。只为正式转写的终止路径补入有界模型尾部上下文，再执行原有 EOF、解码和结果收集；没有扩大结束词删除范围，也没有改变并发、生命周期或超时策略。日志已显示结束词检测器命中后，正式转写终止时未继续解码，因此做这一个可逆变量的实验；是否解决残留，需要本次设备复验，不能仅凭构建成功断言。

    Windows 测试包（优先使用）

    下载 openless-windows-x64（Actions 产物可能需要登录 GitHub）。

    • ZIP 大小：82,303,864 字节。
    • ZIP SHA-256：4c2e9264124e3160a4373285692e17e2e502836fcd96b257d6704ad39ed2e8ec（这是整个 Actions ZIP 的摘要，不是内部安装程序摘要）。
    • 包含 Windows 安装包、同次构建的独立 EXE 与配套 PDB；符号存在校验和上传步骤已通过。请保留配套 EXE/PDB，以便进一步定位崩溃。
    • 保留现有 P1–P6 诊断探针，继续追加到 %TEMP%\openless-1003-3c02ffc1.ndjson；新运行标记为 A2-terminal-tail / C2-terminal-padding。请勿删除、清空或编辑原日志。诊断不记录音频或转写正文。

    本次远程验证

    以下三个工作流均为上述准确提交，已全部成功：

    Bugbot 已报告 No bugs found.；没有创建 PR，没有在本地执行编译、测试或打包。

    **未解决项明确保留：**识别期间的 0xC0000374 崩溃仍无已证实的损坏来源，UI 析构栈只能说明发现损坏的位置；按“最后说话后的静音时长”计时的超时语义也尚未修复。这次不将它们混入结束词实验，不宣称整个 issue 已完成，也不移除诊断。

    请你用修复版复现 bug

    1. 完全退出旧进程，安装上方 A2 Windows 测试包，启动新版本；保持本轮其他设置不变，保留此次配套 EXE/PDB 和已有 NDJSON 日志。
    2. 使用原来的 Windows Zipformer 语音激活设置。说出唤醒词后立即静音，检查启动反馈仍然正常，不补说额外词来推动识别。
    3. 说一小段正文，再完整说出结束词并立即静音。在原有超时之前完成本次短句测试；检查实时末尾、最终插入结果及历史记录中是否仍残留部分结束词，以及正文是否完整。若有残留，请描述残留片段；不必提供私人正文。
    4. 按此前会发生崩溃的正常语音识别操作继续测试；若再次崩溃，记录它发生在唤醒、录入中还是结束附近，并提供异常码/调用栈。不要公开完整内存转储；本版没有宣称修复崩溃。
    5. 完全退出程序后，将 %TEMP%\openless-1003-3c02ffc1.ndjson 原样压缩回传，不清空或编辑；分别报告“唤醒反馈、结束词残留、崩溃”三项结果。超时问题仍单独待修，不将固定总时长结束当作本次结束词命中。

  26. lededev commented on Oct 20, 2026

    @lededev
    lededev
    on Oct 20, 2026
    ContributorAuthor

    唤醒词改成 开始文字录入，结束词用 完成文字录入 念起来会更顺口、响亮、易于语音识别且符合实际功能事实：用户用语音来录入文字。
    结束词目前依然无法清理干净，目前看来是被文字优化的大语言模型进行了语序调整，变更了位置，导致无法清理。举例：
    我的实际说话内容：开始文字录入 哪怕端口存在时，也可以触发冷启动大模型的条件 完成文字录入
    语音识别并被本地大模型轻微优化后的输出：即使端口已存在，也可以满足启动大模型并完成文字录入的条件。
    设置中的 语音唤醒听写 超时自动结束 项依然有问题，我的设置为15秒，那么从语音识别开始，就只能说15秒就被自动中断。而不是识别出最后一个字后，15秒不在有新的字产生，才触发超时自动结束。

  27. HKLHaoBin commented on Oct 20, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 20, 2026
    Collaborator

    当前分支的 Windows 测试版已支持自定义唤醒词，结束词也可以自定义。

    在设置中找到 「语音唤醒听写」 并开启后：

    • 「开始命令」：默认是 开始语音录入，可以改成自己的唤醒短语。
    • 「完成命令」：默认是 完成语音录入，也可以修改。
    • 修改后点击输入框外部，会触发保存。

    对应设置代码：openless-all/app/src/pages/settings/RecordingInputSection.tsx:670。

  28. lededev commented on Oct 20, 2026

    @lededev
    lededev
    on Oct 20, 2026
    ContributorAuthor

    后续的优化建议：放音乐时进行语音识别是可以实现的。如果检测到默认播放设备处于非静音状态，就有声音输出。如果是音箱一类外放音源，麦克风会录制进去触发识别。
    解决办法是捕获播放的音频和麦克风录制的音频做比对，然后从录音中抵消掉音箱播放的那部分声音，这样播放音乐就不会误触发语音识别。

  29. HKLHaoBin commented on Oct 21, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 21, 2026
    Collaborator

    这个的话，你单开一个 issue 吧。

  30. H-Chris233
    added a commit that references this issue on Oct 21, 2026

    feat(voice-activation): 支持 Windows 本地语音唤醒听写 (#1240)

    43df23b

  31. HKLHaoBin commented on Oct 21, 2026

    @HKLHaoBin
    HKLHaoBin
    on Oct 21, 2026
    Collaborator

    #1228

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