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