06 Period 尺寸、中断成本与尾延迟¶
1. 先明确模型边界¶
N 表示每 period 的 frame 数，一 frame 包含全部声道。假设每 period 恰好通知一次，没有中断合并、轮询或额外唤醒：
通知频率 = fs / N，单核固定开销占比 = fs / N × t_context。
t_context 是每次通知引起的 CPU 实际执行时间，不是从中断到用户线程运行的全部墙钟延迟；线程等待 CPU 的时间不能当作 CPU 占用相加。真实驱动未必经过 tasklet，也未必每次唤醒都导致上下文切换。
2. 参数敏感度：固定通知成本¶
以下全部为 48 kHz 下的计算示例，3/10/30 µs 是假设值，不是 ARM64 实测常数。百分比以单个 CPU 核的一秒执行预算为分母，不含解码、拷贝和 DSP 算法。
| N（frame） | period 时长 | 通知/秒 | 3 µs 成本 | 10 µs 成本 | 30 µs 成本 |
|---|---|---|---|---|---|
| 16 | 0.333 ms | 3000 | 0.900% | 3.000% | 9.000% |
| 64 | 1.333 ms | 750 | 0.225% | 0.750% | 2.250% |
| 240 | 5.000 ms | 200 | 0.060% | 0.200% | 0.600% |
| 256 | 5.333 ms | 187.5 | 0.056% | 0.188% | 0.563% |
| 1024 | 21.333 ms | 46.875 | 0.014% | 0.047% | 0.141% |
N 减半使通知频率翻倍，这是反比例关系，不是指数增长。较低占用也不保证省电：唤醒频率、其他定时器与空闲状态退出成本共同影响实际电能。
3. ring 容量不是端到端延迟¶
双声道、4 byte/sample、4 periods 时：
| N | 每 period 字节数 | ring 字节数 | ring 满载时音频时长 |
|---|---|---|---|
| 64 | 512 | 2048 | 5.333 ms |
| 240 | 1920 | 7680 | 20.000 ms |
| 256 | 2048 | 8192 | 21.333 ms |
| 1024 | 8192 | 32768 | 85.333 ms |
实际排队时间取决于当前 queued frames、启动阈值和读写策略，不能直接把 ring 容量作为固定延迟。算法块长、重采样群延迟和硬件 FIFO 是不同项；同一段缓冲不能重复计入。
4. 平均成本之外，还要验证期限¶
例如 N=64 的 period 仅 1.333 ms。若某次调度等待加处理时间为 2 ms，是否 XRUN 取决于当时剩余播放数据，而不是平均 CPU 是否低于 1%。应比较：
调度等待 + 处理 + 提交时间 < 当前安全水位 / fs
播放检查剩余可播放 frame；录音检查剩余空闲 frame。中断合并或突发补交会使实际唤醒节奏偏离 fs/N。
5. 可复现的选择流程¶
- 固定设备、内核、格式、声道数和功耗策略，读取协商后的实际 period/buffer 参数；请求值未必被原样接受。
- 逐档扫描设备支持的 N，而不是假定所有平台支持 64/256 或某个 FAST 标志。
- 每档记录 CPU 执行时间、调度等待分布、最大等待、XRUN、实际回环延迟和电池侧功率。
- 重复加入内存压力、网络突发、DVFS 和后台任务，保持输入和时长一致。
- 按产品允许的延迟、功耗与失效率选取有余量的档位。没有适用于所有移动终端的最佳 N。
测量表应保留硬件/内核版本、测试时长和原始 trace。未运行硬件实验前，本页只证明预算关系，不宣称某个配置达到量产标准。
参考：ALSA PCM 参数与状态。