Pipewire:Fedora Linux 34的新音频和视频守护程序

2021-05-15 10:13:15

WIM Taymans在Linux社区中有很长的轨道记录。他是Gstreamer多媒体框架的两个原始开发人员之一,他是大多数项目的首次存在者的主要维护者。他于2013年加入红帽,并帮助维护了Greamer和Pulseaudio以获得红色帽子。 2015年,他开始研究Pipewire:一个项目在Fedora Workstation 34的完全成果,它处理了音频和视频。除此之外,它还将Pro-Audio与主流Linux的世界合并。在这次面试中,我们将谈谈Pipewire来自哪里,它在哪里以及Wim看到它来自这里的地方。

Christian Schaller:对你想要解决的问题的原因是皮舰的起源?

Wim Taymans:Pipewire真的出现在两个早期的想法中。第一个是PulseVideo,它是由2015年的William Manley写的。它是一个小型服务器,可以将视频从V4L2相机发送到一个或多个其他进程。它使用了GStreamer,DBus和文件描述符(FD)传递以相当有效地执行此操作。它导致Gstreamer关于FDMemory的一堆补丁。

随着那个时候,我们开始考虑Wayland的屏幕捕获。我被要求调查选项。然后,这个想法是拍摄PulseVideo的想法并实现客户提供流的可能性(不仅仅是V4L2设备)。另一个要求是使这一安全性和平板电脑的门户概念良好,以处理具有潜在安全问题的事情。

CS:啊,因为当PipeWire最初被介绍到Fedora 27的Fedora时,它只是处理视频右边?提供一种在GNOME Shell中进行屏幕共享的方法?

WT:是的,只有关于尝试处理音频的狂野想法。最终在Fedora 27中最终的版本需要另一种重写,确实发生了这种情况。

CS:你能谈谈Pipewire如何与Wayland和Gnome Shell这样的东西互动?

WT:当激活屏幕共享时,Gnome Shell将在Pipewire发送流。 PipeWire将对此流路由到Firefox或屏幕记录器等应用程序。我们在共享单个窗口时,我们有一些更高级的功能,例如DMABUF传递和用于游标和剪切区域的元数据。还有卷控制通过PulseAudio API与PipeWire进行交互以管理卷。

CS:所以没有真正的Pipewire Precesors用于视频,因为大多数东西刚刚直接与V4L互动,所以我假设它一定是一个大任务,他们在GNOME Shell和Web浏览器开始使用它来开始使用它?

WT:没有屏幕共享没有任何东西,这只是X11来拍摄屏幕内容。 Jan Grulich使用了上游WebRTC项目,添加代码来与Wayland定义的新门户API进行交互,以协商屏幕共享选项,然后是本机PipeWire支持来获取屏幕内容。然后,马丁斯特兰基回到了将WebRTC和Jan Grulich和Tomas Popela的Firefox副本的工作合并成铬/铬的变化。

对于网络摄像头,还没有太多进展。浏览器仍然直接访问V4L2相机。有一个门户网站通过Pipewire协商网络摄像头访问,但据我所知,尚未在浏览器中实施。

CS:谈论移植和开发人员,当他们听到像Pipewire这样的新项目时,首先问题开发人员可能会问自己是'哦不,我现在需要重写所有多媒体应用程序吗?'。 Pipewire如何处理这一挑战?

WT:PipeWire分别提供与Alsa,Pulseaudio和千斤顶应用程序的兼容性,分别使用Alsa插件,替换PulseAudio服务器和插座替换客户端库。从理论上,这应该提供运行所有现有应用程序的方法而不进行修改。

使用PipeWire,我们现在应该开始考虑那些音频API作为音频工具包。它有点像GUI工具包,如GTK或QT:它们都与底层显示子系统(Wayland / x11)交谈,并且没有应用程序在其应用程序中实现生长的Wayland后端。

