首先，咱们来拆解你遇到的延迟累积问题，核心原因主要集中在播放设备的ALSA参数配置和欠载后的恢复逻辑上，结合你的场景具体分析：

一、播放端参数的不合理设置是延迟累积的核心 #

从你给出的播放设备配置可以看到两个关键参数：

• start_threshold: 384（等于播放缓冲区总大小）
• stop_threshold: 384（同样等于缓冲区大小）

这两个参数的作用是：

1. start_threshold：只有当播放缓冲区被填满到这个帧数时，ALSA才会启动播放。你设置成了整个缓冲区的大小（384帧），意味着每次欠载恢复后，你需要连续调用3次snd_pcm_writei()（每次写128帧）才能触发播放——这期间你已经捕获并处理了3个周期的音频，等于播放的是3个周期之前的数据，直接增加了约4ms的延迟。
2. stop_threshold：当播放后剩余的可播放帧数低于这个值时，ALSA会停止播放流。你设置成了缓冲区大小，意味着只要缓冲区的数据被播放完（剩余0帧），就会触发停止，进而产生EPIPE欠载。这种设置会让播放流非常“脆弱”，稍有延误就会断流，而每次断流后的恢复又需要重新填满缓冲区，延迟自然会不断叠加。

二、单线程+非实时环境的放大效应 #

你在常规Ubuntu 16.04桌面环境运行，没有配置低延迟内核或实时调度，音频线程很容易被桌面进程（比如窗口管理器、浏览器）抢占。一旦抢占导致snd_pcm_writei()错过硬件的播放时机，就会触发欠载；而每次欠载后的缓冲区填充逻辑又会进一步增加延迟，多次累积后就变得可感知了。

另外，捕获端的缓冲区大小（4096帧）远大于播放端（384帧），当处理播放欠载的耗时里，捕获端一直在读取音频数据到自己的缓冲区，虽然snd_pcm_readi()没有报错，但这些积累的旧数据会被后续依次处理播放，也会让延迟越来越大。

三、你的操作误区 #

你调用snd_pcm_recover()后只丢弃了当前被拒绝的周期，但没有同步调整播放的启动条件，也没有处理捕获端积累的旧数据，导致每次恢复后都需要等待缓冲区填满才能播放，同时还在播放之前积累的捕获数据，延迟自然持续增加。

四、具体解决方案 #

1. 调整播放端的关键参数 #

修改播放设备的start_threshold和stop_threshold，让播放流更“灵活”：

snd_pcm_sw_params_t *sw_params;
snd_pcm_sw_params_malloc(&sw_params);
snd_pcm_sw_params_current(playback_handle, sw_params);

// 设置start_threshold为周期大小，填充一个周期就启动播放
snd_pcm_sw_params_set_start_threshold(playback_handle, sw_params, 128);
// 设置stop_threshold为缓冲区大小+周期大小，避免轻易停止播放
snd_pcm_sw_params_set_stop_threshold(playback_handle, sw_params, 384 + 128);

snd_pcm_sw_params(playback_handle, sw_params);
snd_pcm_sw_params_free(sw_params);

这样调整后，欠载恢复后只要写入128帧就能立即启动播放，不会再等待填满整个缓冲区，从根源减少延迟累积。

2. 给音频线程设置实时优先级 #

在Ubuntu中，可以通过设置线程调度策略为SCHED_FIFO来提升音频线程的优先级，减少被抢占的概率：

#include <pthread.h>

struct sched_param param;
param.sched_priority = 10; // 中等优先级，不要设太高避免影响系统
pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);

注意：运行程序需要CAP_SYS_NICE权限，可以用sudo运行，或者给程序设置权限：sudo setcap cap_sys_nice+ep your_program。

3. 欠载恢复时同步捕获与播放 #

当发生EPIPE时，除了恢复播放流，还应该清空捕获端的积累数据，避免播放旧数据：

int err = snd_pcm_writei(playback_handle, buffer, 128);
if (err == -EPIPE) {
    // 恢复播放流
    snd_pcm_recover(playback_handle, err, 0);
    // 清空捕获端的缓冲区，丢弃积累的旧数据
    snd_pcm_drop(capture_handle);
    // 重新启动捕获
    snd_pcm_prepare(capture_handle);
}

这样可以让捕获和播放重新同步，避免播放之前积累的延迟数据。

4. 对齐捕获与播放的缓冲区大小 #

把捕获端的缓冲区大小调整为和播放端接近（比如都设为384帧），这样捕获和播放的节奏更匹配，减少数据积累的概率。可以在设置捕获设备参数时调整：

snd_pcm_set_params(capture_handle,
                   SND_PCM_FORMAT_FLOAT_LE,
                   SND_PCM_ACCESS_RW_INTERLEAVED,
                   1,
                   96000,
                   1,
                   1333); // period_time=1333us，对应128帧，buffer_size会自动计算为3*128=384

内容的提问来源于stack exchange，提问作者user6369958