T5_3.13.6+CI1302串口音频传输方案，在随意对话AI_CHAT_DEFAULT_FREE模式下存在的bug。

[Ann]

1.经常需要说两次才能语音打断。查看log发现:说第1次时听懂并正在回复，但喇叭没出声且一直处于监听状态；说第二次时重新听懂并回复，这时喇叭才播放出来。
2.经常在语音打断回复后，播放打断前的回复0-0.3秒左右，再继续回复新的对话。现象就是每次回复前都会卡一下再继续回复。
3.容易自己回复自己的对话，喇叭和麦克风已经背对朝向并间隔3cm的距离。硬件使用的是1302的开发板，上面有回声消除的电路，1302的程序是涂鸦内部提供。使用板载音频方案，不使用UART音频时，就算把麦克风和喇叭贴到一起也不会出现自问自答。
上述1、2点问题已复现，T5和1302的log放在下面

[愚者千虑必有一得]

你好！

问题概述

T5+CI1302 UART音频方案在AI_CHAT_DEFAULT_FREE模式下存在三个bug：语音打断需说两次、打断后残留旧音频、容易自问自答。

根因分析

经代码排查，UART音频方案(wukong_audio_input_uart.c)相比板载方案(wukong_audio_input_board.c)存在三个关键实现缺陷：

Bug1：语音打断需说两次
wukong_audio_input_uart.c的wakeup_set(TRUE)函数中，is_wakeup=TRUE时仅调用了tdl_comm_audio_voice_cfg_set_mic(TRUE)开启mic，但未调用set_vad(TRUE)和set_wake(TRUE)重新开启VAD和唤醒检测。对比__RESET_CB中同时设置了vad/wake/mic三个开关。从SPEAK回到LISTEN时VAD未重新开启，导致第一次说话无法被VAD检测到，需说第二次触发。

Bug2：打断后播放残留0-0.3秒旧音频
打断流程wukong_ai_free_wakeup()中发送SPK_STOP命令时，未清空CI1302端已接收但未播放的音频缓冲区。CI1302继续播放残留的旧数据后再播放新TTS，表现为"卡一下再继续"。

Bug3：UART方案下自问自答
UART方案的__MIC_STATUS_CB中VAD状态回调缺少wakeup_flag播放状态检查。CI1302内部AEC在UART模式下效果不足（缺少硬件回采回路），喇叭播放时mic误检VAD_START导致自问自答。板载方案通过硬件回采回路做AEC和wakeup_flag软件抑制双重保障，UART方案两者均缺失。

解决方案

方案1：修复UART音频输入状态恢复不完整及VAD抑制逻辑
修改文件：wukong_audio_input_uart.c
1) wakeup_set(TRUE)中补充tdl_comm_audio_voice_cfg_set_vad(TRUE)和tdl_comm_audio_voice_cfg_set_wake(TRUE)，与__RESET_CB保持一致
2) reset()中补充set_vad(TRUE)和set_wake(TRUE)
3) __MIC_STATUS_CB中增加类似板载方案的wakeup_flag检查，在SPEAK状态下抑制VAD_START事件

方案2：打断时清空CI1302端音频缓冲区
修改文件：tdl_comm_audio.c
在发送SPK_STOP命令前，先发送MUTE指令给CI1302，确保CI1302端丢弃已接收但未播放的音频数据，避免残留音频播放。

验证方法

1) UART方案下测试语音打断，验证说一次即可打断
2) 打断后听是否还有残留旧音频
3) 播放TTS期间对麦克风说话，验证不会触发自问自答

以上分析基于代码排查，供参考。