与Jack / Pulseaudio相同,它们提供了具有音频子系统型号的应用程序,您可以选择最适合您用例的音频工具包。除非有人提出终极音频工具包,否则我没有看到这种更改。

CS:你的思考如何在你工作时演变出来的?

WT:随着项目前进,我开始调查此框架是否也可以支持音频。它需要一个大量的重写,以便有效地完成工作。 GStreamer和DBus需要更换更低的东西,以使音频可行,尤其是Pro-Audio。同时,Gobject和DBus都开始对我设计的低级系统感到重。

我在2016年左右开始尝试新的小媒体插件API。它仍然是非常非常非常的gobject,但我开始在这个新框架中重新实现V4L2和Audiomixer插件。到2016年底,我远离DBUS以及更多的HALEDLAND等协议。

2017年初是在我认真开始考虑实施音频服务器的功能时。我开始调查插孔及其处理模型和音频插件API,如LV2。这也是我们想出了Pipewire的名字。到2018年底,我有一个带有类似插孔图模型的工作音频服务器,嗯...至少在我的基本测试用例的上下文中工作。

经过一些与Linux Pro-Audio社区成员进行了一些讨论,他们确信我需要在调度和混合的方式中进行更多的剧烈设计变化,如果这是能够替换他们的杰克。这是当最终重新架构开始并最终成为2年的发展后,2020年初的第一个0.3版。

CS:我知道你提到的专业音频支持在社区中有很多嗡嗡声,所以你最初是谈论的,那么接收到远离更广泛的专业音频社区?

WT:如上所述,我在2018年初与他们讨论过一些讨论。Robin Gareus和Paul Davis有助于推动导致目前实施的变化。

我认为每个人都喜欢拥有无缝,综合和用户友好的体验,可以用于Pro和消费者音频用例,并且对Pipewire如何发展来实现这一目标,肯定有兴趣。我们还没有在特色奇偶校验方面,尽管我们正在快速移动。例如,就在本周,我在Pipewire登陆了续流的支持,这应该在你读到这一点时出来。超越延迟报告是剩余的大TODO项目。此外,虽然PipeWire可以管理与千斤顶相同的延迟,但我们尚未可靠。所以还有一些工作要做。

CS:脉冲蔓延开发人员怎么样?他们是如何服用波纹的到来? Lennart诗歌现在讨厌你吗?

WT:我认为他们很好。我们于2018年10月组织了一个哈克菲,其中一些Pulseaudio开发商谈论Pipewire,所以这不是一个惊喜。事实上,这是一个长时间的Pulseaudio贡献者目前正在研究管道的Arun Ragahavan。我还与Lennart在早期与Lennart交谈,他都是为了统一亲和消费者音频的想法,所以我不认为他讨厌我♥

CS:您也是GStreamer的创建者,您如何在用例中看到这两个项目?

WT:我将PipeWire视为一个低级级别的框架,以在应用程序和设备之间移动数据。它非常擅长处理原始音频和视频以及与设备接口。它不太擅长Muxing和Demuxing,它不想做一些更高级别的多媒体任务,例如实现RTSP服务器或处理透氧格式。 GStreamer仍然非常适合那些更高级别的任务,Muxing,Demuxing,编码,解码等。

WT:他们绝对相互补充。我没有看到一个超越另一个。它仍然很早就知道事情发生在哪里,但我可以看到像音频或视频效果链一样的东西在Pipewire中更好地实现。虽然管道和后处理在GStreamer中更好地完成。

WT:绝对!几乎所有新的令人兴奋的蓝牙工作都是由社区贡献者完成的。

Pauli Virtanen一直在解决此处的修复,例如对SCO插件进行许多蓝牙改进和一般修复和稳定性改进,实现编解码器切换和延迟报告。他还有他的双手在其他领域,例如PipeWire IPC连接和会话管理器中的默认节点和策略,以及一些对象管理改进。

Huang-Huang Bao(EH5)维护了PulseAudio-Modules-BT的贡献了很多变化,如LDAC ABR支持,硬件卷支持以及众多稳定性和兼容性固定,以使蓝牙支持达到同一级别作为pulseaudio模块。

