FunAudioLLM
流式推理总感觉有爆破音如何解决
流失推理，直接stream写入到pc扬声器，总感觉有破麦的那种声音，应该如何解决啊
https://github.com/user-attachments/assets/d675e682-b2bc-468f-b850-aa4bea0b396b
很大概率爆破音
@aluminumbox Thank you very much for your attention. Is there any estimated fix time for this?
flow模型流式合成就会有这个问题。你不用LLM，直接用GoundTruth的 speech token去走flow，得到的音频效果是一样的，一会爆一下。估计在流式两段端点处需要用什么音频平滑算法来处理一下。
我们用的最早版本的flow开放出来的版本， 流式合成固定长度50 speech token为一段，每一段得到的梅尔谱最终拼接起来，再走hift得到语音，是一段一爆的。 我们尝试了将每个speech token段两端延长，合成梅尔谱后再剪掉延长对应的部分，拼接回去，爆的问题也是没解决的。而且 延长的长度变长时，问题更严重了。
我们用的最早版本的flow开放出来的版本， 流式合成固定长度50 speech token为一段，每一段得到的梅尔谱最终拼接起来，再走hift得到语音，是一段一爆的。 我们尝试了将每个speech token段两端延长，合成梅尔谱后再剪掉延长对应的部分，拼接回去，爆的问题也是没解决的。而且 延长的长度变长时，问题更严重了。
更新一下代码，我们加了一些流式逻辑，先脚本方式合成看是否正常，例子里的爆破音不正常
最新的代码也不行。并没有解决爆破音。
另外，同意千问APP里面也是流式的，没有任何问题，应该算法是可以实现的。
是轻微爆破音，还是像上面mp4里的破麦声音一样？如果破麦音，我们这边并没有发现果这种情况，可以提个issue描述如何复现
最新的代码也不行。并没有解决爆破音。 另外，同意千问APP里面也是流式的，没有任何问题，应该算法是可以实现的。
是轻微爆破音，还是像上面mp4里的破麦声音一样？如果破麦音，我们这边并没有发现果这种情况，可以提个issue描述如何复现
应该是开始阶段是轻微爆破音，感觉跟音频质量有关系，低频谱的有问题
尝试了最新的代码版本，还是一段一顿，问题显著，不一定是破音。感觉音量，频谱，没有真正无缝拼接起来。
这个flow流式确实是拼不起来的，只是缓解问题。你可以试试非流式生成，看看两者差异。如果非流式本身就不好，那就跟流式没关系
另外我之前实验的，将流式segment 两端延长一部分合成后，再去掉延长后的mel帧，然后拼接合成，这种方法确实本质上是错误的。因为本来设计的是：由于S3的帧长为320样点，而mel谱帧长256样点，两者存在最小公倍数，使得4帧S3对应5帧梅尔谱。 所以一开始segment两端各延长4个speech token，合成后两端各去掉 5个 mel 帧； 这个效果，比直接分片流式合成效果略好，但是中间还是会存在问题。根本原因在于，S3的处理音频时16KHz的；而梅尔谱采样的时22.05KHz的，两者的采样率不同，没办法用样点数直接对接换算。猜想如果 hift也是16K的vocoder，flow也是16K的梅尔输出的话，这样的overlap模式流式合成可能会有显著的改进。
尝试了最新的代码版本，还是一段一顿，问题显著，不一定是破音。感觉音量，频谱，没有真正无缝拼接起来。
这个flow流式确实是拼不起来的，只是缓解问题。你可以试试非流式生成，看看两者差异。如果非流式本身就不好，那就跟流式没关系
我没有走前端webui，是用脚本，将Ground Truth的speech token，分成一片一片的固定长度的片段，走flow合成mel谱拼接，然后再走hift生成音频的，模拟流式过程。 真实的整个句子的speech token 直接【小于30秒的音频】直接走flow一次性合成，是没有问题的。
找到一种可以缓解问题的办法。
flow模型的生成跟整体上下文相关，stream模式给一整段speech tokens强制切分为一段一段的，割裂了自然语音中上下文信息，所以stream的各个segment最后拼起来是有边界跳音的。
尝试采用In-Context Pormpt模式进行stream合成。即：除了stream第一个segment之外，后续的各个segment合成时，均使用上一个stream步骤的 speech tokens以及对应生成的 mel spec片段，作为prompt参数输入到 flow推理函数接口，这样合成的结果拼接起来后，整体的效果要比之前sft直接分片合成好得多。
但是这种方法只是能缓解，没办法根治。合成的语音听起来，有些片段拼接处还是有显著的听觉跳变。
我是将音频直接写入到麦克风流里面，麦克风流逝播放音频是没问题的。
和上面视频效果一样，会有破麦声，怀疑可能是幅度突变，不太了解是否有解决方法，另外作者您所谓没有这种情况，流逝是如何播放的？
我是将音频直接写入到麦克风流里面，麦克风流逝播放音频是没问题的。
和上面视频效果一样，会有破麦声，怀疑可能是幅度突变，不太了解是否有解决方法，另外作者您所谓没有这种情况，流逝是如何播放的？
流式合成后拼接起来听，或者通过gradio webui听，如果没有问题，那么说明是播放器问题
chunk_bytes = chunk.cpu().numpy().tobytes()
buf = io.BytesIO()
buf.write(chunk_bytes)
buf.seek(0)
可以直接把数据转成bytes然后给到io，不用torchaudio.save，我这样做以后就没爆破音了
找到一种可以缓解问题的办法。 flow模型的生成跟整体上下文相关，stream模式给一整段speech tokens强制切分为一段一段的，割裂了自然语音中上下文信息，所以stream的各个segment最后拼起来是有边界跳音的。 尝试采用In-Context Pormpt模式进行stream合成。即：除了stream第一个segment之外，后续的各个segment合成时，均使用上一个stream步骤的 speech tokens以及对应生成的 mel spec片段，作为prompt参数输入到 flow推理函数接口，这样合成的结果拼接起来后，整体的效果要比之前sft直接分片合成好得多。 但是这种方法只是能缓解，没办法根治。合成的语音听起来，有些片段拼接处还是有显著的听觉跳变
这种方式生成时间会有明显增加吗
找到一种可以缓解问题的办法。 flow模型的生成跟整体上下文相关，stream模式给一整段speech tokens强制切分为一段一段的，割裂了自然语音中上下文信息，所以stream的各个segment最后拼起来是有边界跳音的。 尝试采用In-Context Pormpt模式进行stream合成。即：除了stream第一个segment之外，后续的各个segment合成时，均使用上一个stream步骤的 speech tokens以及对应生成的 mel spec片段，作为prompt参数输入到 flow推理函数接口，这样合成的结果拼接起来后，整体的效果要比之前sft直接分片合成好得多。 但是这种方法只是能缓解，没办法根治。合成的语音听起来，有些片段拼接处还是有显著的听觉跳变
这种方式生成时间会有明显增加吗
去学习cosyvocie2吧，这个版本的flow是支持流式合成的。 cosyvoice1的flow模型原生并没有直接支持chunk-aware