DAWにおけるSMT（HTT）有効無効の話

オーディオを処理するとはどういうことか

　今回の話に「だからこうだ」というように結論づけるものはないのだけど、言及している記事が見つからなかったので書きなぐっておく。

　オーディオのリアルタイム処理というのは、いわゆるベンチマークソフトでスコアの大小を競う、というような時間制約のない処理とは事情が異なる。

　動画のエンコードや3Dレンダリングのような時間制約のない処理は、8スレッド16スレッド32スレッドと処理を並列化（複数人で分担作業する）することで、プロセッサ全体における時間単位のスループットが上がり、結果的に処理能力が向上するというのは直観的でわかりやすい話だ。

▲ AIDA64のCPUベンチマークの例。並列で処理するユニット数、スレッド数が多いほど（クロックも高いほど）スループットは上がりスコアが上昇する。

　対して、DAWやオーディオ機器のCPU、DSPといったデジタルオーディオのリアルタイム処理においては、入力されたデジタル信号を1sampleごとに加工して出力するという処理を連続的かつ、リアルタイムに行う都合上、いわば制限時間のようなものがある。

　どういうことかというと、サンプリング周波数（FS）が48kHzのばあいは単純に1sampleを1/48000秒以内に処理する。0.2msecの処理を1秒間に48000回繰り返してバッファに出力している。遅延しうる要因はいろいろあれど、これが遅延してしまうと0.2msという枠から溢れ、出す音声がなくなってしまって、「ブツッ」とディップが発生して音が切れることになる。フィルタ処理やらリバーブなどの畳み込みやら処理が増えるとさらに計算に要する時間が増え、この枠内での処理時間のマージンは減っていく。

▲ 音の時間波形をSampleレベルに拡大したもの

　CPUにはオーディオ処理以外にリソースを食う様々な割り込み処理（OSのカーネルだったり、Chromeでネットを見るだったり未知の割り込み）が発生するから、処理した音声をそのまま出力するようなことはせず、一旦サンプルバッファにためた音声をストリーミング出力するわけだけど、バッファサイズが大きければ当然レイテンシは増え、バッファサイズが小さければ空になるリスクが高くなる。入力に対する遅延を軽減したければバッファサンプル数を減らすことになるが、そうなれば音はブツブツと切れてしまうリスクが高まることになる。リアルタイムオーディオ処理は「いかに途切れさせないか」という細かい制限時間の連続と、バッファのバランスで動いている。

ブツッと切れたら終わり。シビアなオーディオ処理

　20年くらい前の環境では、ソフトシンセは重いの代名詞のようなものだった。単純にCPUのパワーが「対時間に支配的なリアルタイムオーディオ処理」に耐えられるような処理リソースを持ち合わせていなかったからだ。

　当時AMD K6-2 333MHzというCPU環境で、VSCというローランドのソフトシンセを動かしていたことがあったが、FS=44.1kHzで再生しようとするとしょっちゅう再生がブツブツと途切れ、処理がビジーになり最悪OSがBSODで落ちるなんてこともザラにあった。リアルタイム再生時は22.05kHzに下げ、高音質な44kで聴きたいものはバウンスしてデータ化してから聴いていた。

▲　Virtual Sound Canvas（VSC）。当時はこのソフトたった1台動かすのも大変な負荷だった。

　ここで、オーディオにおける「重い」とはどういうことか考えてみる。

　ゲームなどであれば、重くてもフレームレートがちょっと下がる程度で遊べないことはないかもしれない。動画のエンコードも重いフィルタ処理が入れば、本来１５分で終わるものが２０分に増えるかもしれないが、５分待てばよい。しかし、オーディオにおいては処理切れによって「ブツッ」と音が途切れたら終了、その時点で使い物にならなくなってしまうシビアな処理になる。

　なので、当時は専用のオーディオを処理するDSPを積んだハードウェア（外付けMIDI音源モジュールやシンセサイザ）にその辺の処理を任せ、結果の音波形だけそのハードウェアからもらうと言うのがセオリーだった。これによってソフト処理で実現できないようなリッチな表現を実現していた。

▲　外付けMIDI音源モジュール。昔は専用の外部機材で処理した音を、PCに戻すことで負荷を抑えることができた。

