78
使用websocket在网络不好的情况下了，会消耗完内存导致系统崩溃或卡死
Answers checklist.
- [x] I have read the documentation XiaoZhi AI Programming Guide and the issue is not addressed there.
- [x] I have updated my firmware to the latest version and checked that the issue is present there.
- [x] I have searched the issue tracker for a similar issue and not found a similar issue.
XiaoZhi AI firmware version.
1.5.6+
Operating System used.
Windows
How did you build your project?
Command line with CMake
If you are using Windows, please specify command line type.
None
Power Supply used.
USB
What is the expected behavior?
网络不好的时候应该提示，不应该发生崩溃
What is the actual behavior?
导致系统崩溃或卡死
Steps to reproduce.
在聆听中移动到距离WiFi稍远的地方
Debug Logs.
More Information.
音频读取和发送在两个线程中，处于聆听中时一直会向main_loop添加SendAudio的task，一旦网络不好mian_loop处理SendAudio会阻塞，则会导致tasks堆积过多，最后内存消耗完
调试发现 SendAudio 的 opus 一直是 1500 字节，已更新版本修复这个问题。 参考：https://github.com/78/esp-opus-encoder/commit/531a04312101814a5ccc99db7b313fbf618e1ef7
@78 看着应该还是没有解决吧，SendAudio一旦阻塞，OnAudioOutput还是会一直推tasks，内存还是会消耗完
抱歉，我只是把1500的opus数据包改小了，这次才真的改了。加了一个busy的状态。
https://github.com/78/xiaozhi-esp32/commit/f76f31aa126028029e60e28b25bd18f07acda13f
PS，我发现esp32的udp socket的send函数，是阻塞的，会从1ms到500ms之间波动，这才是堆积tasks的罪魁祸首。
我觉得有点不妥，因为目前是一直在ReadAudio的，只要一点阻塞就会丢弃，这样会导致音频断续严重， 尽量还是设置一个buffer吧，这样较小的网络波动不会找造成断续
我觉得有点不妥，因为目前是一直在ReadAudio的，只要一点阻塞就会丢弃，这样会导致音频断续严重， 尽量还是设置一个buffer吧，这样较小的网络波动不会找造成断续
不用担心，
- audio codec 本身自带 buffer 的，本次不读取，下一个 timing 也能读取到。
- 偶尔丢失一个小片断，对 ASR 大模型的识别效果影响不大。
主要你目前不是不读取，是每次都读，应该把繁忙的判断放在ReadAudio上
好像有道理哦！！
1.5.x为了实现 AEC 功能，增加了一个 audio 任务，才导致了这个问题。在之前的版本中，audio io 和 network io 都是在 main 任务下的，所以 network 阻塞会导致 audio io 有所 delay，但不会爆内存。 后来为了流畅跑 AEC （会吃掉一整个CPU的性能）才把 audio io 独立了一个任务。
感觉目前的修复还是不能根本解决问题， 只是简单的判断是不是busy，内存浮动还是很大 在某些时机下，如果每次读的时候刚好不busy，读完就busy，慢慢的tasks还是会堆积的 没有明确的限制，在内存不宽裕的板子的，迟早要出问题的
感觉目前的修复还是不能根本解决问题， 只是简单的判断是不是busy，内存浮动还是很大 在某些时机下，如果每次读的时候刚好不busy，读完就busy，慢慢的tasks还是会堆积的 没有明确的限制，在内存不宽裕的板子的，迟早要出问题的
暂时来说比之前发布的1.5.6好很多，至于如何更优雅，可以再想办法？设置一个buffer也是要消耗sram的，目前来说C3只能说是勉强支持，推荐还是用S3，后续能力的扩展性更好。