liuwenchang

这个我测试发现wpf 里只要加image控件就会这样，wpf本身框架问题，https://github.com/dotnet/wpf/issues/2397，可以这样规避这个问题 在ImageViewer.cs里，加函数 `public void ResetImageMain() { ImageSource = null; _imageMain.Source = null; _imageMain.UpdateLayout(); }` 在ImageBrowser.cs里覆盖Close函数 `public new void Close() { _imageViewer.ResetImageMain(); base.Close(); }`

你下个arm不就行了，onnx那个库也得下个arm，https://github.com/BtbN/FFmpeg-Builds/releases/download/autobuild-2023-11-30-12-55/ffmpeg-N-112876-ga30adf9f96-linuxarm64-gpl-shared.tar.xz

不止是额外参数重复，location 里很多路径都重复了，问题很严重，要挨个对比修改

当这个反向代理多了之后，点击提交就会卡主，卡的时候，多点了几次提交，就会location重复。这是个很严重的bug

模型精度问题，funasr-export ++model=“modelPath” ++quantize=true，可以导出量化后的onnx

具体怎么修改一下，能否说一下？

 @locasxe 哥，是不是这个地方

测了了两天，把这个改了还是不行，还是有概率触发死循环

> 每个会话结束了，会发送is_final=True，应该就不会触发这个问题了吧~ 改一下源码也可以，int 溢出了，他有个总长度的int，一直发数据，长度在累加，超过大概18个小时，int就溢出了。改成long 可以无限一直发下去

> > > 每个会话结束了，会发送is_final=True，应该就不会触发这个问题了吧~ > > > > > > 改一下源码也可以，int 溢出了，他有个总长度的int，一直发数据，长度在累加，超过大概18个小时，int就溢出了。改成long 可以无限一直发下去 > > 不改int时，感觉会一直上涨，但将int改为long后，目前能看到内存回落了，比较神奇~ 很奇怪的就是data_buf_all_size难道不是当前session有效吗？（比较奇怪~） 这个内存问题很大一部分是因为你音频发送的速度过快，那个存储任务的vector队列会一直扩大，当你任务消耗完了，vector也不会往自动变小，好像是asio 那个框架问题。长度改成long应该是解决不了内存不断增加的问题。你试试循环不间断发音频，中间不要sleep，内存会一直扩。