 Blizzard
|
149c4dc89a
|
fix(voice): 未配 TTS 时也回 tts_end(别让客户端永远卡在"思考中")
TTSEnabled 要 api_key + tts_resource_id + tts_voice_type 三项齐全,而
ASREnabled 只要两项。线上只配齐 ASR 时:转写成功→进思考中→agent 出结果→
speak() 静默 return,连 tts_end 都不发 → 客户端永远停在"思考中"。
用户看到的是"提问后彻底没反应",完全看不出是配置缺失——两个症状
(一直思考不回答 / 结果不语音回复)其实是这同一个静默 return。
改:未配 TTS 时明确回 error 文案 + tts_end,让客户端回到待命并告知原因;
服务端日志也点明缺哪三项。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-07-25 15:27:02 +08:00 |
|
|
Blizzard
|
aba88193d8
|
feat(voice): 提升桌面端语音交互与本地任务执行支持
|
2026-07-24 16:40:25 +08:00 |
|
|
Blizzard
|
b6927247da
|
feat(voice): 下行打字机文本流 + 首块快出，即时反馈
- protocol.go: 新增 ServerReply("reply") 消息——Agent 回答增量文本
- voice_tts.go: token 一到即转发客户端(打字机),同时攒句喂 TTS(音频随后)
- sentence_buffer.go: 本轮首句用低阈值(5 rune)抢首字延迟,之后回常规 12
- 桌面端 voice.ts onReply + VoiceDock 对话气泡(我说的 + JARVIS 打字机回答,思考态光标)
管线已最优:文字在 LLM 首 token 即刻上屏、音频紧随。剩余时延=大模型 TTFT(deepseek-v4-pro
4-7s 且波动大,疑似推理模型),这是模型的账、非管线——真要"马上响应"需换快模型。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-22 11:25:20 +08:00 |
|
|
Blizzard
|
6fe0a58f1b
|
feat(voice): 火山双向流 TTS 客户端 + 下行接线(Phase 1 嘴巴)
回答 token 流 → 攒句器 → 火山双向 TTS → 音频帧回推客户端，端到端连续朗读打通。
- tts_frame.go: V3 事件族帧编解码(事件号+会话ID+gzip)，与 ASR 简帧不同族；
从官方参考实现核实 generate_header/parse_response 字节布局；3 解析单测
- tts.go: seed-tts-2.0 双向流客户端 StartTTS(握手ConnectionStarted/SessionStarted)
/Speak(逐句TaskRequest)/Finish/Audio()/Close，PCM 24k；新版 API Key 鉴权
- voice_tts.go: speak() 先订阅token流再建TTS(core NATS无持久,握手期攒句入pending
就绪补吐,不丢开头)；音频泵首帧ServerSpeaking、收尾ServerTTSEnd；打断stopTTS
- voice.go: barge_in→stopTTS；会话结束连带停TTS；final转写→go speak(taskID)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-22 09:25:49 +08:00 |
|