ボイチェンのFFTをさらに高速化してサーバとiPhoneで比較した話 #ASJ2021a
今回のブログはアカデミックな研究とメタバース開発の境界分野での開発についてGREE VR Studio Laboratory （以下ラボ）の白井暁彦ディレクターとインターンとして活動している堀部貴紀でお送りします。
前回のブログでは、『転声こえうらない』の声質変換エンジンでベースとなっているOSS「音声分析合成システムWORLD」について、変換過程の高速フーリエ変換（FFT）でAccelerate Frameworkを用いたiOS実装のお話をさせていただきました。その内容を2021年9月に日本で最も大きいこの分野の学会 音響学会秋季研究会 (#ASJ2021a)では『FFTライブラリを対象とした実時間Vocoderの速度比較』というタイトルで発表を行わせていただきました。
学会発表的なスライドはこちらになります。
「詳しくは論文と当日の発表スライドどうぞ！」で終わってしまえばいいのかもしれませんが、今回のブログではこの研究成果をメタバース時代のサービスに使うために、皆さんが気になりそうな「じゃあどれぐらい速いの？使えるの？」というあたりを徹底的に調査したので解説してみようと思います。
まずこちらがWORLDの関数を使用したボイスチェンジャー処理の実装例になります。（「転生こえうらない」では若干異なる実装ですが）流れとしてはこんな感じで処理されています。
そしてラボでは「転生こえうらない」でのGCPサーバ版とは別に、iOS実装を開発してあります。ただ作るだけでは実用にはなりませんのでAccelerate FrameworkとWORLDで使用されている大浦FFTのFFT速度比較に関するベンチマークの計測を行いました。社内勉強会でiOS版(WORLDのC++をラップする形のSwift実装)でのベンチマーク結果を共有していたところ、普段AIやデータ分析などを担当するグリーグループの開発本部の橋本さんが「おもしろいね！ちょうどFFTの演算環境があるのですが」と興味をもっていただけたので、つよつよ演算環境である Intel XeonプロセッサAVX-512環境 等とも比較することになりました。いわゆるスパコンなどに使われるベクトル演算おばけですね。いまの「転生こえうらない」も十分高速なのですが、もっと高速になればいろんな表現ができるようになるかもしれません。
実験
以上のような背景から、従来のiOSテスト環境であった iPhoneXS Max(A12 Bionic)に加え、Intel Xion搭載AWSサーバ、Core i7プロセッサ搭載PCといった環境下において FFTW3 と Math Kernel Library (以下、MKL) に置き換えた場合についても同様にベンチマークを計測しました。またコンパイラとコンパイラオプションの違いによる速度比較も行いました。並列化については比較するためにあえてコードベースでは実施しません（コンパイラの能力だけで比較）。実験環境は以下の通りです。
実験では、信号音が持つ周波数と信号音の標本化周波数が異なる信号音を使用しました。
- {100, 200, …, 800} [Hz] の正弦波
-サンプリング周波数 {16, 24, 48} [kHz] に設定された125, 250 Hzの正弦波
※もちろん並列して一般的な配信で使いそうな音声なども試していますが、速度比較のためには再現性のある標準音源を使います。
各ビルド環境＆ハードウェアで100回試行し、計測された平均処理時間に対するReal Time Factor (RTF) を用いて評価しました。
音声研究用語「Real Time Factor」とは
処理対象の音源の再生時間に対する処理に要した時間の割合です。1秒の音源の処理に1秒要した場合、RTF = 1.0です。RTF < 1.0 のとき実時間処理が可能であることを示しています。
音声分野においてリアルタイム性を検証する際に用いられる指標です。
（ Real Time Computing - Wikipedia ともいうらしい）
実験結果
こちらは、PC, サーバでの結果にiOSデバイス環境(この実験ではiPhoneXS Maxを使用)での結果（水色）をプロットしたグラフです。ふつうの研究は自分が自慢したい最も高速な環境をそれぞれ可視化するものなので、なかなかサーバとフロントエンドを比較する機会はないと思います。そういう意味では貴重なグラフです。簡単に表現すると「水色の線よりも下側にある部分がiPhone XS Max (A12 Bionic)よりも速いサーバ環境」と読んでいただければだいたい理解としてあっています。
結論から表現すると「Core i7環境下でoneAPI-MKLでビルドすると最速」。また同環境下で比較すると、WORLDで実装されている大浦FFT（京都大学数理解析研究所 大浦拓哉先生が公開している世界中で使われているFFTライブラリ、SETI@Homeにも使われているそうです）から各環境に提供されているFFT関数に置き換えることで高速化が期待できることがわかりました。世界中のWORLDファンには朗報ですね！
(マニアックな注ですが) WORLDでは声の高さを推定する範囲の上限が800 Hzに設定されています。（ constantnumbers.h#L22 ）そのため、800 Hzの信号音は無声音として処理されたことにより、他の信号音と比較してRTFが極端に小さくなっています。
一言でいえば「自分が頑張って作ったiOS版がある条件では負けてしまった！」ということなのでややショックですが、よく見ると周波数によって依存がありますし、高価な数理解析用サーバとiPhoneXS Maxが互角の戦いをしているという意味でも興味深いデータになっています。
今回の結果に対するマニアックな方々向けの考察です。
【PC向けCPU < サーバ向けCPU】
- シングルスレッドを重視
- Turbo Boost により一時的なCPU周波数が高くなった。
【8124M と 8275CL の比較】
- TurboBoostが考慮されず、CPU周波数の差が見られなかったため、結果の差があまり見られなかった。
【周波数依存】
iOSの内部処理で何らかの工夫がありそう（入力音源で動的に変化するコードは書いていない）。大浦FFTとAppleのAccelerateでも明らかに違う特性があり、後に詳細データ比較します。
続いて、oneAPIのコンパイラについて、自動並列化オプションによる比較のグラフです。（PP0: 自動並列化が有効の場合、NP: 無効の場合）
自動並列化を無効、シングルスレッドに強制したとき、わずかながら速くなりました。このわずかな差は並列化のオーバーヘッドと考えています。
次にFFTW3について、OS付属のものとIntelが提供しているAVX512と呼ばれる命令セット付属のものによる比較を行いました。
【公式HP より】
AVX512は、科学的シミュレーション、財務分析、人工知能 (AI) / ディープラーニング、3D モデリング / 分析、画像およびオーディオ / ビデオ処理、暗号化、データ圧縮などにおいてパフォーマンスを向上させることができるSingle Instruction Multiple Data streams (SIMD)命令セットです。
AVX512 などのSIMD命令セットではClock周波数を動的に切り替える特徴があります。しかし本実験では、Clock周波数の低下や切り替え時のオーバーヘッドが発生し、AVX512の効果が十分に見られず、OS付属のFFTW3の方がRTFが小さいという結果になりました（最初から並列化だけに注力して検証を進めなくてよかったです…！）。
最後に、iOSデバイス環境における標本化周波数の異なる音源を用いたときのRTFの比較です。まず、WORLDにおける声質変換処理と125Hz, 1秒の信号音を使ったときのFFT呼び出し回数をまとめた図です。音声の3つの特徴を分析し、利用者が選択したパラメータに加工した上で合成することを想定しています。
このWORLDでの声質変換処理を意識して各処理ステップごとに色分けしたRTFの棒グラフがこちらです。（上：大浦, 下：FFTAccelerate）FFTが多く出されるD4Cや音声合成部分のSynthesis2で差が広がっています。
標本化周波数 48kHzのとき、大浦FFTのRTFが1.0を超え、RTF が Accelerate < 大浦FFT であることから，Accelerate を使用することで 48 kHz においても iOSデバイス上でリアルタイム処理が可能であることがわかりました。さきほどのRTF水色折れ線グラフでもいえることですが、Accelerate は、音源が持つ周波数の変化に応じたRTF の変化が小さいことから、安定な声質変換処理が期待できるといえます。
音響学会でいただいたご質問より
2021年9月に行われたポスター発表にて、データパッキングや品質、速度差に関するご質問をいただきました。
Q. 大浦FFTからFFTW3などに置き換えてなぜ速くなったのか？
A. FFTW3とMKLの場合、Intelが提供しているSIMD命令を使用することやIntelのコンパイラにおいて命令セットの並びなどの最適化が高速化に寄与していると推察します。
Q. ライセンスについて
A. 大浦FFTはOSSでアプリ組み込みにフリーなことから使用されています（WORLD開発者 森勢先生談）。FFTW3やMKLはそれぞれライセンスが明記されていますのでそちらに従っていただければ幸いです。
Q. データパッキングをしているのか？データパッキングによる高速化は考えられるか？
A. Accelerate Frameworkでは独自のデータパッキングを行なっています。（前回のブログを参照）そのため、アプリ開発者側によるデータパッキングが高速化に寄与していると考えられます。
まとめ・課題・今後の可能性
WORLDでの声質変換のiOSへの最適化を起点に始まったこのプロジェクトですが、今回はFFT関数を置き換えることによる速度比較のお話をさせていただきました。内部で使用されている大浦FFTをFFTW3や各環境に最適化されたFFTに置き換えて得られる効果は十分にあることがわかりました。この結果はボイスチェンジャーだけでなく、音声配信の品質向上や、音声認識、ノイズキャンセリング、メタバース時代の立体音響など幅広い応用の可能性があると思います。
またiOSデバイスとサーバの比較ですが、実験で使用したAWSをはじめとしてサーバ環境は使用したCPU時間に対してコストが発生します。サーバ側変換の通信経路や遅延、ケーブルやユーザの通信環境など総合的な可搬性・可用性とともに考慮すると、Accelerate Frameworkを用いてiOSデバイスで変換処理を行うことも十分に実用的だと考えています。もちろんAndroid環境との比較なども行っていく必要がありますね！
今回の研究では、ベンチマークのために単一の周波数を持つ信号音を用いています。いわゆる「ピー」という音です。そのため音声配信などの実用を検討する上ではさらに多様な発話による周波数の変動から発生するオーバーヘッドを考慮する必要があります。
iOS デバイスで Accelerate Framework を用いた場合の音源が持つ周波数に応じたRTFの変化が小さい理由は謎のままですが、おそらく大規模な数学的計算を高性能かつ低消費電力に最適化して行うためであるという Accelerate の特徴からだと考えています。Accelerate Framework を使うことで周波数の変化に応じた処理時間の変動が小さく、安定的な声質変換処理が期待できるという面で継続して比較検討をしていきたいです（ドキュメントが本当に少ないですが！）。
また今回の研究を通して、5G通信網のような高速低遅延な環境においても、ターゲットとする速度に対して、アルゴリズムの互換性とともに柔軟な設計を行うためのデータを取得できたことは意義深いと考えています。5G事業者の皆さま、こういう研究（Mobile Edge Computing/MEC）にご興味ございましたらぜひGREE VR Studio Laboratoryにご相談ください。
さいごに、ご支援・ご指導いただいた、明治大学の森勢先生、開発本部の橋本さんありがとうございます。
GREE VR Studio LaboratoryでのR&Dについて
GREE VR Studio Laboratoryでは先進的なXRメタバース時代のユーザエクスペリエンスを未来のREALITYで実現すべく、プロトタイプや実験サービスの開発や発信を行っているREALITY株式会社の研究開発チームです。
REALITYのメタバース時代を先んじて、VR/AR/MR/WebXRといった時代のUX開発や熱狂共有システム「VibeShare」の開発、音声関係では「転声こえうらない」を通した、ボイスチェンジャー利用者の声の特徴や利用環境の統計的分析など、基礎的な研究から産業向けのPoCなど幅広く・深く・ものすごいスピードで研究と発信を行っております。中長期のインターンや、オンラインワークショップ「VTech Challenge」なども運営しております。ぜひWebやTwitter、YouTubeチャンネル（http://j.mp/VRSYT）をご参照ください。
学術成果だけでなく、REALITYの中でこういう研究をやりたい方！
こちらの最新求人リストも是非ご参照ください。
関連文献（論文リスト）
・堀部貴紀, 石原達馬, 白井暁彦, 森勢将雅; 『転声こえうらない』利用者の基本周波数分析, 情報処理学会研究報告, [SlideShare] (2020/05/30)
・堀部貴紀, 白井暁彦, 森勢将雅;「『転声こえうらない』を通したボイスチェンジャー品質改善のための定性分析と考察」, 日本音響学会2021年春季研究発表会, [SlideShare] (2021/3/11)
・堀部貴紀，橋本順之，白井暁彦，森勢将雅; 「FFTライブラリを対象とした実時間Vocoderの速度比較」, 日本音響学会2021年秋季研究発表会, [SlideShare] [Web](2021/9/8)