　時代は進み、CPUの性能も指数関数的に向上した今、容易にソフトシンセが動く時代になっている。伴ってDAW（DTM）において制約の多い（後からアップデートが利かない）ハードウェアを積極的に使う理由は薄れ、いわゆるDTM音源の衰退に繋がった。
（伴って、ソフトではマスタリングプラグインなど処理も増えたので重いことに変わりは無いが）

　ということで、DAWなどのリアルタイムオーディオ処理において、CPUスペックの向上というのは「処理が速くなる」というよりは「許容負荷の限界に対するマージンが増える」という方が合っている。

　また、連続的な処理が必要なオーディオは並列化が難しく、メニーコアを搭載したDSP（旭化成のAKシリーズなど）でも大抵シリーズ直列での処理になる。オーディオにおいてはコア数などのユニット数よりも、シングルスレッドの処理性能の方が効くというのが現状だ。IPCが同じ1GHzの4コアCPUと、2Ghzの2コアCPUであれば、後者の2コアの方がディップリスクという観点で許容範囲は広いといえる。

　もちろんDAWでは様々な処理（ジェネレーターや受けのミキサ、エフェクタを分けて処理するなど）が動いているのでコアは多いに越した事はない。

DAWにおいてSMT（HTT：ハイパースレッディング）は害悪か

　で、SMTの話。

　SMTというのはSimulataneous Multithreadingの略で和名では同時マルチスレッディングという技術のこと。インテル製のCore i7 i9などではハイパースレッディング（HTT）ともいう。どういう技術かというと一つのCPUコアで複数スレッドを走らせる技術の事。１コアで２スレッドというのが一般的かと思う。マイクロアーキテクチャの専門ではないので受け売りだが、コアの処理時間の隙間時間を使って２スレッド目も走らせれば効率的だよね、という技術の事。

▲　SMTを搭載したCPUをタスクマネージャーで確認すると、コア数に対して論理プロセッサは２倍になっている。

　例を挙げると、以下のような一連の処理があったとする。

①厨房でコックがパスタを作る
②できたパスタをホールスタッフが受け取り運ぶ
③お客が受け取って食べる
④おいしいと言う

　普通はこの「厨房でコックが」から「おいしい」までが一つの処理として何回も繰り返されるわけだけど、ホールスタッフが運んだりお客が食べてる間、コックは何もしない時間が生まれている。そこで、お客が食べてる間の待ち時間中に次の注文（２スレッド目）のパスタをコックが作り始めて、空いている時間を使って別の処理を走らせる、というのがSMT。

　ただ、単純に性能が2倍になるかというとそうではなく、処理内容によるが大体1.3倍くらいの効果となる。ベンチマークなどで評価してみると、SMTを有効にするとやはりスコアは1.3倍相当になり、処理できるタスクの「量」が1.3倍になる。

　つまりSMTを有効にすれば1人のコックでもパスタの総生産量がザックリ1.3倍増えると言うこと。これは動画エンコードや3Dレンダリングの話にあったバッチ処理において大きな恩恵がある。

　これをリアルタイムオーディオ処理の観点で見るとどうか？

　1コア2スレッドの場合、2コア2スレッドと状況は異なり、処理するコアが一つしかないので、当然1コアに割り当てられた2スレッド目の処理は待ち時間が発生する。パスタの例で言うと「コックが一人しかいないので、他の客のパスタが調理中の場合、自分の注文したパスタも調理が始まったけど、出てくるのが遅い」と言うことが起こりうる。前述した時間的制約のあるリアルタイムオーディオ処理に於いては、当然別スレッドが動いている間の待ち時間があるというのはディップのリスクがある。

　なので、オーディオのリアルタイム処理においてSMTという仕組みだけ見れば「デメリットとなり得る要素しかな」く、単純にSMTも含めた高スペックを謳うCPUが最善手かというとそうとは言えない。

　ここまでが個人的な一般論だ。

メーカーの問題意識と取り組み

　たとえばオーディオ処理のタスク優先度が十分高く、タスクそれぞれが別の物理コア上で動くようにスレッドが割り当てられるとするならば、今回の話は何ら問題にはならい。

