實時聽寫的範例 demo2.py並不是真正的實時

[fumin]

實時聽寫要求每次 inference都只辨識最新 5秒的音頻，而不是回到最一開始的地方。

https://github.com/FunAudioLLM/Fun-ASR/blob/main/demo2.py#L32 每次都從音頻的第 0秒辨識，導致 inference花的時間越來越長，喪失實時的意義。

具體來說，demo2.py呼叫 load_audio時，應該帶入 offset的參數，使得每次 inference處理的長度都是 5秒。

[lihaopeng0928]

但是這樣會導致結果不准，還是需要根據經驗來設定滑動窗口的offset比較好

[fumin]

確實，不過 paraformer的實時窗口長度只有固定 0.6秒效果就不錯。
假如 Fun-ASR-Nano能夠參考 paraformer的窗口算法，加上本身更強的辨識能力應該會效果更好。

[zuxinqi]

可以设定offset，但是感觉切得很散，在切分的地方会导致结果变差，而且这个模型中间是一个llm，每一次只是encoder哪里进行了全部音频的编码(这里是可以gpu并行计算的)，在decode这里是有prev_text的传入的，其实decode不会增加太多耗时，llm主要的推理时延都在decode，这样做我感觉是合理的

[fumin]

每一次进行「全部」音频的编码

这完全不可行，这个复杂度是 O(n^2)，转 3分钟的音频已经要 10+分钟了。
我们会议长度超过一小时，会议后段每次(也就是 5秒钟的说话)岂不是要花72小时！？

[zuxinqi]

不是GPU跑的么，如果转 3分钟的音频已经要 10+分钟，那完全不要用流式了，速度也太慢了，我这边完成整个3分钟左右的音频的转录，整个推理时长在73s左右，这是没有推理优化的前提下，因为输出也是流式的，按照人的阅读习惯，这个延迟是可以接受的，还有会议这种超长音频，本身也要做vad的，这模型的encoder也不能支持那么大的音频输入吧

[fumin]

我們是用 CPU跑的，統一配的電腦是 Intel Ultra 5 225H (1.70 GHz)，Fun-ASR-Nano離線辨識速度還行，但實時聽寫就太遲鈍了。
反倒是 paraformer不知為何用這麼鳥的 CPU速度還能實時聽寫，不過辨識品質就較 Fun-ASR-Nano差劲許多。

假如 Fun-ASR-Nano能維持目前的高辨識質量，又能做到實時聽寫就太棒了！

[YuanJie2001]

参考vllm的funasr-nano项目如何