人工智能语音音频【免费下载链接】PaddleSpeechEasy-to-use Speech Toolkit including Self-Supervised Learning model, SOTA/Streaming ASR with punctuation, Streaming TTS with text frontend, Speaker Verification System, End-to-End Speech Translation and Keyword Spotting. Won NAACL2022 Best Demo Award.项目地址https://gitcode.com/gh_mirrors/pa/PaddleSpeech点击查看免费下载paddlespeech.server.utils.util是 PaddleSpeech 服务端paddlespeech/server的核心公共工具模块集中实现了 wav 与 base64 互转、流式推理数据分块get_chunks、特征去归一化denorm、流式合成延迟统计compute_delay以及引擎端推理日志统计count_engine等关键能力。它是流式 TTS在线语音合成服务能够边合成边输出的底层支撑无论是 Python 版还是 ONNX 版在线 TTS 引擎都直接依赖该模块完成 mel 频谱的分块切分、拼接和反归一化服务端客户端的延迟指标同样由它计算。阅读本文后你将掌握 PaddleSpeech 服务端 util 模块中每个函数的实现原理、在真实调用链中的位置以及如何利用它完成流式 TTS 的端到端调试与性能评估。模块定位与调用关系总览在 PaddleSpeech 服务端架构中util.py 与同目录下的 audio_handler.py、audio_process.py、buffer.py、config.py 等共同构成服务端工具层。从源码中的 import 关系看util 模块被以下关键位置引用服务端客户端命令行paddlespeech_client.py 引入compute_delay与wav2base64HTTP/WS 音频处理器audio_handler.py 引入wav2base64用于 ASR、TTS、Vector 等服务的音频编码传输Python 版在线 TTS 引擎tts_engine.py 引入denorm与get_chunksONNX 版在线 TTS 引擎tts_engine.py 同样引入denorm与get_chunks单元/联调测试tests/tts/online/http_client.py 与 tests/tts/online/ws_client.py 引入compute_delay。可见该模块横跨客户端测延迟、服务端做流式推理两大环节是服务端链路中被复用最频繁的工具模块之一。该模块同时是文档 docs/source/api/paddlespeech.server.utils.util.rst 的 automodule 自动化文档生成对象其公开函数含无下划线前缀的成员都会通过 Sphinx 的:members:、:undoc-members:、:show-inheritance:指令自动收录进 API 文档。音频编解码wav2base64 与 base64towavwav2base64读取 wav 并编码为 base64 字符串def wav2base64(wav_file: str): read wave file and covert to base64 string with open(wav_file, rb) as f: base64_bytes base64.b64encode(f.read()) base64_string base64_bytes.decode(utf-8) return base64_string实现要点源码位置以二进制模式rb打开 wav 文件用标准库base64.b64encode对原始字节流编码将编码结果解码为 UTF-8 字符串返回。该函数是所有 HTTP 类音频服务ASR、Vector、CLS 等请求体的入口客户端先将 wav 文件编码为 base64 文本再放入 JSON 载荷发送给服务端。典型调用场景见 audio_handler.py 中ASRHttpHandler.run的audio wav2base64(input)以及VectorHttpHandler、VectorScoreHttpHandler注册/打分音频均经此编码。命令行客户端 paddlespeech_client.py 中的CLSClientExecutor同样使用该函数构造{audio: audio, topk: topk}请求。base64towav预留的反向接口def base64towav(base64_string: str): pass源码位置 表明该函数当前仅为占位实现pass尚未落地。服务端实际的反向解码逻辑base64 → PCM bytes → wav 文件位于 audio_process.py 的save_audio等函数中由 audio_handler.py 的TTSWsHandler.run通过save_audio(all_bytes, output, self.sample_rate)调用。因此可以推断base64towav是模块作者预留的对称 API实际项目中如需解码可优先复用audio_process中的现成工具。self_check资源自检钩子def self_check(): self check resource return True源码位置。该函数目前固定返回True从实现看仅作为服务启动阶段资源自检的钩子函数预留尚未接入具体校验逻辑。在 base_commands.py 等入口模块中并未发现对其的强制调用因此可以推断它更多是模块设计上的扩展点当需要为服务端增加环境、模型或端口占用的自检能力时可在该函数内补充断言逻辑。denorm流式声学模型的特征反归一化def denorm(data, mean, std): stream am model need to denorm return data * std mean源码位置。该函数实现标准的 z-score 反归一化公式x x * std mean。为什么流式 AM 需要 denorm在训练/推理时声学模型输出的 mel 频谱通常经过ZScore归一化减均值除标准差以稳定训练而送入声码器vocoder前必须恢复为真实量纲的 mel 特征。这在 tts_engine.py 中可看到完整对称逻辑推理侧am_normalizer ZScore(am_mu, am_std)模型输出before_outs postnet后得到normalized_mel反归一化侧L425-L427sub_mel denorm(normalized_mel, self.executor.am_mu, self.executor.am_std)。ONNX 版引擎在 onnx/tts_engine.py 中对该函数的使用方式完全一致。am_mu、am_std来自模型配套的speech_stats统计文件由get_model_info加载为 paddle 张量python 版实现 L81-L83。get_chunks流式推理的分块切分核心get_chunks是流式 TTS 中最核心的工具函数负责把整段特征按block_size切成若干带 pad 的 chunkdef get_chunks(data, block_size, pad_size, step): Divide data into multiple chunks Args: data (tensor): data block_size (int): [description] pad_size (int): [description] step (str): set am or voc, generate chunk for step am or vocoder(voc) Returns: list: chunks list if block_size -1: return [data] if step am: data_len data.shape[1] elif step voc: data_len data.shape[0] else: logger.error(Please set correct type to get chunks, am or voc) chunks [] n math.ceil(data_len / block_size) for i in range(n): start max(0, i * block_size - pad_size) end min((i 1) * block_size pad_size, data_len) if step am: chunks.append(data[:, start:end, :]) elif step voc: chunks.append(data[start:end, :]) else: logger.error(Please set correct type to get chunks, am or voc) return chunks源码位置。关键设计点整段模式block_size -1时直接返回[data]等价于关闭流式分块用于非流式场景维度差异step am时取data.shape[1]mel 帧位于第二维shape 为[batch, frames, dim]step voc时取data.shape[0]mel 特征被整理为[frames, dim]直接按帧切行pad 处理每个 chunk 的起始为i * block_size - pad_size不小于 0结束为(i1) * block_size pad_size不超过总长使相邻 chunk 有pad_size帧的重叠避免边界帧上下文缺失导致的合成瑕疵分块数量n ceil(data_len / block_size)末尾不足一块时自动截断到data_len。在 Python 版流式 TTS 引擎中的完整调用链以fastspeech2_csmsc流式 voc整段 am为例python/tts_engine.py L388-L404mel self.executor.am_inference(part_phone_ids) # 整段 am 推理出 mel mel_chunks get_chunks(mel, self.voc_block, self.voc_pad, voc) voc_chunk_num len(mel_chunks) for i, mel_chunk in enumerate(mel_chunks): sub_wav self.executor.voc_inference(mel_chunk) # 逐块 voc 推理 sub_wav self.depadding(sub_wav, voc_chunk_num, i, self.voc_block, self.voc_pad, self.voc_upsample) yield sub_wav # 边推边吐音频对于fastspeech2_cnndecoder_csmsc流式 am 流式 vocL419-L430 会先get_chunks(orig_hs, self.am_block, self.am_pad, am)对 encoder 输出切块逐块过 decoder 与 postnetdenorm反归一化后用depadding去掉 pad 帧再拼入mel_streaming当累计 mel 帧达到 voc 的 chunk 窗口end时触发流式 voc 推理L440-L465。ONNX 版引擎onnx/tts_engine.py L351、L383调用模式与之一致。block/pad 参数如何配置对应配置见 tts_online_application.yaml参数默认值说明am_block72仅fastspeech2_cnndecoder系列流式 AM 使用决定 encoder 输出的分块帧数am_pad12AM 分块的重叠帧数am_pad设为 12 时流式合成效果与非流式一致voc_block36声码器输入 mel 的分块帧数voc_pad14声码器分块重叠帧数mb_melgan设为 14 时效果与非流式一致最小可到 7 仍听感正常hifigan设为 19 效果一致14 听感正常voc_upsample300ONNX 配置必须与 voc 模型配置中的n_shift一致引擎初始化时会对voc_block 0 and voc_pad 0做断言python/tts_engine.py L245-L247并校验 AM 与 Vocoder 的采样率一致L285-L287。depadding与 get_chunks 配套的去 pad 逻辑get_chunks切分时加入了重叠 pad因此在推理后必须按 chunk 序号精确裁剪这部分由引擎内的depadding完成python/tts_engine.py L325-L340首块chunk_id 0只保留前block * upsample帧丢弃尾部 pad末块chunk_id chunk_num - 1保留front_pad * upsample之后的部分中间块截取[front_pad, front_pad block) * upsample区间。其中front_pad min(chunk_id * block, pad)upsample为声码器的上采样倍数mel 帧到波形采样点的比例。正是因为get_chunks与depadding在切分与还原上严格对称流式输出才能与非流式输出在内容上保持一致。compute_delay流式合成的延迟统计def compute_delay(receive_time_list, chunk_duration_list): compute delay Args: receive_time_list (list): Time to receive each packet chunk_duration_list (list): The audio duration corresponding to each packet Returns: [list]: Delay time list assert (len(receive_time_list) len(chunk_duration_list)) delay_time_list [] play_time receive_time_list[0] chunk_duration_list[0] for i in range(1, len(receive_time_list)): receive_time receive_time_list[i] delay_time receive_time - play_time # 有延迟 if delay_time 0: play_time play_time delay_time chunk_duration_list[i] delay_time_list.append(delay_time) # 没有延迟 else: play_time play_time chunk_duration_list[i] return delay_time_list源码位置。该函数模拟客户端顺序播放音频包的过程来量化流式合成中的卡顿输入receive_time_list每个音频包的到达时间戳chunk_duration_list每个音频包对应的播放时长维护理想播放进度play_time初始为首个包到达时间 首包时长对每个后续包若到达时间晚于理想播放进度delay_time 0说明该包来晚了、播放会中断记录delay_time并顺延播放进度若按时到达则直接追加时长返回值delay_time_list为所有迟到包的延迟时长列表为空则表示无任何卡顿。调用方在客户端侧HTTP 与 WebSocket 两种协议下TTSHttpHandler/TTSWsHandler都会在接收循环中记录receive_time_list与chunk_duration_listaudio_handler.py L375-L379、L480-L494随后由paddlespeech_client.tts_onlinepaddlespeech_client.py L245-L246和联调脚本 http_client.py、ws_client.py 调用compute_delay并输出如下统计Delay situation: total number of packages: N, the number of delayed packets: M, minimum delay time: x s, maximum delay time: y s, average delay time: z s, delay rate: M/N若delay_time_list为空则输出The sentence has no delay in streaming synthesis.。这套指标与first response、final response、RTF一起构成流式 TTS 服务质量评估的标准输出。count_engine引擎端推理日志统计与 RTF 计算def count_engine(logfile: str./nohup.out): For inference on the statistical engine side Args: logfile (str, optional): server log. Defaults to ./nohup.out. first_response_list [] final_response_list [] duration_list [] with open(logfile, r) as f: for line in f.readlines(): if - first response time: in line: first_response float(line.splie( )[-2]) ...源码位置。该函数通过解析服务端日志默认./nohup.out统计引擎侧性能从日志行中匹配三类关键字- first response time:、- final response time:、- The durations of audio is:并取倒数第二个字段作为数值注意源码中该处方法名写作line.splie( )属于已知笔误实际应按split( )理解即空格切分后取倒数第二个元素统计输出测试条数、平均首响应时间、平均最终响应时间、平均音频时长、RTFReal Time Factor 最终响应时间之和 / 音频时长之和以及 min/max 统计RTF 是衡量语音合成/识别引擎实时性的核心指标RTF 1表示处理速度快于音频播放速度。这些日志由流式 TTS 引擎在推理末尾统一打印python/tts_engine.py L507-L514logger.info(fsentence: {sentence}) logger.info(fThe durations of audio is: {duration} s) logger.info(ffirst response time: {self.first_response_time} s) logger.info(ffinal response time: {self.final_response_time} s) logger.info(fRTF: {self.final_response_time / duration}) logger.info(fOther info: front time: {self.frontend_time} s, first am infer time: {self.first_am_infer} s, first voc infer time: {self.first_voc_infer} s,)实战如何用 util 模块完成流式 TTS 链路调试综合以上工具函数一条完整的流式 TTS 调试链路可以组织为启动服务端参考 tts_online_application.yaml 配置协议http/websocket引擎tts_online或tts_online-onnx设置am、voc、am_block、am_pad、voc_block、voc_pad等参数后启动服务并将服务日志重定向到nohup.out客户端调用使用paddlespeech_client.tts_online源码见 paddlespeech_client.py发起流式合成客户端在接收音频包时记录时间戳与包时长结束时调用compute_delay输出卡顿统计服务端统计批量压测完成后运行count_engine(./nohup.out)直接得到平均首/最终响应时间、平均时长与 RTF用于判断引擎实时性与分块参数block/pad是否合理参数调优若compute_delay显示延迟包较多可尝试增大voc_pad如 hifigan 从 14 提到 19以提升边界帧上下文质量、或调整voc_block平衡首包延迟与拼接开销同时对照count_engine的 RTF 观察推理开销变化。小结paddlespeech.server.utils.util以极小的代码量承载了流式 TTS 服务端最关键的三个环节音频的 base64 编解码传输wav2base64、流式推理的 mel 分块与反归一化get_chunks、denorm配合引擎内depadding形成完整的切分—推理—还原闭环以及客户端/引擎两侧的性能度量compute_delay、count_engine。它同时是被 API 文档 自动化收录的公开模块理解它即可打通 PaddleSpeech 在线语音合成从发请求到出音频再到评质量的整条链路。赞分享人工智能语音音频【免费下载链接】PaddleSpeechEasy-to-use Speech Toolkit including Self-Supervised Learning model, SOTA/Streaming ASR with punctuation, Streaming TTS with text frontend, Speaker Verification System, End-to-End Speech Translation and Keyword Spotting. Won NAACL2022 Best Demo Award.项目地址https://gitcode.com/gh_mirrors/pa/PaddleSpeech点击查看免费下载相关推荐Input Leap 完整教程3 步实现跨平台键鼠共享不用再买第二套键盘Input Leap 完整教程3 步实现跨平台键鼠共享不用再买第二套键盘 Input Leap 是一款跨平台的键盘鼠标共享工具用一套键鼠就能控制 Wind人工智能语音音频PaddleSpeech 特征归一化模块解析ZScore 频谱统计归一化与逆变换的实现与实战PaddleSpeech 特征归一化模块解析ZScore 频谱统计归一化与逆变换的实现与实战 导读 本文围绕 PaddleSpeech 中 paddlespe人工智能语音音频NLP媒体生成PaddleSpeech 英文 TTS 前端数字文本归一化paddlespeech.t2s.frontend.normalizer.numbers 模块深度解析PaddleSpeech 英文 TTS 前端数字文本归一化paddlespeech.t2s.frontend.normalizer.numbers 模块深度解人工智能语音音频NLP媒体生成创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
