筆記: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。我們期望這些用例中的一些最終也會使桌面使用者受益。