PipeWire:Linux 的音频/视频总线

十多年来,PulseAudio 一直服务于 Linux 桌面,作为其主要的音频混音和路由守护程序 - 以及它的音频 API。不幸的是,PulseAudio 的内部架构并不适合日益增长的沙盒化的应用程序用例,尽管已经有人尝试对其进行修改。PipeWire,一个新的守护进程从这些尝试中横空而出,将在即将到来的 Fedora 34 发行版中替换 PulseAudio。这是一个即将到来的转变,值得一看。

说到转换,2007 年末 Fedora 8 自己向 PulseAudio 的转换并不顺利。长期使用 Linux 的用户仍然记得,这个守护进程被标记为会破坏音频的软件。在一段崎岖的启动之旅之后,PulseAudio 成为 Linux 声音服务器斗争的赢家。它提供了一个本地客户端音频 API,但也支持使用当时常见音频 API 的应用程序 —— 包括原始的 Linux ALSA 声音 API,它通常只允许一个应用程序访问声卡。PulseAudio 混合不同应用程序的音频流,并为音频管理、细粒度配置和无缝路由到蓝牙、USB 或 HDMI 提供了一个中心点。它将自己定位为 Linux 桌面中的 Windows Vista 用户模式音频引擎和 macOS CoreAudio 守护进程。

PulseAudio 的裂纹

到 2015 年,PulseAudio 仍然享受着它作为 Linux 音频守护进程的地位,但裂缝开始出现。逐渐转向沙盒化的桌面应用程序可能会对其设计造成致命的影响:通过 PulseAudio,应用程序可以窥探其它应用程序的音频,对麦克风进行无中介访问,或者加载可能干扰其它应用程序的服务器模块。尝试修复 PulseAudio,主要是通过访问控制层和每个客户端 memfd 支持 的传输。对于隔离客户端音频,这些都是必要的,但还不够。

大约在那个时候,PulseAudio 的核心开发者之一 David Henningson 从项目中辞职了。他提到了这个守护进程不适合沙盒化的应用程序用例,以及它混合了音频路由决策的机制和策略等问题。在他的消息的最后,他想知道这些问题的组合是否可能是一个新的和急需的 Linux 音频守护进程的产痛:

软件中没有什么是不可能的,但要以良好的 (而不是“在上面构建另一个层”[…]) 方式重新架构 PulseAudio 以支持所有这些需求将非常困难&

你可能感兴趣的:(linux,音视频,stm32)