大屏 No Signal 后小屏卡顿：patch 线程睡太久

这篇写什么？

双屏电视上一种「看起来像解码卡、其实是音频线程拖后腿」的现象：

• 大屏 进入 No Signal（无信号）
• 小屏 再播视频 → 画面/声画卡顿

根因不在小屏播放器本身，而在 TV audio patch 输入线程 在无信号分支里 睡得太久，环形缓冲处理节奏被打乱。

一句话：

无信号 / tv_mute
  → patch 输入线程清缓冲后 usleep
  → 20ms 太长：醒得少、积得多、醒来连吐
  → 小屏卡顿
  → 改成 5ms：更勤检查、更少堆积

相关：TV HDMI-IN Patch 流程、ALSA period 与缓冲。

一、现象

大屏无节目时，patch 线程仍会跑「静音 / 无信号」分支；若这里节奏不对，会 indirectly 影响同进程里其它音频路径的调度与缓冲水位，小屏听感/观感就会发糊、发顿。

二、原因：无信号分支里 usleep(20ms) 太长

问题出在类似逻辑（示意）：

if (aml_dev->tv_mute || !check_tv_stream_signal(&in->stream)) {
    memset(patch->in_buf, 0, bytes_avail);
    ring_buffer_clear(ringbuffer);
    usleep(20 * 1000);   // 原来：每次循环睡 20ms
}

含义拆开看：

20ms 的问题：

1. 线程在无信号状态下 醒来频率偏低（大约 50 次/秒量级）
2. 其它路径仍可能往环里写、或共享调度资源
3. 线程长时间阻塞 → 缓冲侧更容易出现 滞留 / 水位异常
4. 一旦信号或路径恢复、线程连续跑起来，容易 短时间连吐堆积数据
5. 表现到小屏：播放发卡、声画不跟手

所以不是「清缓冲写错了」，而是 清完以后睡太久，处理节拍跟不上。

三、修复：20ms → 5ms

if (aml_dev->tv_mute || !check_tv_stream_signal(&in->stream)) {
    memset(patch->in_buf, 0, bytes_avail);
    ring_buffer_clear(ringbuffer);
    usleep(5 * 1000);    // 改为 5ms
}

usleep 单位是 微秒：5 * 1000 = 5000µs = 5ms。

改完后，无信号时仍会清缓冲、仍会休眠降载，但会 更勤地醒来看信号、维持环水位，避免「睡久了 → 积一堆 → 醒来连吐」。

四、为什么双屏更容易暴露？

单屏时，大屏无信号往往整机都闲着，卡顿不明显。
双屏时：

大屏 patch：No Signal → 长 usleep 空转
小屏：仍在播视频，需要正常音频/调度

两边共用 audio 服务与缓冲策略时，一侧睡太死，另一侧就更容易抖。把无信号空转从 20ms 收到 5ms，是很小的改动，但对「双屏各干各的」场景很关键。

五、调参时注意

六、小结

一句话：无信号时可以睡，但别睡到小屏都卡。

相关阅读

• TV 切到 HDMI-IN：Audio Patch 流程
• HDMI / Tuner Pop 音两招
• ALSA 音频缓冲区
• 抓 atrace 查看 CPU 占用