我们还有Collabora贡献者George Kiagiadakis和FrédéricDanis定期贡献蓝牙,构建和其他修复程序作为其AGL参与的一部分。他们还在致力于一个名为Wireplumber的改进的会话管理器,我们将在Fedora 35中包含。

Dmitry Sharshakov实施了蓝牙电池状态报告,这是Bluez中的一个相对较新的功能,现在也支持Pipewire。

虽然没有直接绑在Pipewire本身,但在Jan Grulich,Martin Stransky和TomášPopela之前提到的工作也是PipeWire支持在Web浏览器中也是前进的重要一步。所有工作都同样的工作JonasÅdahl确实创建了屏幕捕获门户并在GNOME shell中实现它。我也想特别提到乔治史塔法斯塔拉卡斯为他的伟大工作让PipeWire支持进入ObsOse。 Jan Grulich还完成了大量工作,让PipeWire支持进入KDE。

还有很多人在问题跟踪器上活动,试图帮助分类错误,提供帮助和改进维基页面。

CS:正如您一直在测试和使用PipeWire之前,您有没有知道的应用程序,但您发现的是由于人们报告的人没有与PipeWire合作,或者在寻找测试用例时发现?

WT:大多数Midi工具,真的。在我开始在Pipewire添加支持之前,我从未真正使用MIDI。我对各种合成器着迷,如Helm,Zynaddsubfx,更近距离和免费的Vitalium应用程序。

当您拥有以前很少或未知的Midi和Jack兼容性时,有一个全球音乐创作工具。我之前不知道任何LSP或CALF插件。

我喜欢Inge的想法,我很乐意看到它发展得更多。我想到这样的工具可以用来模拟和调整管道中的效果链。

CS:在Pro-Audio和MIDI方面,您是自己的音乐家,是您看到自己在使用个人前进的情况吗?

WT:我自己玩了一点吉他,但我老了,我塞进真正的管放大器没有效果,我堵塞了。我在Arodor中使用了一些吉他和声音的录音,使用Pipewire来测试事物。我对创建代码非常感兴趣,以便其他人可以制作你实际上要听的音乐♥

CS:您认为需要在Pipewire中解决的剩余物品是什么?

对于桌面用例,我们需要使用Pulseaudio达到合理的特色奇偶校验。我们缺少网络流的自动检测和设置以及通过HDMI的压缩格式的Passthough,如DTS和AC3。

对于Pro Audio使用情况,我们需要实现Jack中的内容被称为续流,然后延迟报告。

在那之后,我们可以开始看看我们现在可以用皮舰的所有令人兴奋的新事物。我们可能在某些时候看着声音控制面板的重新设计。

在视频前面,可以提高很多。我们尚未有视频处理管道,更不用说管理此类视频管道的工具。

CS:是否有任何特定领域您希望在Pipewire看到更多贡献者?

WT:当然!我认为现在有很多令人兴奋的事情。例如,我们没有真正的parkbay。我们依靠杰克工具,但那些不处理视频流。我会说一个简单的诅咒是一个很好的贡献。

在PipeWire中,它相对容易地编写新的外部汇来自源。我很乐意看到像Roc左右的良好通用网络协议的本机实现。

CS:你最近开始在Red Hat里面的一份新的工作,你能告诉我们一些关于潜气管的方式吗? WT:是的,我是Red Hat里面的新信息娱乐集团的一部分,最初将专注于为Sutomotive部门提供软件堆栈。 这是关于启用汽车的音频和视频,而且波管将在意识到这一点。 Pipewire已经是汽车级Linux的一部分,以及Wireplumber。 其中一个挑战是能够以灵活的方式将所有音频捕获和播放流路由到汽车中。 现代汽车还有大量需要管理的摄像机。 该计划的一部分是改善管道的这些用例。 期望是,这些用例中的一些也将使桌面用户最终受益。