3. Linux音频系统全景
在车载Linux音频系统中，音频链路从应用层到硬件层往往要穿过多个软件栈。理解这些软件栈的定位、边界与协作方式，是排查“为什么没有声音”“为什么延迟高”“为什么多路音频互相抢占”等问题的前提。本节从内核接口层出发，逐层向上梳理OSS、ALSA、PulseAudio、PipeWire、JACK以及Android Audio HAL之间的关系，并说明它们在车载场景中的典型角色。
一、内核接口层：OSS与ALSA的对比
OSS（Open Sound System）是早期Linux/Unix上的音频接口，采用“设备文件即音频通道”的模型，应用通过/dev/dsp、/dev/mixer等节点直接读写PCM数据。它的优点是模型简单、编程门槛低；缺点是硬件混音能力弱、多路并发支持差、采样率与格式转换能力有限，且驱动维护成本高。ALSA（Advanced Linux Sound Architecture）则取代OSS成为Linux标准音频框架，它把声卡抽象为card、device、subdevice，并通过PCM、Control、Mixer、Seq等接口提供更细粒度的控制。
ALSA的核心优势在于：支持硬件混音、多路PCM、丰富的控件与路由能力，并提供用户态库alsa-lib简化开发。在车载系统中，ALSA通常作为最底层的音频驱动与硬件抽象层，直接管理I2S、TDM、HDMI、USB Audio等接口。需要注意的是，ALSA本身并不负责全局混音和策略管理，多个应用同时打开同一PCM设备时，往往需要dmix插件或上层音频服务来协调。
关键区别：OSS是“设备即通道”，ALSA是“声卡—设备—子设备”的分层模型。现代车载Linux几乎不再使用OSS，但理解OSS有助于读懂旧代码和兼容层。
二、用户态音频服务：PulseAudio、PipeWire与JACK
ALSA之上，常见的用户态音频服务包括PulseAudio、PipeWire和JACK。PulseAudio是长期占据桌面Linux的音频服务，提供全局混音、设备热插拔、网络音频和每应用音量控制。它通过module-alsa-sink、module-alsa-source等模块与ALSA对接，应用通过libpulse或兼容层播放。PulseAudio的缺点是架构较老、延迟偏高，在车载多路低延迟场景中并不理想。
PipeWire是新一代多媒体服务，统一处理音频与视频流，兼容PulseAudio、JACK和ALSA应用。它采用图（graph）模型，节点之间通过端口连接，支持低延迟、多路并发和细粒度路由。在车载系统中，PipeWire常被用于需要动态路由、多音区管理和低延迟回放的场景。JACK则专注于专业音频，提供极低延迟和采样级同步，适合车载音频采集、主动降噪（ANC）、回声消除（AEC）等对时序要求极高的模块。JACK通常直接对接ALSA，或通过PipeWire的JACK兼容层运行。
三、Android Audio HAL与车载场景的关联
在Android车载系统中，应用通过AudioTrack/AudioRecord进入AudioFlinger，再经由Audio HAL与底层音频驱动交互。Audio HAL是Android定义的硬件抽象接口，常见实现包括audio.primary.default、audio.usb.default等。车载场景下，Audio HAL不仅要完成PCM播放与采集，还要处理多音区（前排/后排/头枕）、音源优先级（导航优先于媒体）、电话与媒体混音、AEC/ANC等策略。
典型车载音频链路可以概括为：Android App → AudioFlinger → Audio HAL → ALSA/ASoC → Codec/功放 → 扬声器。若系统同时运行Linux原生应用，则可能出现PipeWire/PulseAudio与Android Audio HAL并存的情况，此时需要通过音频路由策略或虚拟声卡进行桥接。常见做法是让Android Audio HAL直接对接ALSA，而Linux侧通过PipeWire管理非Android音源，二者通过snd-aloop或dmix共享硬件。
四、核心对比与选型参考
| 方案 | 定位 | 延迟 | 多路混音 | 车载典型用途 |
|---|---|---|---|---|
| OSS | 旧式内核音频接口 | 中等 | 弱 | 旧平台兼容，已基本淘汰 |
| ALSA | 内核标准音频框架 | 低 | 依赖dmix | 驱动、Codec、ASoC底层 |
| PulseAudio | 桌面音频服务 | 较高 | 强 | Linux侧媒体播放、调试 |
| PipeWire | 新一代多媒体服务 | 低 | 强 | 多音区、动态路由、低延迟 |
| JACK | 专业音频服务 | 极低 | 采样级同步 | ANC、AEC、音频采集 |
| Android Audio HAL | Android硬件抽象 | 低 | 由AudioFlinger管理 | 车载Android音区与策略 |
五、案例与排障思路
假设一辆车机出现“导航播报时媒体音量被压低，但导航结束后媒体音量没有恢复”的问题。排查路径如下：首先确认AudioFlinger中的音源优先级与audio_policy.conf配置；其次检查Audio HAL是否实现了setParameters中的routing与volume策略；再通过tinymix、amixer查看ALSA控件是否被错误置位；最后确认PipeWire/PulseAudio是否与Android音频服务争抢同一PCM设备。
# 查看ALSA声卡与PCM设备
aplay -l
arecord -l
# 查看当前混音控件
amixer -c 0 controls
# 查看PulseAudio/PipeWire节点
pactl list short sinks
pw-cli list-objects | grep node
# Android侧查看音频服务
adb shell dumpsys audio
adb shell dumpsys media.audio_flinger排障建议：先确认“声音从哪一层消失”，再决定是查ALSA控件、音频服务路由，还是Android Audio HAL策略。不要一上来就改驱动。
常见误区：认为ALSA能自动完成全局混音。实际上，多应用并发时若未启用dmix或上层音频服务，后打开PCM的应用可能直接失败。车载多音区场景更应依赖PipeWire或AudioFlinger进行统一调度。
总体来看，OSS与ALSA解决的是“内核如何访问硬件”，PulseAudio、PipeWire、JACK解决的是“用户态如何混音、路由与低延迟处理”，Android Audio HAL解决的是“Android框架如何与车载音频硬件和策略对接”。在车载Linux音频系统中，这几层往往同时存在，理解它们的边界与数据流，才能快速定位问题并做出合理的架构选型。