PipeWire是一个面向Linux系统的低层多媒体框架与媒体服务器（media server），用于在应用程序与硬件设备之间传输、路由和处理音频、视频及MIDI等多媒体数据。它采用基于图（graph）的处理模型，节点可以在服务器进程内运行，也可以分布在独立进程中，通过套接字通信并借助文件描述符传递共享媒体数据。该项目由红帽（Red Hat）的维姆·泰曼斯（Wim Taymans）于2015年发起，目标是用统一框架取代PulseAudio、JACK等分散的音频方案，并为容器化应用和Wayland环境提供可控的权限模型。2021年4月，Fedora Linux 34成为首个默认使用PipeWire处理音频的发行版。
定义
PipeWire是一个运行在Linux上的低层多媒体框架与媒体服务器，提供处理多媒体管线的服务器端和用户空间API。按照其官方文档的说明，它是一个基于图的处理框架，主要处理音频、视频和MIDI数据，并为进程外处理图提供开销较小的支持。[1]
在PipeWire的模型中，一张图由若干节点组成，每个节点接受任意数量的输入，这些输入称为端口（port），节点处理完数据后再从输出端口送出；连接输出端口与输入端口的边称为链接（link）。只带输出端口的节点通常称为源（source），只带输入端口的节点称为汇（sink）。[2]
这套设计要解决的问题是Linux长期缺乏统一的多媒体交换机制：视频渲染通常依赖合成器，视频采集往往直接访问硬件设备，消费级音频使用PulseAudio混音，专业音频则由JACK管理节点图，而这些方案在设计之初并未考虑Flatpak等容器化应用所需的权限控制。[2]
原理
PipeWire的服务器本身不负责管理图的拓扑结构。它提供创建、链接和控制节点的接口，而监视新的ALSA设备、把它们配置成节点、以及决定节点之间如何连接这类依赖具体环境的行为，由称为会话管理器（session manager）的独立客户端负责。会话管理器决定了每个客户端拥有哪些权限，每条权限记录包含一个对象编号和读、写等标志位。[2]
节点内的处理逻辑通过SPA（Simple Plugin API，简单插件接口）实现。SPA面向低延迟与高效处理设计，可处理各种多媒体格式，并提供了一些标准C库中不存在的辅助工具。PipeWire原生协议的通信方式与Wayland类似，但对消息采用自定义的序列化方式，原因是消息中的数据结构较复杂，不易用XML表达。[3]
在数据传输效率上，PipeWire针对未压缩视频使用文件描述符传递，音频则使用共享环形缓冲区；节点可以运行在服务器进程内部，也可以位于独立进程中，通过套接字与服务器通信。对于使用PulseAudio、JACK、ALSA或GStreamer的应用，PipeWire提供了相应的兼容机制，例如通过修改动态链接库搜索路径，让JACK客户端加载PipeWire实现的兼容库，从而被重定向到PipeWire。[3][2]
发展历程
2015年，维姆·泰曼斯开始开发PipeWire，其思路来自若干已有项目，其中包括威廉·曼利（William Manley）提出的PulseVideo。红帽的克里斯蒂安·沙勒（Christian Schaller）表示，该项目从PulseVideo的早期原型中借鉴了许多想法，并建立在因此被合并进GStreamer的部分代码之上。
项目在命名上经历了几次变化。泰曼斯起初考虑沿用PulseVideo这个名字，到2015年6月则采用了Pinos这一名称，取自他曾经居住过的西班牙城市皮诺斯德阿尔阿乌林。早期的Pinos只处理视频流，到2017年初泰曼斯开始加入音频流处理，并为此咨询了JACK开发者保罗·戴维斯（Paul Davis）和Ardour开发者罗宾·加雷乌斯（Robin Gareus）；也正是在这一时期，项目改名为PipeWire。
2018年11月，PipeWire的许可证从LGPL更换为MIT许可证。2021年4月，Fedora Linux 34成为首个默认用PipeWire处理音频的发行版；此后Pop! OS在22.04版本中将其作为默认音频服务器，Ubuntu从22.10版本起默认采用，2023年Debian 12 Bookworm也在GNOME桌面环境中将它设为默认音频服务器。[4]
应用
PipeWire最常见的用途是充当系统音频服务器。它提供PulseAudio服务器的兼容实现以及面向JACK客户端的ABI兼容库，目标是用一个组件同时替代PulseAudio与JACK，从而省去在两者之间架设桥接程序的需要。发行版通常通过pipewire-pulse和pipewire-jack等软件包提供这些兼容层。[5][6]
在视频方向，PipeWire被用作屏幕共享与屏幕录制的中介。Wayland环境下，浏览器等应用通过xdg-desktop-portal及其后端请求捕获桌面内容，由PipeWire以细粒度的访问控制提供画面，Firefox 84及以后版本、Chromium 110及以后版本默认支持这种方式，OBS Studio从27版起也提供基于PipeWire的捕获源。此外，v4l2设备提供者模块可以让多个进程受控地共享同一个视频采集设备。[7][3]
PipeWire还包含名为filter-chain的内部模块，可以创建处理音频输入输出的节点，用于均衡器、虚拟环绕声、声道混合等处理，并可使用LADSPA、LV2等格式的插件。基于它的第三方工具包括GTK编写的图形化接线面板Helvum和基于Qt的qpwgraph，用于查看和编辑节点间的连接。[7]
局限
PipeWire自身不具备网络透明传输能力，跨计算机共享音频需要依赖其PulseAudio兼容实现所提供的网络流功能，例如配合Avahi进行服务发现，再加载相应的TCP协议与发现模块。
在专业音频场景中，PipeWire的延迟表现曾受到质疑。有用户报告在使用FireWire音频接口时出现约90毫秒的额外延迟，而相同的硬件直接通过ALSA工作时往返延迟约为10毫秒；社区提出了调整api.alsa.period-num等参数作为绕过方案。另有开发者表示，使用PipeWire配合FFADO时出现明显可听的xrun，因而放弃将其用于专业音频用途。[8][9]
兼容层也带来额外开销。有开发者指出，以JACK客户端方式经由PipeWire的兼容库运行时，每次回调都要经过一层参数转换，且无法获得按节点名称指定设备、延迟上报、格式协商、空闲挂起、会话管理器钩子等原生PipeWire客户端可直接使用的功能。此外，PipeWire的ALSA插件对周期数量的处理与原生ALSA硬件不同，在只设置周期数而不指定周期大小时可能配置出异常大的缓冲区，进而产生远超预期的输出延迟。[10][11]
参见
-
PulseAudio —— Linux 上较早的音频服务器，PipeWire 提供其兼容实现并逐步取代它。
-
JACK —— 面向专业音频的节点图管理方案，PipeWire 提供 ABI 兼容库以运行其客户端。
-
ALSA —— Linux 内核声卡驱动与用户空间接口，PipeWire 通过它把硬件设备暴露为节点。
-
GStreamer —— 多媒体处理框架，PipeWire 提供对应的输入输出元件并借用了其部分代码。
-
Wayland —— 显示服务器协议，PipeWire 为其提供屏幕共享能力，二者协议模型相似。
-
WirePlumber —— PipeWire 推荐使用的会话管理器，负责节点连接与设备监视。
参考资料
- PipeWire [引用日期2026-10-14]
- Concepts [引用日期2026-10-14]
- PipeWire: Design [引用日期2026-10-14]
- proceedings(PDF) [引用日期2026-10-14]
- 「PipeWire」の版間の差分 [引用日期2026-10-14]
- PipeWire [引用日期2026-10-14]
- 「PipeWire」の版間の差分 [引用日期2026-10-14]
- indiana.edu 上的网页 [引用日期2026-10-14]
- gnuweeb.org 上的网页 [引用日期2026-10-14]
- github.com 上的网页 [引用日期2026-10-14]
- github.com 上的网页 [引用日期2026-10-14]