feat: 添加可配置的TTS音频发送延迟功能 #2357
feat: 添加可配置的TTS音频发送延迟功能 #2357
Conversation
kkroid
commented
Oct 14, 2025
kkroid
commented
- 修改 sendAudio() 函数，新增 tts_audio_send_delay 配置参数（毫秒）
- 0: 使用原有逻辑
- 大于0: 使用固定延迟发送（降低首包延迟，提升响应速度）
- 修改 sendAudio() 函数，新增 tts_audio_send_delay 配置参数（毫秒） - 0: 使用原有逻辑 - 大于0: 使用固定延迟发送（降低首包延迟，提升响应速度）
|
能说明一下降低首包延迟，提升响应速度的原理吗 |
|
我做了一个PC端的客户端，使用xiaozhi-esp32-server时发现播放卡顿严重，每个字都在卡顿（不仅仅是首包，而是每个包），最终分析到是服务端音频发送太慢了，客户端都播放完了服务端都还没发送过来。这里原来是60ms发送一帧音频数据，可能esp32处理比较慢，所以没这个问题。PC端处理比较快，所以在这里增加了一个固定时延 |
|
我理解和发送速度无关，因为xiaozhi本地有语音队列长度限制，没办法快速发送。 |
|
还是有关的，每次计算都可能产生微小误差，多个数据包后会累积，播放速度和发送间隔都是60ms，再累计一点计算时间，这样即使只有1ms的误差，都会产生1ms的静音帧。另外，补充一下，我这里客户端是一个流式音频播放器，收到音频立即播放，不会等收到所有音频之后才开始播放 |
|
所以你这个要有缓冲包的，不能收一帧就播放。音视频就需要缓存的。 |
|
缓冲包不能解决根本问题，对于长文本合成，随着时间的累积，缓冲包始终会被消耗完的。只有发送速度大于播放速度才能从根本上解决问题。另外一个方案就是一长段一长段的发送，比如按标点符号分割，当然这就改动比较大了。当前修改我在我本地验证已经消除了播放卡顿问题 |
|
如果不缓冲的情况下，即使按照固定速率发送，网络层面依旧可能出现卡顿。所以这个解决不了这个问题。如果本地性能够好，调整缓冲大小，能够解决绝大部分问题。 |
|
我认同你的说法，但是网络只要真的很卡，那就不可能有好的体验，无非就是等缓冲完了再播放还是等有一定量的数据才播放（后者就是xiaozhi-esp32-server当前实现和我的修改的情况）。我的修改优化的是本地音频消耗速度大于服务器发送速度的情况。这里附上我的环境信息：【基于windows + wsl开发，音频播放是流式音频播放，收到音频立即开始播放，服务器部署在本地wsl上的，客户端是运行在Windows C++客户端】，本地通信，理论上网络延迟非常小，所以在我的环境下，播放出现每个字都有轻微卡顿这个现象就和网络延迟基本无关了，这也是为什么我通过这种方式来加快服务器发送速度可以解决这个问题。当然我也尝试过增加缓存，但当时间长了之后，缓存就会被消耗完，就又会出现每个字都轻微卡顿的问题。另外，当前修改是与现有设计兼容的，只有配置了这个参数之后这个逻辑才会生效，个人认为可以入库，需要的人按需配置即可 |
3 participants
