如果在应用层不依赖chat_break来结束对话，是可以消除“卡死”感，但是如何解决以下问题： 1、用户再次尝试对话怎么办？chat_break的阻塞堆积在某个任务里面？ 2、云端依旧有可能在不确定的时间段继续返回TTS，开始回复已经结束的对话。经测试有时候阻塞非常之久。 本次AI回复与我所分析的不同，因为实际阻塞时间不固定，测试中最长的时候四五分钟都有，不得不重启产品，所以怀疑底层是有无限等待的阻塞存在，麻烦分析一下chat_break完整的调用链路，确保有超时、报错返回。 这边已经使用过DeepSeek分析 以下是AI分析出来的完成调用链路： _hly_ai_idel() / _hly_a...

当网络环境较差时，调用wukong_ai_agent_chat_break阻塞非常严重。 以下是进入待机模式的代码，需要wukong_ai_agent_chat_break让云端不再返回消息，每一步都做了日志。 STATIC VOID _hly_ai_idel() { TAL_PR_DEBUG("===idel 01"); wukong_ai_agent_output_stop(TRUE); TAL_PR_DEBUG("===idel 02"); wukong_audio_player_stop(AI_PLAYER_ALL); TAL_PR_DEBUG(...

您好，在tkl_ao_put_frame函数加入超时代码后，第二天依旧有出现无声的现象。 tkl_ao_put_frame函数代码如下： OPERATE_RET tkl_ao_put_frame(INT32_T card, TKL_AO_CHN_E chn, VOID *handle, TKL_AUDIO_FRAME_INFO_T *pframe) { OPERATE_RET ret; if (pframe == NULL) { return OPRT_INVALID_PARM; } if (!s_audio_init.audio_init || !s_audio_init.audio_sta...

测试比较久才能复现问题，基本都是需要挂机一晚上，第二天唤醒就会出bug，我们是10pcs样品一起测试，出问题可能就一两台，日志没有办法记录那么多。 产品确实是多线程在操作player，但是都有加锁，除非是在一些wokong的代码里面又异步操作了player。 而且现在明显队列满了，处理消息的线程卡死了，这个才是根本原因 ，处理消息的线程跟我们变更player的状态没有关系，为什么会卡死，我深挖底层代码，在tkl_audio.c里面发现了一段可能的死循环： OPERATE_RET tkl_ao_put_frame(INT32_T card, TKL_AO_CHN_E chn, VOID *han...

日志如下： [06-30 10:16:02:881 ty N][0x60c05bf0][wukong_audio_input_board.c:313] wukong audio input -> reset ringbuf! [06-30 10:16:02:881 ty N][0x60c05bf0][wukong_audio_input_board.c:320] wukong audio input -> vad stop! [06-30 10:16:02:882 ty N][0x60c05bf0][wukong_audio_input_board.c:323] wukong audio in...

现在修复卡死问题后，出现了没声音的现象，播放提示音和AI对话都没声音了。

我把stop和start的超时时间全部改成了1秒，挂机一晚上后，第二天唤醒时播放唤醒提示音没有声音，刚开始有卡顿1秒，大约是超时了，后续没有出现卡顿了。

没接日志能判断还有哪里有问题吗。

这是3.13.3中的