PipeWire環境でWine/Protonの音ゲーを遊ぶなら、winepulse.drv は避けたほうがよい。winepulse.drv が、PipeWireのPulseAudio互換サーバーから得た最小要求量を大きく拡大し、Windowsアプリへ大きなWASAPI shared bufferを見せるからである。
PipeWireのquantumが128 frames、44.1 kHzで、PulseAudio互換層の最小要求量が1 quantum相当なら、そのバッファーは約87 msになる。これはWindowsクライアントから見えるバッファーであり、実際の総遅延と同一ではない。しかし、後段にはPipeWire graph、USB、DACなどの遅延も存在するため、約87 msという時点で音ゲー向けのバッファとしては大きすぎる。
PipeWireのquantumを小さくしても解決しない
標準Wineの通常のWASAPI shared modeでは10 msのdefault periodと3 periodsのバッファーにより、30 msが下限になる。winepulse.drv の問題はquantum 128 framesでは、その下限を大きく上回る約87 msのshared bufferをWindowsアプリへ見せることである。安定運用が難しいほど極端な32 frames以下まで下げて、ようやくWine共通の30 ms下限へ到達する。
つまり、PipeWire graph全体へ厳しいリアルタイム処理を要求しても、得られるのはwinepulse.drv自身の保守的なバッファーを相殺することだけである。
winepulse.drv は安全側に寄せたバッファー設計をしており、再生の安定性を優先する通常用途には向いていても、入力に対する発音の速さが重要な音ゲーには保守的すぎる。
かわりに何を使うか
そもそもPipeWireを採用しているホスト環境でPulse経路を使う理由はない。
Windows側で低遅延にする方法としてWASAPI event-driven exclusive modeがあるが、Wineでは利用できない。winepulse.drv以外のバックエンドを替えても、制約はWine共通部分にある。
ゲームがASIOに対応していればPipeASIOを使うとPipeWireとネイティブ接続し、WASAPI event-driven exclusive modeと同等の処理により小さいバッファで安定した再生を得られ、理論上もっとも低遅延になる。
WASAPI shared modeしか選択肢がなければwinealsa.drvか、winepipewire.drvを使うのがよい。前者はWineに標準で組み込まれているため扱いやすく、PipeWireのALSA PCM Pluginであれば物理デバイスを排他利用することもない。後者はWine標準ではないがPipeWireネイティブ接続のためshared modeの最低遅延を狙える。ただしWindowsの30ms下限制約があるので、その後段を削減しても全体への影響は小さい。
参考
- Linuxでコナステ音ゲーの低レイテンシとOBS収録を両立した
- WineのPulseAudioドライバー実装 - PulseAudioから得た
minreqの10倍をdevice periodとして報告している