笔记：Fedora 34 全面转向 PipeWire ？

https://pipewire.org/

# dnf -y install pipewire* Last metadata expiration check: 2:36:42 ago on Tue 18 May 2021 09:50:00 PM PDT. Package pipewire-0.3.27-2.fc34.x86_64 is already installed. Package pipewire-alsa-0.3.27-2.fc34.x86_64 is already installed. Package pipewire-devel-0.3.27-2.fc34.x86_64 is already installed. Package pipewire-gstreamer-0.3.27-2.fc34.x86_64 is already installed. Package pipewire-libs-0.3.27-2.fc34.x86_64 is already installed. Package pipewire-pulseaudio-0.3.27-2.fc34.x86_64 is already installed. Package pipewire-utils-0.3.27-2.fc34.x86_64 is already installed. Package pipewire0.2-libs-0.2.7-5.fc34.x86_64 is already installed.

# dnf -y install pipewire-devel Last metadata expiration check: 2:36:31 ago on Tue 18 May 2021 09:50:00 PM PDT. Dependencies resolved. ===================================================================================================================================================================================================================== Package Architecture Version Repository Size ===================================================================================================================================================================================================================== Installing: pipewire-devel x86_64 0.3.27-2.fc34 updates 132 k Transaction Summary ===================================================================================================================================================================================================================== Install 1 Package Total download size: 132 k Installed size: 728 k Downloading Packages: pipewire-devel-0.3.27-2.fc34.x86_64.rpm 215 kB/s | 132 kB 00:00 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 142 kB/s | 132 kB 00:00 Running transaction check

