我正在使用 RT 内核的多核 (Debian) Linux 机器上开发音频应用程序。音频源生成需要大量的处理时间，单核无法处理，所以我有三个不同的线程:
- 核心 0 上运行的主 portaudio 线程
- 在核心 1 上运行的第 1 代源代码
- 在核心 2 上运行的第 2 代源代码
线程 2 和 3 正在写入环形缓冲区，而线程 1 正在从环形缓冲区读取数据并将其求和到端口缓冲区。
我尝试了许多缓冲区大小和调度策略，我最好的结果是 FIFO 策略，音频缓冲区大小为 16 个立体声样本，环形缓冲区大小为 576。此解决方案产生超过 13 毫秒 (576/44100*1000) 的延迟，这太多了。
我确信可以减少这种延迟，但我不是 Linux 调度方面的专家。有什么想法吗？
最佳答案
只要您将流程的 RT 优先级保持在核心上高于任何其他流程，该政策就无关紧要。
确保将任何其他应用程序踢出用于 RT 的内核(例如使用 isolcpus= 内核 cmdline 参数)。否则，低优先级进程会触发 I/O，这将阻塞您的 RT 线程。您还应该将您的应用程序不关心的所有中断分配给未使用的内核。实际上，在您的情况下，我建议将 core0 用于正常任务，将 core 1、2、3 用于 RT，因为由于 core0 是引导 CPU，它将必须执行一些特殊的内务处理任务。
按照上述方法对系统进行分区后，请尝试使用延迟测量工具找出导致延迟的原因。谷歌搜索 linux rt latency trace 会给你很多有用的链接。这是基本的:http://people.redhat.com/williams/latency-howto/rt-latency-howto.txt
如果事实证明某些内核处理正在阻止您的应用程序，您可以通过查看此处的内核线程描述找到解决方案:http://lxr.free-electrons.com/source/Documentation/kernel-per-CPU-kthreads.txt
您绝对应该能够低于 2 毫秒。
关于linux - 多核Linux系统上的实时音频，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29863321/