Feature Request: 新增基于 FunASR WebSocket 服务的插件式 STT Provider
背景
首先感谢作者开源这个项目。Shinsekai 现在已经具备比较完整的语音输入/输出链路，我在阅读仓库后，感觉当前架构很适合新增一个基于 FunASR WebSocket 服务的 STT provider。
我自己有一些 FunASR 语音处理和部署经验，因此想先提一个 feature issue 讨论方案。如果这个方向合适，我愿意继续跟进PR。
当前现状
我理解目前项目里的 STT/ASR 运转方式大致如下：
- 默认入口在
asr/asr_adapter.py 中的 create_default_asr_adapter(callback)
- 当前会从
system_config.asr_provider 读取 provider，再从 ASRAdapterFactory._adapters 里选择具体适配器
- 目前内置 provider 只有
vosk
- 其他 ASR 后端是通过插件机制
register_asr_adapter(...) 注入到同一套工厂里的
ASRAdapter 统一接口已经比较清晰：start / stop / pause / resume / get_status- 识别结果回调也是统一的：
callback(text, is_partial)
- Settings 页会自动枚举
ASRAdapterFactory._adapters，因此只要注册新的 slug，就可以进入现有配置流
从 README 和插件开发文档来看，项目本身也明确是支持插件式扩展 ASR 后端的。
提议
建议新增一个 插件式 ASR provider，例如：
首版目标不是改动现有默认 Vosk 链路，而是为已经自行部署 FunASR 的用户提供一个可选语音识别后端。
接入方式建议如下：
- 用户本地或局域网先部署 FunASR WebSocket 服务
- Shinsekai 侧继续负责麦克风采集 PCM 音频
- 适配器通过 WebSocket 与 FunASR 服务建连
- 持续发送音频块，并消费服务端返回的 partial/final transcript
- partial 结果回调
callback(text, True)
- final 结果回调
callback(text, False)
为什么值得做
我认为这个功能有几个比较实际的价值：
- 非常贴合当前架构：它不需要改写 ASR 主流程，只需要新增一个 provider
- 降低本地推理负担：用户可以把识别服务部署在本机、局域网机器，甚至后续扩展到远端服务器
- 中文场景有吸引力：FunASR 在中文实时识别、标点、VAD 这一类场景里有比较成熟的部署方案
- 与现有 issue 不重复：当前 open issue 里有语音输入体验优化需求，但没有专门讨论新增 FunASR provider 的 issue
建议的首版范围
建议首版先控制在一个比较容易合并的最小范围，只支持：
- 自托管 FunASR WebSocket 服务
ws:// / wss:// 基础连接能力- 最小配置项：
hostportssl 或 use_sslmode，默认 2pass
这部分配置理论上可以直接走现有：
get_config_schema()api.yaml -> asr_extra_configs[provider_slug]
不需要额外发明一套新配置系统。
首版可以先 不把以下内容做成必选项：
- hotword
- ITN
- 更细的 chunk size 调参
- 更多高级运行参数
这些可以先使用适中的默认值，等基础链路稳定后再扩展。
一个可能的实现思路
如果按插件式 provider 落地，我理解实现上大致可以是：
- 新建
FunASRWSSAdapter(ASRAdapter)
- 在
start() 中建立 WebSocket 连接，并启动音频发送线程/消息接收线程
- 将麦克风采集到的 PCM 数据持续发送给 FunASR 服务
- 服务端返回中间识别结果时，触发 partial 回调
- 服务端返回句末修正结果时，触发 final 回调
pause() 暂停发送音频但保留连接resume() 恢复发送stop() 关闭连接、线程与音频资源- 若服务不可达、端口错误、握手失败或 SSL 不匹配，应优雅回退到 idle/stopped 状态，并写日志，避免影响主程序其他功能
语言映射上，也可以先沿用宿主已有的 zh / ja / en 逻辑，在适配器内部再做必要转换。
参考资料
FunASR 官方文档里已经有比较直接可用的 WebSocket 服务形态，因此我感觉这个提案实现成本是可控的：
- FunASR Python WebSocket README：支持
offline / online / 2pass
- FunASR Quick Start：可直接启动
python funasr_wss_server.py --port 10095
- FunASR Realtime Service 文档：也提供 Docker 化实时部署路径
额外说明
我这里先提的是 功能提案 + 落地思路，不是要求项目一定做成核心内置。
如果作者认可这个方向，我愿意继续往下推进：
- 先做一个插件式
funasr_wss provider
- 补基础配置项和最小测试
- 后续再看是否值得继续扩展 hotword、ITN、高级参数，或者讨论是否并入核心
如果作者觉得这个功能适合收进生态，我也愿意继续参与这部分开发。
Feature Request: 新增基于 FunASR WebSocket 服务的插件式 STT Provider
背景
首先感谢作者开源这个项目。Shinsekai 现在已经具备比较完整的语音输入/输出链路，我在阅读仓库后，感觉当前架构很适合新增一个基于 FunASR WebSocket 服务的 STT provider。
我自己有一些 FunASR 语音处理和部署经验，因此想先提一个 feature issue 讨论方案。如果这个方向合适，我愿意继续跟进PR。
当前现状
我理解目前项目里的 STT/ASR 运转方式大致如下：
asr/asr_adapter.py中的create_default_asr_adapter(callback)system_config.asr_provider读取 provider，再从ASRAdapterFactory._adapters里选择具体适配器voskregister_asr_adapter(...)注入到同一套工厂里的ASRAdapter统一接口已经比较清晰：start / stop / pause / resume / get_statuscallback(text, is_partial)ASRAdapterFactory._adapters，因此只要注册新的 slug，就可以进入现有配置流从 README 和插件开发文档来看，项目本身也明确是支持插件式扩展 ASR 后端的。
提议
建议新增一个 插件式 ASR provider，例如：
funasr_wss首版目标不是改动现有默认 Vosk 链路，而是为已经自行部署 FunASR 的用户提供一个可选语音识别后端。
接入方式建议如下：
callback(text, True)callback(text, False)为什么值得做
我认为这个功能有几个比较实际的价值：
建议的首版范围
建议首版先控制在一个比较容易合并的最小范围，只支持：
ws:///wss://基础连接能力hostportssl或use_sslmode，默认2pass这部分配置理论上可以直接走现有：
get_config_schema()api.yaml -> asr_extra_configs[provider_slug]不需要额外发明一套新配置系统。
首版可以先 不把以下内容做成必选项：
这些可以先使用适中的默认值，等基础链路稳定后再扩展。
一个可能的实现思路
如果按插件式 provider 落地，我理解实现上大致可以是：
FunASRWSSAdapter(ASRAdapter)start()中建立 WebSocket 连接，并启动音频发送线程/消息接收线程pause()暂停发送音频但保留连接resume()恢复发送stop()关闭连接、线程与音频资源语言映射上，也可以先沿用宿主已有的
zh / ja / en逻辑，在适配器内部再做必要转换。参考资料
FunASR 官方文档里已经有比较直接可用的 WebSocket 服务形态，因此我感觉这个提案实现成本是可控的：
offline / online / 2passpython funasr_wss_server.py --port 10095额外说明
我这里先提的是 功能提案 + 落地思路，不是要求项目一定做成核心内置。
如果作者认可这个方向，我愿意继续往下推进：
funasr_wssprovider如果作者觉得这个功能适合收进生态，我也愿意继续参与这部分开发。