技能介绍

解决的痛点

在本地使用 IndexTTS2 生成口播或旁白音频时，通常需要手动打开 WebUI，输入文本，点击“生成语音”按钮，然后等待并下载文件。这种交互方式难以集成到自动化流水线中，且每次启动或切换任务都需要人工介入。此外，如果直接调用底层模型，会导致模型被重复加载，瞬间吃掉双倍显存，给本地部署带来不必要的资源压力。

核心能力与工作流

该技能通过 gradio_client 直接与已经运行的 IndexTTS2 WebUI (webui.py) 进程通信，完美复用了 WebUI 的推理路径。这意味着模型只会在 WebUI 启动时加载一次，后续的自动化调用不会增加额外的 VRAM 开销。

核心工作流如下：

环境与进程检查：首先探测 127.0.0.1:7860 端口。若 WebUI 未运行且允许自动启动，技能会在后台拉起 webui.py（首次加载需 1-2 分钟）。
音色与文案准备：默认使用 outputs/presets/ 下的 Hai 预设（prompt.wav）作为声音参考。文案长度可参考约 4.5 字/秒的节奏来估算。
程序化调用：执行 scripts/generate_tts.py。脚本会动态读取 /gen_single 接口签名，填充默认参数，并覆写需要控制的字段，最终返回生成的 WAV 文件绝对路径（通过 OUTPUT:{path} 标识）。

适用边界与注意事项

参数传递陷阱：在调用 /gen_single 时，emo_control_method 必须传入选项文本字符串而非数字索引；声音参考音频必须封装为 Gradio 的 FileData 字典，不能直接传裸文件路径。
返回值解析：接口返回的是 gr.update(...) 字典，实际的音频文件会落盘到 outputs/spk_{timestamp}.wav，需通过解析 OUTPUT: 行或文件系统确认结果。
硬件性能：在 Apple Silicon (MPS) 上推理速度明显慢于 CUDA，生成较长音频时需预留更多时间。
进程管理：WebUI 进程会在多次调用间保持存活以复用显存，调用结束后可根据需要由用户决定是否手动终止。