Pipewireについてざっくり調べたこと

PipeWire は Linux の次世代マルチメディアサーバーで、PulseAudio や JACK の後継的な立ち位置を目指し、オーディオとビデオ両方を扱える仕組みになっています。
PipeWire が音を鳴らす仕組みをざっくり内部動作から調べてまとめてみました。

---

1. 基本構造

PipeWire は大きく分けて以下の役割を持っています：

• デーモン (pipewire)
  サーバープロセス。クライアント（アプリケーション）やデバイスとの橋渡し役。

• クライアントライブラリ (libpipewire)
  アプリが使う API 層。PulseAudio 互換の libpulse や JACK 互換の pipewire-jack もここに載る。

• セッションマネージャ (例: wireplumber)
  実際のポリシー（どのアプリの音をどのデバイスに流すか、どの権限を与えるか）を決める制御レイヤー。

2. 音が鳴るまでの流れ

例: ブラウザで YouTube を再生して、スピーカーから音が出る場合

1. アプリが音声ストリームを生成

   • ブラウザが ALSA / PulseAudio API などを通じて音声バッファを生成。
   • PulseAudio 互換レイヤーを通すと、実際には PipeWire のクライアントライブラリに接続される。

2. PipeWire に接続（ノードとして登録）

   • PipeWire では「音の流れ」は ノード (Node) という単位で表現される。

     • アプリ → 出力ノード
     • デバイス（スピーカー）→ 入力ノード

   • ノードは「ポート (Port)」を持ち、ポート同士が リンク (Link) される。

3. セッションマネージャがルーティングを決定

   • wireplumber が「このアプリの出力はデフォルトのスピーカーへ」というポリシーを実行。
   • その結果、アプリの出力ポートとスピーカーの入力ポートがリンクされる。

4. リアルタイムスケジューラによるデータ転送

   • PipeWire のコアは グラフスケジューラになっており、各ノードを依存関係に従って順番に実行。
   • 音声バッファは 共有メモリ (SHM) や memfd を使ってゼロコピーでやりとりされ、遅延を最小化。

5. デバイスへ出力

   • 最終的に ALSA デバイス（例: hw:0,0）に PCM データを書き込み、スピーカーから音が鳴る。

3. 仕組みのポイント

• 音声や動画処理の統一的な扱い
  音声の流れ全体を「ノードとリンク」で抽象化。JACK と同じ発想。
  これにより、音声だけでなく動画処理も同じ仕組みで扱える。

• 低レイテンシ
  JACK 並みの低レイテンシを狙って設計されており、PulseAudio の欠点を解消している。

• 互換性

  • PulseAudio アプリ → pipewire-pulse が吸収
  • JACK アプリ → pipewire-jack が吸収
  • ALSA アプリ → alsa-plugins 経由で接続可能

• セキュリティ
  Flatpak や Wayland と統合し、アプリごとにオーディオアクセス制御を可能にしている。

4. まとめイメージ

[App: Firefox] --(libpulse/libjack/ALSA)--> [PipeWire client]
     ↓
  [Node: audio stream] --(Link)--> [Node: output device (ALSA)]
     ↓
  [Speakers] → 音が出る

PulseAudioとの違い

PulseAudioは、それまで長らくLinuxオーディオの標準で、またプロ向けオーディオのJACK（音をルーティング（配線）し、同期させること）でもありました。

主要な違いを以下の表にまとめてあります。

PipeWire vs PulseAudio 比較表

項目	PulseAudio	PipeWire (最新の標準)
主な用途	一般的なデスクトップオーディオ	オーディオ ＋ ビデオ ＋ プロ向け音響
遅延 (レイテンシ)	やや大きい（動画視聴などは問題なし）	極めて低い（楽器演奏や制作に向く）
セキュリティ	限定的（サンドボックス外からのアクセス）	強固（Flatpakなどの分離環境に最適化）
リソース消費	中程度	低い（効率的なメモリ・CPU管理）
互換性	自身の規格のみ	PulseAudio, JACK, ALSAのすべてに対応
ビデオ機能	なし	画面共有（Wayland等）の標準規格

よく一緒に使われるWirePlumberとの違い

PipeWireとWirePlumber、どちらもLinuxのオーディオ・ビデオ環境でよく目にする名前ですが、役割は明確に分かれています。

一言でいうと、

• PipeWireは「音を鳴らす仕組み」そのもの。
• WirePlumberは「Bluetoothヘッドセットがつながったら自動でそっちに切り替える」といった「賢い動作」を担当するもの。

です。
PipeWireは「道具（ハードウェア・ソフトウェアの基盤）」であり、WirePlumberは「その道具をどう使うかを決める指揮者（セッションマネージャー）」とも言えます。

---

• 役割: PipeWireに対して「どのデバイスを有効にするか」「音量をどう設定するか」「アプリの音をどこに流すか」といった命令を出します。
• やっていること: Luaスクリプトを使用して、自動接続やデバイスの優先順位付けなどの複雑なルール（ポリシー）を実行します。
• 特徴: 以前使われていた pipewire-media-session の後継であり、より柔軟でカスタマイズ性が高いのが特徴です。

---

主な違いの比較表

特徴	PipeWire	WirePlumber
分類	グラフ処理エンジン / サーバー	セッションマネージャー
例え	楽器や音響機材、ケーブル	指揮者やミキシングエンジニア
主な目的	データのストリーミングと処理	接続の自動化とポリシー管理
設定方法	主に設定ファイル (.conf)	Luaスクリプト
依存関係	単独で動作可能（だが不便）	PipeWireが必要

Waylandでしか使えない？

いいえ。X11（従来のデスクトップ環境）でも問題なく動作します。

PipeWireの役割と環境の関係

PipeWireが何に使われているかによって、状況が変わります。

機能	Waylandでの状況	X11での状況
オーディオ管理	必須/標準。音声出力・入力の制御。	利用可能。PulseAudioの代わりとして動作。
画面共有	必須。セキュリティ上、PipeWireを経由しないと画面が写せない。	選択的。従来のX11の仕組みでも共有できるが、PipeWireも使える。
ビデオ管理	Webカメラの共有などに使用。	Webカメラの共有などに使用。

なぜ「Wayland用」だと思われがちなのか？

それは、Waylandにおいて画面共有を実現するためにPipeWireが「絶対不可欠」だからです。

• X11の場合： どんなアプリでも、OSの全画面の情報を勝手に覗き見ることができました（これがセキュリティ上の弱点でもありました）。
• Waylandの場合： セキュリティが厳しく、アプリが直接他の画面を覗けません。そのため、**「PipeWireが画面の映像を仲介し、xdg-desktop-portalという仕組みを通してアプリに渡す」**という手順が必要になります。

この「Waylandで画面共有するならPipeWireを設定してね」という解説をよく目にするため、Wayland専用というイメージが強まったのだと考えられます。