在我之前做语音采集相关的项目时，遇到系统的实时性问题。因为语音采集是整个流水线的起点------如果采集线程被延迟或阻塞，后续的所有处理（比如特征提取、模型推理、语音合成）都会跟着滞后，这种延迟不会被放大，但会直接破坏端到端的实时体验。
为了保障这一点，我把语音采集线程设为高优先级，并采用了 Linux 的 SCHED_FIFO 实时调度策略，而不是默认的 CFS（完全公平调度器）。这是因为：语音采集本质上是 I/O 密集型任务，它大部分时间其实在等待音频设备的数据（比如通过 ALSA），处于阻塞状态；一旦有新数据到达，它需要立刻被唤醒并处理，不能被其他计算密集型任务（比如大模型推理）抢占；而由于它运行时间很短、很快又会主动让出 CPU（回到阻塞状态），即使优先级很高，也不会导致其他线程"饿死" ------相反，它释放 CPU 后，计算线程就能立即接手做预处理或推理。
两种调度器的解释说明：
CFS (完全公平调度器)：每个任务按权重（基于 nice 值）公平分配 CPU 时间。使用 虚拟运行时间 来衡量公平性：每个 CPU 维护一个 红黑树，树节点按 vruntime 排序（左子树 vruntime 最小）。调度过程选择下一个任务：总是挑选红黑树最左节点（vruntime 最小，即"最欠 CPU"的任务）。
插入/删除：任务就绪时插入树中，阻塞或退出时移除。复杂度 O(log N)。无固定时间片：任务运行直到 vruntime 超过阈值被抢占，或自愿让出 CPU。
SCHED_FIFO (First-In-First-Out 实时调度策略)
使用优先级队，按优先级扫描最高优先级就绪任务。
调度过程：任务运行直到：自愿让出（yield）、阻塞（I/O 等）、或被更高优先级实时任务抢占。
同优先级任务：严格 FIFO 顺序，不互相抢占（当前运行的任务继续，直到让出）。实时任务总是抢占 CFS 等普通任务。应用场景：
硬实时或软实时任务：需要低延迟、可预测响应，如音频/视频处理、多媒体播放、工业控制、机器人、嵌入式系统。时间关键任务：例如实时数据采集、传感器处理，避免被普通任务中断。
