[WebRTC Demo][streaming_generate] decode完成但无wav输出，超时退出 [单工]

[Hel5ing]

Describe the bug
单工模式下,对话无响应,日志显示:
[streaming_generate] decode完成但无wav输出，超时退出 [单工]

[⏱️ Generate 性能总结] [单工]
音频首响: N/A
总生成时间: 6630.1ms
总音频时长: 0.00s
整体 RTF: 0.00x ✅
发送 Chunk 数量: 0

Screenshots

Desktop (please complete the following information):

• OS: macOS M5
• Browser ARC
• Version 26.2 (25C56)

[seasidedog24]

@Hel5ing Hi! 抱歉回复晚了，春节假期刚结束。🧧

从你的日志看，问题很明确：LLM decode 正常完成（6630ms），但 Token2Wav 没有生成任何 WAV 文件（音频时长 0.00s，发送 Chunk 数量 0）。这说明是 TTS 音频生成环节出了问题，而不是推理本身。

请按以下步骤排查：

1. 检查 Token2Wav 模型是否正确加载

Token2Wav 依赖 prompt_cache.gguf 文件。如果该文件缺失或路径错误，Token2Wav 会静默失败（不报错，但不输出 WAV）。

# 检查模型文件是否存在
ls -la models/MiniCPM-o-4_5-GGUF/prompt_cache.gguf
# 或你实际使用的模型路径

如果文件不存在，需要按文档重新下载完整的 GGUF 模型（包含 prompt_cache）。

2. 检查 C++ 服务的启动日志

C++ 推理服务（llama-server）启动时应该有 Token2Wav/Token2Mel 的初始化日志。请检查启动时是否有类似以下的错误或警告：

[Token2Wav] init failed
[Token2Mel] model load error

如果有，贴出来可以进一步定位。

3. 检查 WAV 输出目录

WAV 文件会被写入到一个临时目录（通常是 /tmp/minicpmo_wav/ 或类似路径）。请确认该目录存在且有写权限：

# 查看 WAV 输出目录是否存在
ls -la /tmp/minicpmo_wav/
# 如果不存在，手动创建
mkdir -p /tmp/minicpmo_wav/

4. 确认 n_timesteps 参数

n_timesteps 需要和 prompt_cache.gguf 编译时使用的值一致。如果不匹配，Token2Mel 可能会初始化失败。最新版本使用 n_timesteps=5。

5. macOS M5 的 Metal 兼容性

你的设备是 macOS M5，这是比较新的芯片。如果上面都没问题，可能是 Metal shader 的兼容性问题。可以尝试：

# 强制使用 CPU 运行 Token2Wav（排除 Metal 问题）
# 在启动命令中添加：
--no-metal-tts   # 如果支持的话

---

能否提供以下信息帮助进一步排查？

1. 你的部署方式（Docker / oneclick.sh / 手动编译）
2. C++ 推理服务（llama-server）的完整启动日志
3. minicpmo_cpp_http_server.py 的详细日志（特别是 streaming_generate 函数中 Token2Mel 和 Vocoder 相关的行）

我之前在 Mac mini M4 上遇到过类似的 Token2Wav 延迟问题，详细记录在 Issue #75，供参考。

[tc-mb]

@Hel5ing
我感觉好像是中间断了，有可能是没生成wav出来。您可以看下设置的output路径下面是否有wav文件生成。
如果没生成，感觉是token2wav不对，比如gguf没下载全等等，可以具体分析。
如果有wav，感觉是output设置和server不对齐，导致server没拿到。