Audio ALSA阈值、可用时间和周期之间有什么区别？

我正在四核debian盒上进行ALSA捕获例程，对此我感到困惑

基本ALSA捕获，hw:0接口，16位，44.1 KHz，使用带poll（）的阻塞线程，由

snd\u pcm\u start（）和
snd\u pcm\u drop（）控制。我检查所有ALSAAPI调用的返回值。基本捕获工作正常，但我无法确定如何设置轮询速率（即ALSA通知我的poll（）例程返回的频率，因为帧可以读取）

我使用
snd\u pcm\u sw\u params\u set\u avail\u min（）
将此设置为2048帧，当大约有2048帧可读取时，poll（）返回。在调用
snd\u pcm\u avail\u delay（）
之前，我调用了
snd\u pcm\u readi（）
，这一切看起来都很合理。但如果我将其设置为小于2048的任何值，就会得到不一致的结果。如果我将avail_min设置为1024，则poll（）会在大约有1024帧可用时返回一半时间，而只有1500帧可用时才会返回一半时间。当我将avail_min设置为512时，第一次读取是512，但随后95%的读取是1024帧或更大。当我调用
snd_pcm_hw_params_get_period_size_min/max（）
时，此设备报告的有效范围为16-8192帧，因此512帧的周期似乎并不合理——驱动程序报告硬件支持它

我尝试了
snd\u pcm\u sw\u params\u avail\u min（）
，
snd\u pcm\u hw\u params\u set\u period\u size（）
和
snd\u pcm\u sw\u params\u start\u threshold（）
，但仍然无法实现
得到合理的结果

我已经尝试用pthread setaffinity将这个线程固定到一个CPU内核上。我尝试了
sched_setschedule（）
为流程提供“软”实时优先级。除了将avail_min设置为至少2048之外，似乎没有任何东西允许我获得一致的poll（）返回

下面是一些ALSA问题：

启动阈值（使用
snd\u pcm\u sw\u params\u set\u start\u threshold（）
是否仅与异步相关
捕获？也就是说，开始阈值似乎不适用于基于poll（）的捕获。是这样吗
对吗

以帧为单位的周期大小与以帧为单位的可用最小大小之间有什么区别？
文档似乎暗示avail_min设置了轮询（）的点将返回，因为至少有那么多帧可读取。时段大小是一个hw参数，但API仍然提供了一个最小值和最大值以及设置它的方法。在我看来，它们实际上是一样的，但我无法让poll（）根据我设置的时段返回

当我解释
snd\u pcm\u sw\u params\u set\u avail\u min（）
设置触发poll（）例程的可用捕获帧的目标数量时，我是否误读了文档

对于我来说，期望poll（）的返回比在500到1500帧之间的任何时候都更一致是合理的吗？或者这是正常的行为，我应该期望在可读取的帧数上有很大的变化吗

如果预计会有很大的变化，那么最好总是读取由
snd\u pcm\u avail（）
报告的总可用帧，还是每次poll（）返回时读取一组帧数

开始阈值对于捕获设备没有多大意义；只需将其设置为1即可

硬件不断地填充捕获缓冲区，但仅在每个周期结束时引发中断。
当ALSA等待某些数据可用时（在轮询或snd_pcm_read*中），在可用最小帧可用之前，ALSA不会返回。但是，此检查仅在函数开始时或在中断唤醒时进行

因此，如果您不想等待太长时间，您必须使周期长度足够短。
仍然对第5项的答案感兴趣。。。