　しかし実際どうか？というと、情報がなく結構あいまいでよくわからない。

　Cubaseの例では6までのバージョンではSMT（HTT）を無効化することを明確に推奨しており、7以降は「Hyper-Threadingに由来するドロップアウトの危険性も下げる」ためのASIO-Guardと言う仕組みを導入するなどの対策を取っている。
https://japan.steinberg.net/en/support/support_pages/hyper_threading.html

　FL Studioもマルチスレッディングによってジェネレータやミキサの処理をスレッドごとに分けているが、SMTが有効の状態でどうか（１コアに２スレッド割り当ててしまうことがあるのか）、そのあたりのケアがされているかは調べた限り、明確に明言されている情報は発見できなかった。

　FLの開発者であるGolが「ハイパースレッディングはクソだ」なんて公式のスレッドで発言しているのを見たことがあるので、問題意識はあるのかもしれない。

　結局「じゃあリスキーならSMTを無効にしよう」となりそうな話ではあるが、DAW専用機ならまだしも、動画エンコード、3Dレンダリングなど他のクリエイティブ用途におてSMTは十二分メリットがあるわけで、それだけのためにCPUのパフォーマンスを下げるような行為を進んでやれるか、というと難しい。

CPUの進化＝やれることが増える＝重くなる＝工夫する

　ここからは余談。
　
　実際、SMTの弊害の範疇に入ったとて、現代のCPUスペックであればそんなことは気にしなくてよい程の処理能力は有しているので、殆どの人がそのデメリットを感じることは無いかもしれない（SMT有効時にスループットが1.3倍アップなら、1スレッドの最悪値は0.3とザックリ考えることができるが、0.3CPU時間は昨今のオーディオ処理に対してどうか？と考えると十分許容できる範疇だと思われるため）。

　ただ、SMT云々関係なく、現実のDAW環境は自分のトラックメイキングの方法がフリーダムすぎるせいか結構重く、よく処理の限界を感じることがあり、ジェネレータを数十本、エフェクタを数十本刺し、後段にはマスタープラグインを刺し、常にマスター状態聴くというやり方をやっていたりするすると、重さによって稀に起こるディップで音がブツッと切れたりする。

▲　Ryzen 3950Xの環境下でも、48kHzのエディットですら自分のやり方ではFLのCPU使用率は常に60％前後を遷移する。これが96kHzになると単純に処理負荷は2倍になるため、今のような作り方で96kHzネイティブ編集は厳しい。一時期Fs96kHzでエディットしていたこともあったが、重くて妥協が多くなり、結局48kHzに戻してしまった。

　そんなことが起きると、どうにかこうにか足搔きたくなるもので、実態はただ単純に重いだけなんだろうけど、SMTによる懸念を払拭したいと思いたくなるもの（実際BIOSでSMTを無効にしてもあまり変化を感じたことはないが）。

　FL Studio4（当時はFruity Loops 4）の時代、サンプリングレートを下げる、シンセの音をバウンスして貼り付ける、なんていう、PCスペック不足からくる工夫の日々を一時期経験している自分としては、制約を気にせず自由にエディットできる、というのは余計なところに脳のリソースを使わなくて済むし、発想する余裕も増え、時短にもなるので、常々「無茶できる」環境というのは重要視しているポイント。
　
　２０２１年現在、音制作環境は当時からは考えられないくらい、制約がなくなった。しかし、オーディオ処理はまだまだ重くなる余地が残されている。

　ハードウェア１台では１系統しか使えないようなエフェクトも時代は進んで、VSTの台頭でエフェクトを複数同時に、何重にも起動できるようになり、数MBでリッチといわれた音色も今や数GBになり、要求スペックもどんどん上がっていく。これは今後もしばらく続いていくはずだ（処理に余裕ができればFS=96kHzでのリアルタイム処理後、マスターでダウンサンプルするというフローがスタンダードになることが予想できるので、そこだけ見てもまだまだ重くなることが想像できる）。

　しばらくはこの絶妙な均衡が続き、少し背伸びをしたエディットはオーディオ処理の制約にかかってしまい工夫が必要、という時代が続くだろう。