FunAudioLLM
处理音频时出现内存/闪存跑满，导致进程崩溃的问题。
What is your question?
在使用 FunASR 处理音频文件时，发现部分格式为 .m4a 或 .mp3 的音频文件会直接导致设备的显存（GPU 内存）或内存（RAM）被完全占用，进而引发程序进程崩溃。但这些 “问题音频” 通过人工使用常规音频播放软件打开时，能够正常播放，未发现音频本身存在损坏、无法读取等明显问题。请问导致该现象的可能原因是什么？如何解决此类因音频处理导致显存 / 内存跑满并崩溃的问题？
What have you tried?
1、验证问题音频的完整性：使用多个主流音频播放软件（如 Windows Media Player、PotPlayer、VLC）打开问题 .m4a 和 .mp3 文件，均能正常播放，未出现卡顿、无声、文件损坏提示等问题，排除音频文件本身无法正常读取的基础问题。 2、测试非问题音频：使用相同的代码和环境处理其他同格式（.m4a、.mp3）的音频文件，大部分文件能够正常完成处理，未出现显存 / 内存异常占用，仅特定部分音频触发该问题。 3、切换运行设备：尝试将代码中 device 参数从 “cuda” 改为 “cpu”，处理问题音频时仍会出现内存（RAM）跑满并崩溃的现象，并非仅局限于 GPU 显存问题。 4、检查音频文件属性：对比 “问题音频” 与 “正常音频” 的基础属性（如时长、采样率、比特率、声道数），未发现明显规律（例如问题音频并非均为超长时长或超高采样率，部分短时长音频也会触发问题）。 5、升级相关库版本：尝试将 FunASR、ModelScope、PyTorch 等核心依赖库升级至当前最新稳定版本，重新运行代码处理问题音频，显存 / 内存跑满崩溃的问题仍未解决。 6、使用linux系统部署项目仍然现类似问题。
demo1.py里的vad配置完就会先用vad把音频分段。分完了再放到设备上转录，可避免oom问题。demo1.py里的model.generate(batch_size_s, batch_size, merge_vad, merge_length)这几个参数可以调整每个batch放到设备内存推理的时长(batch_size_s)和batch_size,我试过不会再oom.但demo2.py无此类示例，我还在研究。
