T5-3.13.6版本AI玩具打开UI后播放音频时会有明显噪声

xdt_chen · 2026年 May 19日 16:52

用T5AI_BOARD_EYES的版型，在原来的版本3.13.3的时候也有这个问题，使能UI后，播放音频会有比较明显的噪声一起播放出来，把UI关闭后噪声就会消失，新版本3.13.6好像会好一些，但还是可以听到，播放声音的时候会有哒哒哒，嘎嘎嘎的噪声，不知道这个怎么优化，现在眼睛尺寸是160*160，噪声在关闭UI后会消失。

愚者千虑必有一得 · 2026年 May 19日 18:23

T5AI_BOARD_EYES + ENABLE_TUYA_UI 播放音频出现"哒哒/嘎嘎"噪声 — 根因与排查方案

我把 EYES 板的 LCD/音频驱动和 LVGL 渲染链路都过了一遍，现象（开 UI 才有、关 UI 消失、改 160×160 后噪声更密）非常典型，根因排序如下，可按优先级直接排查。

一、根因排序（按可能性）

1. SPI LCD 高频开关通过电源/地耦合干扰 T5 片内 AUD DAC 模拟前端（最可能）
T5 的扬声器/麦克风走的是 BK7258 内置的 AUD ADC/DAC（模拟域），不是 I2S：

Code: Select all

vendor/T5/tuyaos/tuyaos_adapter/src/driver/tkl_audio.c:206
onboard_spk_cfg.clk_src = AUD_CLK_APLL;   // 片内 DAC，模拟域

而 EYES 板的 SPI LCD 默认配置：

Code: Select all

apps/tuyaos_demo_wukong_ai/src/drivers/app_tuya_display/tdd_lcd_driver/src/spi/lcd_spi_st7735s.c:36
.freq_hz       = 48000000,    // 48MHz，已是 ST7735 上限
.spi_dma_flags = 1,           // DMA 大块传

开 UI 之后，LVGL 任务以 4ms 间隔不断把帧 DMA 到 SPI（128×128×2=32KB 每帧；改 160×160 后 51200B，刷屏数据 +56%），48MHz SPI 时钟+DMA 突发开关在 PCB 电源/地上产生周期性噪声，被 AUD DAC 的 AVDD/AGND 耦合进去 → 听感上就是与刷屏节拍同步的"哒哒哒"；改 160×160 后单帧 DMA 时间更长、噪声更密集，完全吻合你的描述。
关 UI 后整个 SPI 路径停摆，噪声立刻消失 — 这是电气耦合的强证据。

2. SPI DMA 与 AUD DMA 总线/中断争抢，导致 DAC FIFO 欠载（次可能）

Code: Select all

apps/tuyaos_demo_wukong_ai/src/miscs/gui/tuya_lvgl/src/tuya_app_gui.c:28
#define TASK_PRIORITY_LVGL 5            // BK/FreeRTOS 数值越大越高
vendor/T5/tuyaos/tuyaos_adapter/src/driver/tkl_audio.c:226
mic task_prio = 2, stack = 4096          // 比 LVGL 低

LVGL 优先级高于音频处理任务；SPI flush 是"提交 DMA → 信号量长等"模式（tal_display_spi.c:111-143），DMA 通道占用期间若与 AUD DAC 的 DMA 喂数发生总线饥饿，DAC 就会出现欠载 click。

3. APLL 共享干扰 — 基本排除
查 tkl_spi.c:390 仅在 #if CONFIG_SOC_BK7256XX（T2 平台）操作 APLL，T5/BK7258 路径不动 APLL，所以 AUD_CLK_APLL 不会被 SPI 拉走。

二、排查与解决步骤（建议按顺序逐项尝试）

Step 1 — 强力定位：播放期间暂停 LVGL 刷屏
代码里已有现成 API：

Code: Select all

