RVCを使用したAIボイチェンVC Clientの遅延時間を調査してみる

VRChat
スポンサーリンク

はじめに

こんにちは!お久しぶりです。

今日はAIボイチェンであるRVCについてVRChatで使用に耐えられるのかリアルタイム性、応答性能、遅延時間について少し調査したので紹介します。

以下の環境で調査しています。

遅延時間の調査

RVCとは何か

RVCとはここではVC Client(Realtime Voice Changer)を指します。使うには色々な方法がありますが今回は最も簡単な事前ビルド済みの Binary での利用の方法を取ります。私の場合は、Windows環境でNVIDEAのグラフィックボードを使用しているのでフレームワークが「ONNX(cpu,cuda), PyTorch(cpu,cuda)」と記載されている「MMVCServerSIO_win_onnxgpu-cuda_v.1.5.3.18a.zip」を用いて「start_http.bat」で起動できる方法を取りたいと思います。

マイク入力からPCまでの遅延時間

Virtual Desktopを用いた場合のマイク入力からPCまでの無線通信の遅延時間を調べます。

方法

UR242へ接続したマイクと、HMDのマイクに同時に同じ音を入れて、OBSでそれらのを音を同時に録音します。録音した音声は私が作成したデコードソフトto_wavでwavファイルに変換後に波形解析ソフトspwaveを用いて差分を調べることで遅延時間を求めます。

結果

117msの遅延がありました。

所感

Meta Quest LinkAir Link といった方法での遅延時間も調べたかったのですが、大変だったので調査せず。とりあえず無線通信をすると100ms程度の遅延があることが分かっただけでも成果かなと思います。

ここの遅延を避けたい場合は、マイクだけは直接PCに接続するといいと思いますが、無線通信というメリットを捨てる必要があるので悩みどころでしょうか。

ボイチェン出力のマイク入力遅延時間

HMDのマイク入力は、Virual Desktop Streamer の仮想デバイスであるマイク (Virual Desktop Audio)に入ります。そしてマイク (Virual Desktop Audio)の音声がVRChatのソフトの入力に入り、HMDからの声がVRChat上へ配信されることになるのです。

VRChatでボイチェンを使う場合は、VRChatのインプットをボイチェンの出力した情報を入れる必要があります。つまり、マイク (Virual Desktop Audio)から、ボイチェン後の音が入ってくる別の音声入力デバイスに変更する必要があります。

方法

マイク入力の方法はざっと以下の3種類あるのでこれらの遅延時間を調べます。

  • 物理ケーブル接続
    • 音声デバイスをAとBの2つ用意して、Aの音声出力をBの音声入力にケーブルで物理的に接続する。
  • ループバック利用
    • 音声出力をマイク入力として扱えるループバック機能がある音声デバイスを使用する。
  • 仮想接続
    • VBCABLE_Driver_Pack43のような仮想ドライバを用いて、カーネル空間で音を接続する。

遅延時間を調べる方法はOBSを用います。OBSでは音の入力用デバイスだけではなく、音の出力用デバイスをモニターする機能もあるため、これを用いてオリジナルの音と、入力で入ってきた音との遅延時間をspwaveで調べます。

結果

結果は以下の通りになりました。

接続方法 詳細 遅延
物理ケーブル接続 UR242→Realtec Audio Input 54 ms
ループバック利用 UR242→Loopback 16 ms
仮想接続 VB-Audio Virual Cable 2 ms

所感

正直、仮想接続が早いことに驚きました。ここは相性問題などなければ VBCABLE_Driver を用いること一択かと思われます。ループバックは早いとは思ったのですが、外部へ音声信号が出てしまっているのでそのあたりで、やはり遅延が発生している思われます。

ボイチェン単体の遅延時間

以下のようなソフトになるのですが、用意されたキャラクターの声が出せるようになるソフトです。キャラクターは自分で作ったり、他人が作ったものを追加することが出来ます。

方法

遅延時間に関係しそうなパラメータが複数ありますが、すべてやろうとすると時間が足りないので何となく関係していそうなパラメータを絞り、その値を変える際に他のパラメータを変えずに変更して確認という方法を取ります

以下は着目したパラメータです。後は上記の画像のような設定で設定で調べています。

  • F0 Det.
    • F0とあるので恐らく声の高さを求めるアルゴリズムの設定かと思われる。アルゴリズムは計算時間に関係があるのでここを変更してみて調べてみる
  • CHUNK
    • よくわからないですが、msと時間が書いてあるので、この値は大きいほど遅延時間に関係していそうなので調べる。たぶんバッファ的な感じのものだろうか。
  • EXTRA
    • よくわからない。2の累乗になっているため、何らかのサイズを表すように見えるが。これもバッファ的な設定であれば大きいほど遅延するように見える。
  • GPU
    • cpuかgpuのどちらで計算するかという部分である。これも計算時間に関係ありそうである。
  • Quality(Advanced Setting)
    • 品質をLowかHighで選べる。これも計算時間に関係ありそうである。

実際に遅延時間を調べるためにこれまで通り、OBS+to_wav+spwavを用いて調べます。

結果

結果は以下の通りになりました。

F0 Det CHUNK EXTRA GPU Quality 遅延
rmvpe_onnx 96 (256.0 ms) 4096 cpu low 1050 ms
rmvpe_onnx 96 (256.0 ms) 4096 gpu low 749 ms
rmvpe_onnx 96 (256.0 ms) 4096 gpu high 726 ms
crepe 96 (256.0 ms) 4096 gpu high 894 ms
fcpe 96 (256.0 ms) 4096 gpu high 724 ms
rmvpe_onnx 96 (256.0 ms) 8192 gpu high 622 ms
rmvpe_onnx 64 (170.7 ms) 16384 gpu high 582 ms
rmvpe_onnx 96 (256.0 ms) 16384 gpu high 954 ms
rmvpe_onnx 512(1365.3 ms) 16384 gpu high 2920 ms

ちなみに、遅延が 622 msと書いてある結果の部分だが、GUIのresの表示上の値は 130 ms になっていました。いかにも応答時間を示すような値がmsで表示されるのですが、実際の遅延時間と違うため参考程度に留めるといいと思います。おそらくですが、このresは内部の純粋な理論値のようなものではなのではないでしょうか。

所感

  • F0 Det
    • ここの種類が違うと遅延時間に関係あるようである。例えば、crapeとfcpeで100ms程度の差が出てきていた。
  • CHUNK
    • 結果を見る通りやはり、遅延時間に直結するようである。短すぎると変換の精度が悪くなるのである程度大きくする必要があります。
  • EXTRA
    • 実際に測った感じ、遅延時間に影響がありそうでないようでよくわからない感じでした。
  • GPU
    • やはりCPUよりグラボを用いた方が早いようです。
  • Quality
    • 遅延に影響があると思ったのですが、ないので驚きでした。ただ処理負荷は必ず上がっているはずなので、CPUやGPUの性能次第ではlowという選択肢もあるのではないでしょうか。

まとめ

遅延時間を少なくするには以下がポイントでしょうか

  • PCと有線でマイク接続をする。(無線だと遅延 +117ms)
  • ボイチェン出力とVRChatとは仮想デバイスで接続する。(有線接続だと遅延 +50ms)
  • CPUではなくGPUで変換する。(CPUだと遅延 +300ms)
  • F0 Detを工夫する。(遅いの比べて早いのは遅延に 100ms 差がある)
  • CHUNKを自分の声や変換モデルで最適値を見つける。

最後まで読んでいただきありがとうございます。

コメント

タイトルとURLをコピーしました