Linux多媒体进阶之旅(十二): PulseAudio时代正在落幕,PipeWire时代到来

点击下方👇关注 Android系统攻城狮

第205篇原创文章

       最近几年，Linux音频框架正在经历明显变化：越来越多的Linux发行版开始默认采用PipeWire新一代多媒体处理框架，而长期占据Linux平台默认音频系统地位的PulseAudio也正在被逐步取代。

      2021年4月，Fedora34发布，Fedora Workstation34开始将桌面音频切换到PipeWire。

      2022年10月，Ubuntu Desktop22.10发布，PipeWire开始成为Ubuntu默认桌面音频架构。

      2023年6月，Debian12发布，其GNOME桌面环境默认采用PipeWire处理音频。

      2024年7月，Linux Mint22发布，默认音频服务也切换到了PipeWire。

     2025年10月，Ubuntu25.10发布，PipeWire升级到1.4.7版本。

      2026年4月，Ubuntu26.04 LTS发布，PipeWire升级到1.6.2版本。

      越来越多主流Linux发行版转向PipeWire，并不只是将一个声音服务器替换成另一个声音服务器，传统围绕单一音频服务构建的架构，已经难以统一承载这些音频与视频场景。

      更深层的原因在于，Linux系统需要处理的媒体场景已经发生变化：应用不仅需要播放和录制音频，还要面对专业低延迟音频、视频采集、屏幕共享、蓝牙设备、沙箱权限以及动态流路由等复杂需求。

1

PulseAudio解决上一代什么问题？

        PulseAudio解决了把应用、音频设备、音量、路由和混音统一放到一个声音服务器里处理，让应用程序不用直接向ALSA设备读写数据。

　　在很长一段时间里，这个模型是有效的，应用播放声音、录音应用采集麦克风、桌面环境切换默认声卡，这些问题PulseAudio都能处理起来。

　　PulseAudio把ALSA上面那层用户态音频管理补齐，增加了混音、音量、播放、录音、设备路由等处理功能，从此，Linux系统终于有了一套比较稳定的处理方式。

　　后面的变化，是系统需求的东西变多了，桌面共享需要采集屏幕，浏览器需要安全地拿到音频和视频流，JACK应用需要低延迟音频处理，容器和沙箱应用不应该随便访问设备，车载系统还要同时面对多路音频策略、蓝牙、导航、语音和娱乐系统。

　　到这个阶段，问题就不再只是应用声音怎么送到声卡，而是这些媒体流怎么被统一描述、统一连接、统一调度、统一授权。

　　PulseAudio原来的模型围绕音频服务展开，它可以很好地管理声音，但新的问题要求系统同时管理音频、视频、屏幕流、权限和低延迟图，这些能力是原来的音频服务模型不具备的。

2

PipeWire兼容PulseAudio吗？

　　PipeWire的定位不是再做一个PulseAudio服务，而是做Linux用户态的新一代多媒体处理框架，它把音频、视频和其他媒体流统一抽象成图里的对象，再通过连接关系组织起来。

　  在PipeWire里，一个播放流、一个录音流、一个摄像头、一个屏幕采集流，都可以被放到Graph里管理，系统不再只关心 谁播放声音，而是关心哪个媒体节点产生数据，哪个媒体节点消费数据，中间如何连接。

　  这就是PipeWire和PulseAudio最核心的差异。

　  PulseAudio更多是围绕音频设备和音频流建立的声音服务，PipeWire把处理对象扩展到了多媒体流，并且用Graph组织这些流之间的关系。

　　为了让旧接口的应用继续使用，PipeWire还提供了兼容层，比如pipewire-pulse可以让原来使用PulseAudio协议的应用继续工作，pw-jack可以让JACK应用跑在PipeWire上。

 关键点：虽然兼容PulseAudio，但是底层真正运行的是PipeWire自己的Graph、节点和调度模型。

3

PipeWire解决什么问题？

　　一直以来，Linux平台多媒体系统比较复杂，一个应用可能走PulseAudio，一个专业音频应用可能走JACK，一个屏幕共享又要经过Wayland和Portal，一个视频采集还要面对摄像头和权限。

　　这些组件不是谁取代谁的问题，而是它们原来分散在不同通道里，应用开发者和系统集成者经常要同时处理多套模型。

　　PipeWire想解决的就是这些碎片化问题，把不同类型的媒体流放到统一的运行框架里。

　　以屏幕共享为例，现代Linux桌面不希望应用直接获取屏幕内容，特别是在Wayland环境下，屏幕内容属于敏感资源，应用需要通过Portal拿到授权，再由PipeWire获取实际媒体流。

        这样应用不需要直接操作底层显示系统，也不需要绕开权限模型，而是通过系统统一的方式拿到受控的媒体流。

　　音频链路也是类似思路，应用不再只面对一个声音服务，而是面对PipeWire提供的统一媒体图，音频设备、应用流、策略管理和兼容层都可以放到同一套模型里协作。

　　PipeWire负责底层媒体对象和Graph运行，WirePlumber负责策略管理，比如设备什么时候可用、应用流连接到哪个设备上、默认路由怎么选、蓝牙设备切换后怎么处理。

1.PipeWire：负责媒体对象和Graph。2.WirePlumber：负责策略、路由和会话管理。

　　也就是说，PipeWire不是把所有事情都塞进一个进程里来做，而是把媒体处理框架和策略管理拆开，底层跑媒体流，上层决定怎么连接、怎么选择、怎么切换。

4

AGL支持PipeWire框架

        如果只看桌面Linux发行版，PipeWire的普及像是一次桌面音频栈升级，它已经被应用到Linux开源车载平台AGL(Automotive Grade Linux)中。

        车载音频系统面对的并不只是一个音乐播放器，媒体播放、导航提示音、语音助手、蓝牙电话、系统提示音和仪表报警音等多类音频流可能同时存在，并且具有不同的优先级、路由目标和安全要求。系统不仅要保证声音能够正常播放，还要处理抢占、降音、暂停与恢复、设备切换、权限隔离以及跨容器音频策略。

        AGL在2025年12月发布UCB20.0 Terrific Trout，继续更新PipeWire和WirePlumber，重点改善低延迟能力以及蓝牙音频和电话功能集成。实际上，AGL早在2019年的UCB8.0版本，就已经将PipeWire设置默认音频系统，UCB20.0体现的不是首次引入，而是对它的持续升级。

        在AGL音频架构中，PipeWire负责低延迟媒体流处理以及应用与设备之间的音频路由，WirePlumber负责设备发现、配置、会话管理、安全隔离和策略执行。仪表报警音与IVI音乐之间的优先级仲裁、不同容器之间的权限隔离以及蓝牙电话设备管理，都是这套架构面向车载场景的具体应用。

        PipeWire的发展方向，已经不再局限于替代传统桌面声音服务，而是与WirePlumber共同构成面向桌面、嵌入式和车载系统的媒体处理与策略管理的基础设施。

5

总结

      PulseAudio解决的是如何统一管理声音，PipeWire进一步解决的是如何统一组织音频、视频、图形和其他媒体流。

　　Linux多媒体框架的需求已经变了，PipeWire不只是音频服务，而是Linux平台新一代统一音视频流管理框架。

若读者朋友发现有错误、疑问的地方，或者好的建议，欢迎拍砖！！！