apps/tuyaos_demo_wukong_ai/src/miscs/gui/lvgl/src/lvgl_v8/lv_vendor.c:202
void lv_vendor_stop(void);          // 停渲染任务
void lv_vendor_disp_lock/unlock();  // 持锁互斥
apps/tuyaos_demo_wukong_ai/src/miscs/gui/tuya_port/src/tuya_port_disp.c:275
void tkl_lvgl_pause(void);          // 暂停

在播音状态机切到 PLAY 时调用 tkl_lvgl_pause()，停止后调用 tkl_lvgl_resume()。
预期：噪声完全消失（与关 UI 等价）。这一步同时验证根因是 SPI 刷屏。

Step 2 — 降低 SPI 频率试听
把 lcd_spi_st7735s.c:46 的 freq_hz 从 48000000 改为 24000000 或 16000000，重新编译试听：

噪声明显减弱 → 电气耦合是主因，按 Step 4 处理硬件
噪声基本不变 → 主因偏向总线争抢，按 Step 3 处理软件

Step 3 — 软件层缓解（不动硬件）

降低 LVGL 任务优先级到 ≤ 音频任务：把 TASK_PRIORITY_LVGL 从 5 改为 2 或 3
限制刷屏频率：lv_vendor.c:151 的 sleep_time 下限从 4 改大到 20_33（3050FPS 降到 20_{30FPS），眼睛动画基本不影响观感}
降低色深/帧 buffer：把 LVGL 的 disp_buf_size 调小（如改成 1/4 屏分块刷），减少单次 DMA 突发时长

Step 4 — 硬件层根治（量产方案）
这是 T5 + 模拟音频 + 高频 SPI 屏的通用问题，软件只能缓解，量产板必须从硬件上隔离：

背光（GPIO25）和 SPK_EN（GPIO28）物理相邻，BL PWM 需独立 LDO 或 RC 滤波
AUD DAC 的 AVDD / AGND 必须用独立的 LDO 供电，不要和 LCD/MCU 数字 3V3 共网，AGND 单点接地到 PCB 数字地
SPK_EN 引脚串 100Ω + 1nF 简单 RC，避免 SPI 时钟串扰
LCD 排线远离 AUD 模拟走线和喇叭功放输入；如果可能，LCD SPI 时钟用串阻（22_33Ω）+ 包地处理
扬声器功放电源加 LC（10uH + 10uF）滤波

三、关于 3.13.6 比 3.13.3 略好的解释
3.13.6 对 LVGL 任务调度和 DMA 时序做了优化，争抢和软件突发减少 → 第二根因（DMA 争抢）影响减弱；但第一根因（电气耦合）只能靠硬件解决，所以仍然能听到。

四、快速自检清单

Step 1 加 lv_vendor_stop()/tkl_lvgl_pause() 验证噪声是否完全消失
Step 2 SPI 频率从 48M→24M→16M 三档试听
示波器抓 SPK_EN(GPIO28) 在播音时的电平/纹波，是否能看到与刷屏同步的毛刺
测 AUD DAC 的 AVDD 纹波，开 UI / 关 UI 对比
改 160×160 是否同步改了引脚？确认未占用 audio 模拟域的参考引脚

如果 Step 1 暂停 LVGL 后噪声完全消失，请回帖告诉我，可以进一步给出"播音期间智能暂停 UI"的整套状态机集成代码（在 wukong_ai_mode_*.c 切到 PLAY/TTS 状态时挂钩 lv_vendor_stop/resume）。

如果 Step 2 降频后明显改善，重点放在硬件电源去耦改造，软件保持当前帧率即可。

愚者千虑必有一得 · 2026年 May 20日 11:25

这里的降低lvgl线程优先级会比较有效。有客户240*240的双眼屏，优先级调低之后播放也正常了。

xdt_chen · 2026年 May 20日 13:54

实际上我烧录过以前旧版本的3.12.23版本固件到这个板子上，也是带一样的眼睛屏幕，旧版本就没有这个噪声。然后我把新版本的固件（3.13.6）烧录到你们的开发板上，也会有噪声。然后我按照你提供的步骤一，UI暂停后，噪声貌似少了很多，但仍然会有。

