我发现使用音频服务器（在我的例子中是管道线），您可以改变“延迟”。 （请原谅我，我对这些东西不是很了解。）
PIPEWIRE_LATENCY="128/48000"
Arch Linux wiki 将其描述为“请求自定义缓冲区大小”。
我想知道，将延迟设置得非常低是否有“缺点”。仅仅是响应更快的音频就意味着更高的资源成本吗？
答案1
当缓冲区较小时，它会更快地填满并更快地清空。这就是延迟缩短的原因。
然而，将数据放入缓冲区和从缓冲区取出数据的进程会被更频繁地触发。因此，当您将缓冲区设置得太小时，您可能会发现音频软件对计算机 CPU 的消耗更高。在极端情况下，使用缓冲区较小的音频系统可能会使计算机上的其他软件响应速度变慢，或者可能“不稳定”或“口吃”，在平滑和冻结之间交替。
如果将音频数据放入缓冲区的进程无法足够快地响应并且缓冲区在短时间内完全变空，则小缓冲区也可能导致音频流卡顿。从缓冲区中取出音频数据并将其通过输出传递到扬声器（或耳机）的过程将耗尽数据，并且声音会出现中断（通常称为“丢失”）。
很难预测什么尺寸会“太小”，因此您可能必须进行试验，看看哪种折衷方案可以在不影响音频流和计算机其他部分的情况下实现最短的延迟。
答案2
无论您的声音应用程序 (A)、声音服务器 (B)、alsa 声卡驱动程序 (C)：
- (A) 将（按照自己的速度 PA）将样本写入某个缓冲区，
- (B) 将（按其速度）读取，以便将它们（按其速度）写入某个缓冲区，
- 声卡的中断处理程序将（以 PC 的某个速度）读入硬件声卡的通常固定大小的非常小的缓冲区，
- 嵌入式软件将读取这些数据，以便以非常精确的速度回显到硬件输出。
从这种工作方式你可以理解：
- 只是没有办法（立即）”设置延迟“。（可以理解为从（A）输出样本到硬件输出该样本所花费的时间）。因此......不可能有任何“将延迟设置得非常低的缺点”
- 需要缓冲区是因为进程中涉及的不同组件异步工作，因此缓冲区大小必须考虑到某些（？）有时某些上游组件将比紧随其后的组件输出更多（或更少）的样本将能够立即处理。
从上一段中，就缓冲区而言，您可以理解：
如果缓冲区尺寸过小，因为这些很可能是环形缓冲区……您可能会面临：溢出！
这意味着样本永远不会进入硬件输出，这将转换为可听的声音。
所以是的！减小缓冲区大小确实有一个缺点：超支。
当然，有一些方法可以降低超限的风险： 让流程运行：以正确的速度！
如果您可以使下游组件能够及时完成其工作（或者以比上游组件更快或相同的速度），那么无论缓冲区大小如何，您都可以避免溢出的风险。
- 首先确保 irq 是线程化的，并且与声卡关联的内核线程的实时优先级是最大的。
- 接下来应该是在某种实时调度模型下运行的任何声音服务器，其优先级立即低于上述 irq 内核线程的优先级。
- 最终，上游应用程序也在实时调度模型下运行，其优先级低于声音服务器的优先级。
您也可能（正确地）认为具有两个缓冲区的声音服务器成本高昂（就额外的延迟而言）并且可能......没有任何作用并且......考虑摆脱它。