T5_3.13.6版本更改本地提示音，导致开机变缓、log卡死

[Ann]

T5_3.13.6版本，我添加了“ 联网成功 ”本地提示词(音频>3s)，导致开机联网成功播报从7秒变成12，且发现log在运行到第7-9秒时会卡死，程序运行也会受到一点定影响卡顿。后续经验证log卡死不是由本地提示音导致的，麻烦看看什么原因谢谢。
添加本地提示词代码如下：

case AI_TOY_ALERT_TYPE_NETWORK_CONNECTED:
{
audio_data = (CONST CHAR_T*)media_src_network_conn_success_zh;
audio_size = sizeof(media_src_network_conn_success_zh);
break;
}

[愚者千虑必有一得]

你好！

问题概述

添加"联网成功"本地提示音(>3s)后，开机播报从7s变12s，log在第7-9秒卡死。

根因分析

经代码排查，这不是本地提示音本身的问题，而是事件分发机制导致的阻塞：

调用链：

1. 联网成功 → ty_publish_event发布EVENT_AI_CLIENT_RUN事件
2. 事件的subscriber回调__ai_client_run_evt在event->mutex保护范围内同步执行
3. 回调中调用tuya_ai_output_alert(AT_NETWORK_CONNECTED)
4. 最终在mutex持有期间同步完成>3s的MP3解码+音频输出(lite_player_feed)
5. event->mutex被长时间持有，其他需要ty_publish_event的操作（包括log输出相关的dispatch）被阻塞

所以log卡死的本质是：事件mutex被音频同步播放长时间持有，阻塞了所有后续事件分发。即使用默认dingdong提示音也存在同样问题，只是阻塞时间短不明显。

关键代码路径：

• tuya_ai_agent.c:1145 — 同步调用tuya_ai_output_alert
• base_event.c:326 — ty_publish_event在mutex下同步dispatch
• svc_ai_player_lite.c:220 — lite_player_feed同步解码+写音频输出

解决方案

方案1（推荐）：将alert回调中的音频播放改为异步执行
修改位置：wukong_provider_tuya.c的tuya_alert_cb
在tuya_alert_cb中通过消息队列或独立线程异步投递播放事件，使alert_cb快速返回释放事件mutex。

方案2：将同步feed改为异步feed模式
修改位置：wukong_audio_player.c的wukong_audio_play_data
将同步feed改为异步模式：先start+feed首帧，剩余数据通过定时器或音频回调逐步feed，避免调用线程长时间阻塞。

验证方法

修改后开机联网成功播报时，log输出不再卡死，程序运行流畅。