愚者千虑必有一得 · 2026年 May 20日 13:59

3.12.x版本，系统cpu的压力较小，你可以在日志口输入ap_cmd info来查看对比，有额外的新增算法、编码等能力，驱屏的框架差异也蛮大的。

愚者千虑必有一得 · 2026年 May 20日 15:56

感谢你补充的关键对比信息（3.12.23 同板无噪声 / 3.13.6 烧到我们开发板也复现 / tkl_lvgl_pause 后噪声大幅减少但残留），这等于把根因范围从“硬件本征 EMI”明显收窄到“3.13.x 引入的回归”。结合平台同事 25832/25834 的提示（降 LVGL 优先级有效 + ap_cmd info 看 CPU 压力），更新一下排查方向。

一、关键事实重排（按可信度）

同板 3.12.23 无噪声，3.13.6 有 → 排除 EYES 板硬件本征 EMI（电源/地走线一直没改）。
3.13.6 烧官方开发板也复现 → 排除单板硬件个体差异。
tkl_lvgl_pause 后噪声大幅减少但仍有残留 → SPI LCD 刷屏耦合是“次主因”，但不是全部；还有一条独立干扰路径在 3.13.x 自身。
降 LVGL 优先级也有效（同事 25832 实测 240×240 双眼屏 OK） → 间接证实 CPU/总线时序竞争是关键变量。

二、3.13.x 相对 3.12.23 的可疑变更点

3.13.x 相比 3.12.23 在音频/驱屏/系统侧确实做了几处会改变 DAC 取数时序的改动，按嫌疑排序：

A. AUD 子系统线程化与异步 buffer 改造

Code: Select all

components/svc_audio_pipeline/   （3.13.x 新增/重写）
components/tal_audio_subsys/         （tal_audio → svc_audio_pipeline 入口变化）

3.13.x 把音频送 DAC 的路径从“应用直推 tal_audio_play”改为多级 ringbuf + pipeline 任务调度。pipeline 任务和 LVGL 任务都跑在 OS 调度上，pipeline 任务被抢占的瞬间 DAC FIFO 就会欠载产生“哒哒”。这也解释了为什么“降 LVGL 优先级”立刻有效——pipeline 任务终于能稳定喂 FIFO。

B. CPU SMP 调度与新增编码/算法负载
同事 25834 提到的“额外的新增算法、编码等能力”。3.13.x 默认开启了若干 AI 后处理（NS/AGC/AEC 二级、TTS 解码线程、上传压缩等）。在 SPI 大块 DMA + LVGL 渲染同时跑时，pipeline 任务被挤到核 1 与中断争夺时间片。

Code: Select all

ap_cmd info  // 串口输入，对比 3.12.23 vs 3.13.6 的任务/CPU 占用

C. SPI LCD 驱动框架重写
3.13.x 的

Code: Select all

apps/.../tdd_lcd_driver/

引入了新的 buffer 调度和 TE 信号处理；DMA 大块传输的占空比比 3.12.x 明显升高（从单缓冲变成 2 段流水）。这就是关 UI 立即消失的直接证据。

D. APLL 共享路径已确认排除。

三、定位脚本（按这个顺序做，每步 ≤ 5 分钟）

步骤 1：先量化 CPU 压力差异
分别在 3.12.23 和 3.13.6 启动后、播放音频时执行：

Code: Select all

ap_cmd info

重点比对：

各任务 CPU% 排名（pipeline / lvgl / spi / audio_play 谁占比最高）
系统空闲率
是否有任务接近 100%

如果 3.13.6 下 svc_audio_pipeline 或 tal_audio 类任务 CPU% 没跑满但被频繁抢占，就指向调度问题；如果跑满，就指向算法负载问题。

步骤 2：直接复现“裸音频”基线（强烈建议先做）
不开 UI、不开 KWS/ASR/AEC，纯

Code: Select all

wukong_audio_play_local

一段本地音频：

