SDVXとbeatmania IIDX INFINITASをWindowsからLinuxへ移した大きな理由の一つは、PipeWireなら低レイテンシの音声出力とOBSへの分岐を同時に実現できると見込んでいたからだった。実際にPipeASIOを導入して調べた結果、両方のゲームを44.1 kHz、64 samplesで安定動作させられた。
現在のソフトウェア側の片道出力レイテンシは約4.24 msと推定している。Windows時代に使っていたVoicemeeterやVB-Audioを介する構成より明確に短く、しかもOBSでの収録を諦める必要がない。Proton、Wine、ゲーム固有の制約に対処してまでLinuxへ移行した狙いが、ようやく音声経路でも形になった。
Windowsでは低レイテンシと収録が衝突した
WASAPI exclusiveはWindows Audio Engineを迂回して小さいバッファを使える一方、デバイスを占有する。Microsoftの仕様でも、WASAPI loopback captureはshared modeでのみ利用でき、exclusive modeでは利用できない。そのため、ゲームをexclusive modeで出力しながら、同じ音を普通のOBS desktop audioとして取り込むことはできない。
ASIOも同様にWindows Audio Engineの外側を通る。OBSへ渡すには、オーディオドライバ固有のloopback、仮想ASIO、Voicemeeter、VB-Audio Cableなどを使い、ゲームから物理出力までの途中へ仮想デバイスを挿入する必要がある。
以前のWindowsでのINFINITAS ASIO構成では、VoicemeeterのASIO入力64 samples、仮想入力1024 samples、WDM出力128 samplesを直列に通していた。単純合計だけでも1216 samples、44.1 kHzで約27.57 msになる。
その後にさらに詰めた時期の記憶でも、VB-Audio側は512 samples前後が安定動作の限界だった。512 samplesだけで約11.61 msあり、さらに物理デバイスへ渡す後段のバッファが加わる。Windows exclusiveやnative ASIOだけを単独で使えばもっと短くできる可能性はあるが、それではOBS収録という必要な機能を同時に満たせない。
PipeWireではOBSが再生経路の途中に入らない
LinuxではPipeASIOを使い、WineのASIO出力をPipeWire nodeとして公開した。概念的な接続は次のようになる。
SDVX / INFINITAS
|
PipeASIO
|
+----> Sound Blaster GS3
|
+----> OBSOBSはゲームと物理出力の間に直列挿入されるのではなく、PipeWire graphから並列に音声を受け取る。OBS内部には録画や同期のためのバッファがあるが、それは録画側の遅延であり、GS3へ出る音を同じ長さだけ遅らせるものではない。
この構造によって、ゲームへは64-sample ASIO bufferを提示したまま、物理出力とOBSの両方へ接続できる。Windowsで仮想オーディオデバイスを挟んでいたときとは、録音機能のためのバッファを再生経路が直列に通らない点が本質的に違う。
64 samplesで安定するまで
両ゲームは44.1 kHzを前提としている。一方、使用しているSound Blaster GS3のALSA nodeは48 kHzで動作するため、PipeWireが44.1 kHzから48 kHzへ変換している。
最終的なPipeASIO設定の要点は次のとおり。
- 入力0、出力2 channels
- hardwareへ自動接続
- fixed buffer sizeを有効化
- preferred buffer sizeを64 samplesに設定
- sample rateを44.1 kHzに固定
follow_device_clockを無効化- PipeASIOのRT priorityを無効化
- PipeWire graphも64-sample quantumで動作
- PipeASIOからGS3へ直接接続
INFINITASはASIOデバイスの名称を限定しているため、PipeASIOのCLSIDを保ったまま、Wine registry上でXONAR SOUND CARD(64)として見せる設定も必要だった。
SDVXでは当初PipeASIO 1.5.0を使ったところ、約3秒ごとに一瞬の音飛びが発生し、その瞬間に画面も引っかかった。debug logとPipeWire graphを照合すると、接続先device chainのlatencyを検出するたびにkAsioLatenciesChangedをhostへ通知し、SDVXがPipeASIO driverを再ロードしていた。
この挙動はバッファ不足ではなかった。PipeASIO 1.4.3へ戻すと周期的なlatency通知とdriver再ロードがなくなり、最終的には64 samplesで実際にプレイしても音切れせず安定した。切り替え直後の128-sample動作を繰り返し監視した際には、pw-top上のエラーカウンタは増加せず、process callbackの最大処理時間も約173 usで、2.90 msのdeadlineに対して十分な余裕があった。
レイテンシの内訳
64 samples、44.1 kHzの1 periodは次の長さになる。
64 / 44100 * 1000 = 1.451 msPipeASIO 1.5.0で128 samples動作を観測したとき、接続先device chainは1 quantum + 59 samplesと報告されていた。59 samplesは、GS3までの経路と44.1 kHzから48 kHzへの変換に由来する追加遅延と考えられる。
同じ構造を64 samples動作へ当てはめると、片道出力レイテンシは次のように推定できる。
| 内訳 | samples | 時間 |
|---|---|---|
| PipeASIO buffer | 64 | 1.45 ms |
| PipeWire/device chainの1 quantum | 64 | 1.45 ms |
| device chainの追加分 | 59 | 1.34 ms |
| 合計 | 187 | 約4.24 ms |
約4.24 msは64 samples動作時に外部loopback測定した値ではなく、128 samples時にPipeASIO 1.5.0が報告したdevice-chain latencyを使った推定値である。GS3内部のDSPやDAC、アンプ、スピーカーの音響遅延も含まない。それでもWindows時代のVB-Audio 512 samplesだけで生じる約11.61 msより小さく、実用上の差は明確である。
設定を詰めれば無限に短くなるわけではない
PipeWireのrealtime priorityやCPUのperformance profileも調べたが、これらは処理落ちを防ぐための余裕には影響しても、音声が通るbufferの公称レイテンシを直接短くするものではなかった。効果が確認できなかった追加のPipeWire RT設定は削除した。
現在はPipeASIOとPipeWireの両方が64 samplesで動き、非同期動作による追加bufferもなく、ゲームからGS3へ直接接続されている。GS3が48 kHz固定で、ゲームが44.1 kHz固定である以上、残る主な削り代はsample-rate conversionとALSA device側の安全余裕になる。ここを削って得られる可能性があるのは1 ms前後であり、安定性を失う危険に見合わない。
別の44.1 kHz native対応audio interfaceを使えばさらに短くできる可能性はあるが、GS3を使う現在の構成としては64 samplesが実用上の到達点だと思う。
Linuxへ移行した意味
Windowsはゲームの動作環境としては当然に近く、Linuxでコナステ音ゲーを動かすまでには多くの問題があった。INFINITASではWineのMedia FoundationとWMA再生を修正し、Gamescopeや画面キャプチャも調べ、ASIO driverの組み込みとゲーム固有registryまで用意した。SDVXではPipeASIO自体のversion差による周期的な再初期化も追うことになった。
それでもLinuxへ移したのは、単にWindowsを避けたかったからではない。PipeWireのgraphなら、低レイテンシ再生、OBS収録、アプリごとの分岐や監視を同じ音声基盤で扱える可能性があったからだ。映像をPipeWireで扱おうとした試行と同じく、ゲームを遊ぶ経路と観測・収録する経路を分離しつつ接続できることに価値を感じていた。
今回、SDVXとINFINITASの両方で64 samplesが安定し、OBSを利用するために大きな仮想bufferを再生経路へ挟む必要もなくなった。Windows exclusive単体との最小値だけを比べれば、Windowsにも同等に短い構成はあり得る。しかし「低レイテンシでプレイしながら、その音をOBSにも渡す」という自分の用途を同じ条件で比べるなら、Linuxのほうが明確に低レイテンシで、かつ汎用性が高い。
苦労してでもLinuxへ移行したことで得たかったのは、この両立だった。