关于audio的古老的笔记

QCOM Audio HAL 各 Playback 模式参数汇总

下表列出了几种典型 QCOM HAL Use-case（播放路径）的 PCM / buffer 参数：

模式 (Use Case)	pcm_config 关键参数	含义 / 换算
Low-Latency	- Channels = 2 - Rate = 48 000 Hz - period_size = LOW_LATENCY_OUTPUT_PERIOD_SIZE = 240 frames（非 MSM8974）或 256 frames（若是 MSM8974 平台） android.googlesource.com+2android.googlesource.com+2 - period_count = 2 android.googlesource.com+1 - Format = PCM_FORMAT_S16_LE （16-bit LE） android.googlesource.com+1 - start_threshold = period_size / 4 = 60 (or 64) frames android.googlesource.com - avail_min = period_size / 4 = 同样 60 / 64 frames android.googlesource.com	换算（假设 两声道 16-bit, 48 kHz）： - 总 buffer 大小 = 240 × 2 = 480 帧（若是 256 则是 512 帧） - 每帧字节 = 2 ch × 2 bytes = 4 bytes，512 帧即 2048 bytes（480 → 1920 bytes） - 延迟 = 480 / 48000 ≈ 10 ms（256 帧的话约 10.67 ms）
Deep-Buffer	- Channels = 2 - Rate = 48 000 Hz - period_size = DEEP_BUFFER_OUTPUT_PERIOD_SIZE = 960 frames（你之前提到的平台） android.googlesource.com+1 - period_count = 8 android.googlesource.com - Format = PCM_FORMAT_S16_LE android.googlesource.com+1 - start_threshold = 960 / 4 = 240 frames android.googlesource.com - avail_min = 960 / 4 = 240 frames android.googlesource.com	换算（假设 48 kHz, stereo 16-bit）： - 总 buffer = 960 × 8 = 7680 帧 - 每帧 4 bytes → 总约 30,720 bytes (~30 KB) - 延迟 = 7680 / 48000 = 160 ms - start threshold 时间 = 240 / 48000 = 5 ms - 单个 period 约 = 960 / 48000 = 20 ms
Offload (Compress-Offload)	这一模式不典型地用 PCM buffer，而是 fragment (压缩片段) 机制： - COMPRESS_OFFLOAD_FRAGMENT_SIZE = 256 KB (在较新 HAL 中) android.googlesource.com+1 - COMPRESS_OFFLOAD_NUM_FRAGMENTS = 3 android.googlesource.com+1 - COMPRESS_OFFLOAD_PLAYBACK_LATENCY = 96 ms（定义在 HAL 中） android.googlesource.com+1	意义 /换算： - 总 fragment buffer = 256 KB × 3 = 768 KB - HAL 设计的 offload 延迟是 96 ms（这个是 HAL “宣称”的播放延迟）
Real-Time / ULL / MMAP	- 在 HAL 里还有 pcm_config_rt (RT, ultra-low-latency) 模式：period_size = ULL_PERIOD_SIZE = DEFAULT_OUTPUT_SAMPLING_RATE / 1000 = 48,000 / 1000 = 48 frames (对应 1 ms) android.googlesource.com+1 - period_count = 512 (在 HAL pcm_config_rt) android.googlesource.com - start_threshold = ULL_PERIOD_SIZE * 8 = 48 × 8 = 384 frames (~8 ms) android.googlesource.com - avail_min = ULL_PERIOD_SIZE = 48 frames android.googlesource.com	换算： - 总 buffer = 48 × 512 = 24,576 帧 - 每帧 4 bytes → 总约 98,304 bytes (~96 KB) - 延迟 = 24,576 / 48,000 = 512 ms（这个是非常大的 buffer，但 RT 模式为保证稳定 / no-irq 设计） - start_threshold 时间 = 384 / 48,000 = 8 ms
HDMI Multi (多通道播放)	- Channels = HDMI_MULTI_DEFAULT_CHANNEL_COUNT（QCOM HAL 定义通常是 6 通道） android.googlesource.com - Rate = 48,000 Hz android.googlesource.com - period_size = HDMI_MULTI_PERIOD_SIZE = 336 frames android.googlesource.com - period_count = HDMI_MULTI_PERIOD_COUNT = 8 android.googlesource.com - Format = PCM_FORMAT_S16_LE（16-bit） android.googlesource.com - start_threshold = 0, avail_min = 0 (HAL 中这样设) android.googlesource.com	换算： - 总 buffer = 336 × 8 = 2688 帧 - 每帧 4 bytes → 总约 10,752 bytes (~10.5 KB) - 延迟 = 2688 / 48000 ≈ 56 ms

---

一些补充说明 &分析

1. 版本差异

   • 注意：不同 QCOM HAL 版本 /不同 SoC (比如 MSM8974 vs 非 MSM8974) 的 OUTPUT_PERIOD_SIZE / COUNT 可能不同。比如，在 audio_hw.h 中就写了 “#ifdef MSM8974 … 否则 …” 来分别定义 deep-buffer 和 low-latency 的 period size。 android.googlesource.com

   • offload fragment size 和 fragment 数量也随版本变化：有版本是 32 KB × 4 fragment，也有新版是 256 KB × 3 fragment。 android.googlesource.com+1

   • RT / ULL 模式 buffer 设计可能会根据 HAL 版本调整。

2. 为何不同机制

   • Low-Latency：期望很低延迟，buffer 小 (period 小, count 少)，适合对实时性要求高（比如游戏音效、UI 音效）

   • Deep-Buffer：为了省电 /减少唤醒开销 (wakeups) 使用较大 buffer。适合后台音乐、流媒体播放。

   • Offload：压缩格式（如 mp3 / AAC /其他 DSP 编码）播放，把压缩交给 DSP 处理，用 fragment 而不是 PCM 连续写。

   • RT / ULL：超低延迟 (超实时) 模式，通常用于 no-IRQ /特殊 use-case，但 buffer 比较大 (总帧数高) 保证稳定。

3. 测量 &调试

   • 如果你在设备上做性能分析 /测延迟 (audio latency) 时，可以根据这些配置算理论延迟。但实际延迟会因为 DSP / driver /内核 /唤醒开销等因素与理论值有差异。

   • 可以结合 dumpsys media.audio_flinger 输出里的 HAL 帧数 (frame count) 跟这些 period_size 来验证是否匹配 HAL 的预期配置。