如果还有“哒哒” → 不是 LVGL/SPI 问题，是 pipeline 自身
如果完全干净 → 锁定为 pipeline 在 LVGL 抢占下的 FIFO 欠载

步骤 3：把“3.13.6 → 3.12.23 行为”反向打开
3.13.x 默认开启的几个开关，逐项关掉验证：

Code: Select all

apps/tuyaos_demo_wukong_ai/include/tuya_app_config.h

#define ENABLE_AI_AUDIO_NS         0   // 关 NS
#define ENABLE_AI_AUDIO_AGC        0   // 关 AGC
#define ENABLE_TTS_PIPELINE_ASYNC  0   // 关 TTS 异步管线（如有）

Code: Select all

components/svc_audio_pipeline/include/svc_audio_pipeline_cfg.h
// 把 pipeline 任务优先级从默认值临时上调到 8 或 9（高于 LVGL 5）

哪个开关关掉之后噪声消失，就是该模块在 3.13.x 默认配置下与驱屏抢资源。

步骤 4：调度参数收敛
经过步骤 3 找到“敏感开关”后，组合应用同事建议的两条：

LVGL 任务优先级 5 → 3
pipeline / audio 任务优先级保持或上调 1 级
LVGL 最小 sleep 4ms → 10ms
保留必要的 UI，再听噪声。

四、推荐做法（迁移到稳定路径）

不建议：回退到 3.12.23 长期使用——3.13.x 在 wukong AI 关键能力上做了较多升级，回退会失去新能力。
推荐：留在 3.13.6，按上面“步骤 1_{4”定位到具体抢占点后，做最小补丁：}

pipeline / audio 任务优先级 ≥ LVGL（短期补丁）
默认开 LVGL 任务低优先级 + 长 sleep（系统级补丁，可写进
Code: Select all
```
apps/.../tuya_app_gui.c
```
）
量产板修改 AVDD 独立 LDO + SPK_EN/BL 时序隔离（长期硬件补丁）

五、需要你反馈的数据

请把以下三组日志发上来，我们继续锁定具体抢占点：

3.12.23 与 3.13.6 各自
Code: Select all
```
ap_cmd info
```
输出
步骤 2 的“裸音频基线”是否仍有噪声（重要）
步骤 3 中关掉哪个开关后噪声明显减少

附：相关源码引用

Code: Select all

components/svc_audio_pipeline/src/        // 3.13.x 引入，pipeline 任务
components/tal_audio_subsys/src/tal_audio.c   // pipeline 调用入口
apps/tuyaos_demo_wukong_ai/src/drivers/app_tuya_display/  // 3.13.x SPI LCD 框架
boards/T5AI_BOARD_EYES/board_config.c          // EYES 板音频/SPI 引脚
vendor/T5/tuyaos/tuyaos_adapter/src/driver/tkl_audio.c:206  // T5 内置 AUD DAC 配置

xdt_chen · 2026年 May 20日 17:51

1.步骤1：log 串口发送ap_cmd info，会log提示没找到命令。
2.不开UI,是确定没有噪声的。
3.没有这些开关，以及svc_audio_pipeline_cfg.h文件也没有。
我现在用的"DemoVersion": "1.0.46"，我尝试修改TASK_PRIORITY_LVGL到2，感觉没啥优化，反倒是我把屏幕spi时钟从30M改到60M噪声有明显的消除，但仍然有

愚者千虑必有一得 · 2026年 May 20日 18:12

你能联系到我们的fae吗？他们有搞过相关的case，你直接找他们处理一下，我们也处理过几个case，相关补丁他们都知道的。

愚者千虑必有一得 · 2026年 May 20日 19:03

你好，

从你描述的现象看，这个问题基本可以先按 UI 刷屏 / 显存搬运占用总线，导致音频 DMA/I2S 取数不连续 来排查。

你给出的现象有两个关键信号：

开启 UI 就有噪声，关闭 UI 噪声消失
3.13.6 比 3.13.3 略有改善，但没有完全消失