Christian Schaller: 就您想解决的问题而言，PipeWire的起源是什么？ Wim Taymans: PipeWire实际上是由两个早期的想法演变而来。第一个是PulseVideo， 这是由William Manley在2015年写的。它是一个小型的服务器，可以将视频从一个v4l2摄像头 发送到一个或多个其他进程。它使用GStreamer、DBus和文件描述符（fd）传递来相当有效地完成这项工作。 这导致了对GStreamer关于fdmemory的一堆补丁。 大约在那个时候，我们开始考虑Wayland的屏幕捕捉问题。我被要求调查各种选择。 当时的想法是采用PulseVideo的想法并实现客户端提供流的可能性（不仅仅是v4l2设备）。 另一个要求是使其安全，并与Flatpak和Flatpak的门户概念很好地配合，以处理有潜在安全问题的事物。 CS：啊，对了，因为当PipeWire最初在Fedora 27中被引入时，它只处理视频，对吗？ 提供一种在GNOME Shell中进行屏幕共享的方法？ WT: 是的，当时只有一些疯狂的想法，想把音频也处理了。最后出现在Fedora 27中的版本 需要再次重写才能实现，真的。 CS: 你能谈谈PipeWire是如何与Wayland和GNOME Shell等东西互动的吗？ WT：当屏幕共享被激活时，GNOME Shell将发送一个流到PipeWire。PipeWire会将这个 数据流路由到Firefox或屏幕录像机等应用程序。我们已经实现了一些更高级的功能， 如DMABUF传递和元数据，用于共享单个窗口时的光标和剪切区域。还有音量控制， 通过PulseAudio API与PipeWire互动来管理音量。 CS：所以，在视频方面没有真正的PipeWire先驱，因为大多数东西都是直接与v4l交互的，所以我 想把GNOME Shell和网络浏览器等东西移植过来，开始使用它一定是个大工程？ WT：没有什么屏幕共享的功能，只是用X11调用来抓取屏幕内容。Jan Grulich与上游的WebRTC项目合作， 添加代码与为Wayland定义的新门户APIS进行交互，以协商屏幕共享选项，然后支持本地PipeWire来 获取屏幕内容。然后Martin Stransky将这些工作回传到WebRTC的Firefox副本中，Jan Grulich 和Tomas Popela确保了这些变化被合并到Chromium/Chrome中。对于网络摄像机来说，目前还没有 什么进展。浏览器仍然直接访问v4l2摄像机。有一个门户可以通过PipeWire协商网络摄像头的访问， 但据我所知，这还没有在浏览器中实现。 CS：谈到移植和开发者，当开发者听到像PipeWire这样的新项目时，他们可能会问自己的第一个问题 是 "哦，不，我现在需要重写我所有的多媒体应用程序吗？"。PipeWire是如何应对这一挑战的？ WT：PipeWire通过一个ALSA插件、一个替代PulseAudio的服务器和一个替代JACK的客户端库分别提供了 与ALSA、PulseAudio和JACK应用的兼容性。理论上，这应该提供了一种无需修改就能运行所有现有 应用程序的方法。有了PipeWire，我们现在应该开始考虑将这些音频API作为音频工具包。这有 点像GUI工具包，如GTK或Qt：它们都与底层显示子系统（Wayland/X11）对话，没有应用程序考虑在 他们的应用程序中实现原始Wayland后端。JACK/PulseAudio也是如此，它们为应用程序提供了一个音频 子系统的模型，你可以选择最适合你使用情况的音频工具箱。我认为这种情况不会改变，除非有人想出 终极音频工具包。 CS: 在你工作的过程中，你对这个问题空间的思考是如何演变的？ WT：随着项目的推进，我开始研究这个框架是否也能支持音频。它需要大量的重写来使其有效工作。 GStreamer和dbus需要被替换成更低级的东西来使音频可行，特别是专业音频。同时，GObject和DBus 对于我所设计的低级系统来说开始感到沉重。在2016年年中，我开始试验一个新的小型媒体插件API。它 仍然很像GObject，但我开始在这个新框架中重新实现v4l2和audiomixer插件。到2016年底，我也 从DBus转移到一个更像Wayland的协议。2017年初，我开始认真考虑实现音频服务器的功能。我开始研究 JACK及其处理模型和音频插件API，如lv2。这也是我们想出PipeWire这个名字的时候。到2018年底， 我有了一个工作的音频服务器，有一个类似JACK的图形模型，嗯......至少在我的基本测试案例的 背景下工作。在与Linux专业音频社区的成员进行了一些讨论后，他们相信我需要在调度和混音的工作 方式上做一些更激烈的设计改变，如果这有可能取代JACK对他们来说。这时，最终的重新架构开始了， 经过2年的开发，最终在2020年初形成了第一个0.3版本。 CS：我知道你提到的专业音频支持已经在社区中引起了很大的反响，那么你最初和谁谈过，到目前为止， 更广泛的专业音频社区的反应如何？ WT：如前所述，我在2018年初就与他们进行了一些讨论。罗宾-加雷斯和保罗-戴维斯在推动导致 目前实施的变化方面发挥了作用。我认为每个人都希望有一个无缝的、集成的、用户友好的体验， 可以用于专业音频和消费音频的使用案例，大家肯定对PipeWire将如何发展以实现这一目标感兴趣。 尽管我们正在快速发展，但在功能平等方面我们还没有达到这个水平。例如，就在本周，我在PipeWire 中实现了对Freewheeling的支持，当你读到这篇文章时，它应该已经在Fedora中出现。 除此之外，延迟报告是剩下的一个重要的TODO项目。另外，虽然PipeWire可以管理与JACK相同的延迟， 但我们还没有那么可靠。所以还有一些工作要做。 CS：那么PulseAudio的开发者呢？他们是如何看待PipeWire的到来的？Lennart Poettering 现在恨你吗？ WT：我认为他们对它没有意见。我们在2018年10月与PulseAudio的一些开发人员组织了一次黑客节， 讨论PipeWire，所以这并不奇怪。事实上，Arun Ragahavan是PulseAudio的长期贡献者，他目前 正在研究PipeWire。早期我还和Lennart谈过这个问题，他完全支持统一专业音频和消费音频的想法， 所以我觉得他不恨我 。 CS: 你也是GStreamer的创建者，你如何看待这两个项目的使用情况？ WT：我认为PipeWire是一个更低级的框架，在应用程序和设备之间移动数据。它在处理原始音频和视频 以及与设备的接口方面非常出色。它并不擅长多路复用和少路复用，也不想做一些更高层次的多媒体任务， 如实现RTSP服务器或处理多路复用格式。GStreamer仍然非常适合那些更高层次的任务，复用、解复用、 编码、解码，等等。 CS: 所以你认为它们相互补充而不是相互竞争？ WT：它们绝对是相互补充的。我不认为一个会超越另一个。现在知道事情的确切走向还为时过早，但我可 以看到，像音频或视频效果链这样的东西在PipeWire中实现得更好。而管道和后期处理则在GStreamer中完成得更好。 CS: 除了你自己之外，还有什么社区贡献者你想强调的吗？ WT：当然有。几乎所有新的令人兴奋的蓝牙工作都是由社区贡献者完成的。Pauli Virtanen一直在做 修复工作，比如许多蓝牙的改进和SCO插件的一般修复和稳定性改进，实现编解码器的切换和延迟报告。 他还参与了其他领域的工作，如PipeWire IPC连接、会话管理器中的默认节点和策略，以及一些 对象管理的改进。维护pulseaudio-modules-bt的Huang-Huang Bao（ep）贡献了很多变化， 如LDAC ABR支持、硬件音量支持和大量的稳定性和兼容性修复，使蓝牙支持达到与pulseaudio模块 相同的水平。我们也有Collabora的贡献者George Kiagiadakis和Frédéric Danis定期贡献 蓝牙、构建和其他修复，作为他们参与AGL的一部分。他们也一直在开发一个叫做WirePlumber的 改进型会话管理器，我们将尝试将其纳入Fedora 35。Dmitry Sharshakov实现了蓝牙电池状态报告， 这是bluez中一个相对较新的功能，现在也被PipeWire支持。虽然与PipeWire本身没有直接关系， 但我之前提到的Jan Grulich、Martin Stransky和Tomáš Popela在网络浏览器中支持PipeWire 的工作也是一个重大进展。同样，Jonas Ådahl为创建屏幕捕捉门户并在GNOME Shell中实现它所 做的工作也是如此。我还想特别提到Georges Stavracas，他在将PipeWire支持纳入OBS Studio 方面做了大量工作。Jan Grulich也做了大量的工作，将PipeWire支持纳入KDE。也有很多人活跃在 问题追踪器上，试图帮助分流错误，提供帮助和改进维基页面。 CS: 在你测试和使用PipeWire的过程中，是否有一些你以前不知道的应用，但由于人们报告说它们 不能与PipeWire一起使用，或者你在寻找测试案例时发现了它们？ WT：大部分的midi工具，真的。在我开始在PipeWire中添加支持之前，我从未真正使用过midi。 我迷上了各种合成器，比如Helm，zynaddsubfx，还有最近的Vital和免费的Vitalium应用程序。 当你有了midi和JACK的兼容性之后，就会有一个完整的音乐创作工具的世界，而这些工具在以前是 很少见的。我以前不知道任何lsp或calf的插件。我喜欢Inge的想法，我希望看到它得到更多的发展。 我想，像这样的工具可以用来对PipeWire中的效果链进行建模和调整。 CS: 在专业音频和midi方面，你自己是一个音乐家吗，这些东西你认为自己今后会使用吗？ WT：我自己会弹一点吉他，但我是老派的，我插在一个真正的电子管放大器上，没有效果器，然后 我就弹。我在Ardour中用PipeWire做了一些吉他和声音的录音来测试。我真的对创建代码更感兴 趣，这样其他人就能做出你真正想听的音乐了 。 CS: 你觉得PipeWire还有哪些需要解决的问题？ WT：有一个很长的待办事项清单...。 对于桌面用例，我们需要与PulseAudio达到合理的功能对等。我们缺少对网络流的自动检测和设置， 以及对压缩格式的穿越，如DTS和AC3在HDMI上的穿越。对于专业音频的使用情况，我们需要实现杰克 所说的 "自由旋转"，然后是延迟报告。在这之后，我们可以开始研究我们现在可以用PipeWire做的 所有令人兴奋的新事情。我们可能会在某个时候重新设计声音控制面板。 在视频方面，有很多地方可以改进。我们还没有一个视频处理管道，更不用说管理这样一个视频管道的工具了。 CS：你是否希望在PipeWire中看到更多的贡献者？ WT：当然！我认为现在有很多令人兴奋的东西，你可以做。例如，我们没有一个真正的本地补丁库。 我们依靠JACK工具，但这些工具并不能处理视频流。我想说，一个简单的基于curses的 patchbay将是一个很好的贡献。在PipeWire中，编写新的外部汇和源是比较容易的。我很想看到 一个好的通用网络协议的本地实现，比如ROC之类的。 CS: 你最近在RedHat内部开始了新的工作，你能告诉我们一些情况吗，这对PipeWire意味着什么？ WT：是的，我是Red Hat内部新的信息娱乐小组的一员，该小组最初将专注于为汽车行业提供软件栈。 这是关于在汽车中实现音频和视频，PipeWire将在实现这一目标中发挥重要作用。PipeWire已经 是汽车级Linux的一部分，同时还有WirePlumber。其中一个挑战是要能够以灵活的方式路由 汽车中所有的音频采集和播放流。现代汽车也有大量的视频摄像头需要管理。该计划的一部分 是为这些用例改进PipeWire。我们期望这些用例中的一些最终也会使桌面用户受益。