语音播客
豆包语音播客大模型支持根据文本、网页或话题生成播客,也支持将已有对话文本合成为音频。本文介绍 HTTP SSE 接口的接入方式:客户端发送一次请求后,通过 SSE 持续接收文本、音频分片及生成状态。
通过请求参数 action 指定生成方式。
- 仅需生成播客文本时,可设置 input_info.only_nlp_text=true,不输出音频。
- 需要下载完整音频时,可设置 input_info.return_audio_url=true。下载链接通过事件 363(PodcastEnd)的 meta_info.audio_url 返回,有效期为 24 小时。
播客内容按轮次返回,每个轮次通过 round_id 标识。同一轮次的音频可分多次返回,每次返回的音频数据称为“音频分片”。
- 建议选择同系列音色配对,以获得更好的效果。“黑猫侦探社咪仔”和“刘飞和潇磊”为播客专属音色系列。
- 发送请求:向 /api/v3/podcast/sse 提交 JSON 请求,携带鉴权信息、生成方式、输入内容及音频配置。无需额外发送会话开始或结束消息。
- 确认连接:检查 HTTP 状态码及响应类型 text/event-stream。收到 HTTP 200 后持续读取响应;HTTP 200 仅表示连接已建立,不表示音频生成成功。
- 保存会话标识:收到事件 150(SessionStarted)后,保存 session_id,用于问题排查及连接中断后的断点续传。
- 接收轮次数据:事件 360 表示轮次开始,记录轮次编号、文本及音色;事件 361 返回音频分片;事件 362 表示轮次结束。多轮播客按此流程依次返回。
- 处理用量及播客结束信息:收到事件 154 时记录用量;收到可选事件 363 时记录播客结束信息。收到上述事件后,仍须继续读取响应。
- 确认请求结果:收到事件 152 且 code=20000000 时,确认生成成功并完成音频保存。事件 151 表示会话取消,事件 153 表示会话失败。若在收到上述结束事件前连接中断或超时,则结果不完整。
SSE 消息通过 event: 指定事件类型,通过 data: 承载事件内容(JSON)。例如,event: 361 表示音频分片事件。事件编号与 HTTP 状态码相互独立。
- 解析完整消息:SSE 消息以空行分隔。通过 event: 识别事件类型,按 SSE 规则合并同一消息中的一个或多个 data: 行,再解析 JSON。
- 解析事件数据:SSE 的 data: 行承载 JSON;JSON 中的 data 字段承载 Base64 编码的音频分片,须解码后使用。文本、音色及用量等信息通过 payload 返回。
- 按序处理音频:事件 361 可连续返回多次。解码后的音频字节须按接收顺序追加至文件或播放器,避免并行处理导致顺序错乱。
- 处理保活消息:服务端空闲时约每 15 秒发送一次 :keep-alive。该消息为维持连接的注释行,不包含播客内容。应跳过所有以冒号开头的注释行。
- 等待会话结束:轮次数、音频分片数及用量事件次数均不固定,不应在收到固定数量的消息后结束读取。
生成过程中连接中断时,可保留已完整接收的轮次,通过新请求接收剩余内容。本接口以完整轮次为单位进行断点续传;未完整接收的轮次需丢弃已接收的音频分片,并重新接收该轮次的全部内容。
- 保留已完整接收的轮次音频,丢弃中断时未完成轮次的音频分片。
- 保留原请求中的文本、音色、音频配置等参数,添加 retry_info 后重新发送 HTTP POST 请求。
- 接收后续轮次,并按顺序将完整音频追加至已保留的音频。收到事件 152 且 code=20000000 后,确认生成成功。
- 轮次 0~8 已完整接收,轮次 9 仅接收部分音频时连接中断。保留轮次 0~8 的音频,丢弃轮次 9 的音频分片,并将 last_finished_round_id 设为 8。续传时从轮次 9 开始接收,再与已保留的音频拼接。
- 续传请求未填写 retry_info 时,可能从头生成。本接口不支持通过 SSE 的 Last-Event-ID 自动重放历史事件。
- 构建完整播客时间轴时,须结合已保留音频的时长计算续传结果中的 start_time 和 end_time,不能直接将其作为完整播客的全局时间。
最近更新时间:2026.10.14 16:33:12