这说明问题大概率不是音频文件本身，而是 UI 与音频同时运行时的系统资源竞争，常见落点有：

LCD 刷屏带宽过高，和音频 DMA 抢总线
UI 刷新频率过高，持续占用 CPU / 内存带宽
音频 buffer 偏小，UI 抖动时更容易欠载，听感上就是“哒哒哒 / 嘎嘎嘎”
I2S / 功放时钟或走线本来就在临界状态，UI 打开后把边缘问题放大

建议按下面顺序验证：

1）先做最小变量实验

请优先做 4 组对比，确认是不是“刷新负载”直接相关：

关闭 UI：播放音频，记录是否完全无噪声
UI 打开但静态不刷新：只显示一张静态图，不做动画
降低 UI 刷新频率：比如从高频刷新改成低频刷新
减小分辨率 / 缩小刷新区域：160x160 全刷改成局部刷

如果“静态 UI 基本没问题、动画或高频刷新时噪声明显”，那就可以基本确认是 UI 刷新链路干扰音频实时性。

2）优先优化 UI 刷新负载

建议重点做下面几项：

A. 降低刷新频率

不要持续全屏高频刷；能事件驱动就不要定时全刷。

B. 减少全屏刷新

把 160x160 全刷改成局部刷新，只更新变化区域。

C. 降低颜色格式 / 带宽占用

如果当前 UI 使用的像素格式较重，尝试降低带宽占用；同时避免不必要的双缓冲搬运。

D. 避免播放音频时做复杂动画

音频播放阶段，先临时降低 UI 动画频率、粒子效果、频繁透明混合等操作。

3）增大音频缓冲，避免欠载

这类“有节奏的杂音 / 卡顿感”，很多时候不是 codec 解码失败，而是 播放 buffer 被 UI 抢占后供数不连续。

建议检查并适当放大：

音频播放 ring buffer
解码输出 buffer
DMA buffer / period 配置

验证方法：

保持同一份音频
只调大音频 buffer
如果噪声明显减轻，说明根因就是实时供数不足

4）检查任务优先级与绑核/调度

如果 UI 线程、解码线程、音频输出线程优先级接近，播放阶段容易被 UI 抢占。

建议：

提高音频输出相关任务优先级
UI 刷新任务优先级不要压过音频实时链路
如果平台支持，尽量把 UI 和音频处理分开，减少互相抢占

重点不是一味把所有任务都调高，而是保证：
音频输出链路 > UI 动画/刷新链路

5）做硬件侧交叉验证

因为你描述的是“明显噪声”，除了软件调度，也建议顺手排除硬件边缘问题：

关闭 UI 后是否 100% 消失
更换音量大小后噪声是否变化
更换功放供电 / 耳机 / 喇叭做对比
检查 LCD SPI / RGB 刷新时是否对音频模拟部分产生串扰
检查 I2S MCLK/BCLK/LRCK 与屏幕接口走线是否互扰

如果关闭 UI 后噪声完全消失，一般还是软件时序/带宽问题优先；
如果关闭 UI 后仍残留底噪，再去重点看硬件串扰。

6）针对你当前场景的建议结论

结合你给的信息，建议优先按这个顺序处理：

先把 UI 改为低频 + 局部刷新
播放音频时关闭复杂动画
增大音频 buffer / DMA buffer
提高音频链路任务优先级，降低 UI 刷新任务抢占
再做硬件串扰复核

如果方便的话，建议你再补充以下信息，我们可以继续帮你缩小范围：

UI 使用的是哪套显示驱动 / 刷新方式（SPI 屏还是其他接口）
播放本地音频和播放 URL 音频是否现象一致
噪声是在 播放瞬间开始 还是 只要 UI 开着就一直存在
当前音频采样率、声道数、bit 宽
是否有播放任务 / UI 任务的优先级配置

按目前现象看，优先方向不是 codec 本身，而是 UI 与音频链路并发时的带宽和实时性冲突。先从“降刷新 + 加 buffer + 调优先级”入手，通常是最有效的。