間違いだらけのリアルタイム (再生) パフォーマンスと CPU パフォーマンス (バウンス)
え〜、いつもながら、どこから仕入れたのか全くわからない「間違った情報」が耳に入るので、別に放置してもいいのですが、質問がやたら飛んできたりするので、面倒くさい 簡単には答えられないので「情報をまとめて公開します…」と言って返答から逃げていたという経緯があり、この記事を書いております。
きっかけは以下のツイートでした。
とーくばっく の著者 David さんが X (旧 Twitter) で求められていた意見というのは「CPU の負荷が高いと DAW は演算の切り捨てを行ってるか。」という事実関係で、これを発端として、いくつか質問 DM が飛んできたので、David さんへのご回答並びに、質問者への回答として記事を書いています。
これに関して David さんを抜きにして語るとまた変な誤解が生まれるとも限らないので先に David さんからのご意見をこちらに記載させていただきます。
CPU 負荷が高い場合、DAW は演算の切り捨てを行ってるか
こちらのご意見は「CPU がドロップアウトしているわけではなく、限りなく処理負荷の高い状態のときに DAW が処理を変える、または処理を間引く」という意見があったことに起因していると思われますので、前提条件や経緯を理解した上でかつ、リスペクトを持って以下の David さんのご意見をお読みください。
CPU: 負荷が高いからって勝手に演算結果を変えることはできません。じゃあ富岳は演算結果がおかしくならないように70%以上の負荷はかけないの？っていう。
DAW: 簡単な掛け算、足し算しかしていません。これ以上処理を単純化する余地はありません。
Plug-ins: CPU の正確な利用状況を知るのは困難です。利用率を % で把握できても、自分だけが原因なのか、ほかのプラグインが負荷をかけているだけなのか判断できません。条件の可能性が無限大にあり、いちいち対応していられません。バグ混入とか、予期せぬ動作を行うリスクを高めるだけでなにもいいことはありません。
唯一考えられるのは負荷増加を検知した DAW からプラグインに対して「ちょっとしんどいんで処理を簡略化してくれんか？」とリクエストを送ることですが、私の知る限りそのような連絡のメカニズムはそもそも備わっていません。仮にあったとして、マルチコアへの負荷分散が苦手な DAW 郡が、正しく状況判断して的確な指示をプラグインに出せるとは思えません。
まず、リアルタイムのほうが音がいいとか、バウンスは音が悪いとか、DAW は演算処理を間引くとか、全く エビデンスがない主観的な情報 は抜きにして、一旦、基礎的な事実を皆さんにお伝えいたします。昔から疑問だった業界に伝わる真偽が不明な妄言はすべて忘れて各個人で考えましょう。
念押ししておきますが、今回語るのは 基礎的な処理構造 の話で現在の最新の技術では基礎的な構造から更に複雑な構造になりますので、局所的なものを見ると違う状況は存在するということは気に留めておいてください。
って、そもそもこの業界には通ぶってたり、その分野に精通しているようで全く実はそうではなく、ホラを吹く人がたくさんいるので…
今回も自分一人じゃ、絶対に間違いを言ってしまう恐れがあるので、海外の有識者や技術者とチャットしながらここに記載する情報をまとめさせていただきますので、おそらく日本語の情報では一番信用できるかと思います。ただし、実際には結構ブラックボックス的な要素もあり、情報も若干古い場合もあるので、あくまで今回の話の定義付けの中だけの話ということで、だから結局はネットの肥やしですが。
DAW パフォーマンスとコンピュータパフォーマンスの話
コンピュータの見かけ上のスペックがいいからと言って、リアルタイムパフォーマンスがいいかというと必ずしもそうではありません。ただし、ある程度の相関関係があるので、この話はややこしくなります。
例えばの話ですが、最新機種のハイグレード CPU を利用している人と何世代前のハイグレード CPU を利用している人では、明らかに CPU パフォーマンス は前者、最新機種のほうがいいと思います。
ただし、CPU パフォーマンスが良ければ DAW パフォーマンスが上がるか、というと実はそうではありません。これ系の話は実は以下の動画で私が解説しているので暇な人はご視聴してみてください。こちらの動画では「DSP 処理パフォーマンスが向上すれば、DAW パフォーマンスは向上する、ということは実際には異なる」ということを解説しています。
上記の動画では、非常に初歩的な内容を語っているに過ぎませんが、要点は、CPU や DSP はメモリ構成に依存し、結局 演算パワーのみだけではパフォーマンスは向上しない、という事実だけ理解できればいいです。実際にはリアルタイム処理にはもっと深い構造への理解が必要ですので以降、それについて詳しく語っていきます。
また、これも蛇足となりますが、オーディオカルト (わざと カルト と表記しています) と称して、コンピュータオーディオにおけるリアルタイム再生の問題について別口で語っている記事がありますので、暇な方は読んでおくといいでしょう。
DAW のパフォーマンスと CPU のパフォーマンスの監視状況
意外とみんな知らない事実なんだけど、DAW が「再生処理キツいよ〜」って言っているとき CPU は「DAW の処理キツいよ〜」なんて言ってません。証拠はこちら。ちょっと時間経過が広いのはごめん。
つまり、DAW が「再生処理キツイよ〜」って言ってるとき、CPU がボトルネックになっているわけではない。もちろん「シングルコア性能がー」とか言い出したらキリがないが、状況証拠的には「DAW のリアルタイム再生能力は CPU の処理能力が決定的に影響するとは言えない」事ががわかる。
もちろん、元々 CPU の演算能力だけがシステム全体のパフォーマンスに影響していた場合はこれに当てはまらないし、最近は要求コストが低下しているので、実際の状態と当てはまらない場合もある。が、あくまで現在はシステム全体の応答性能の話をしていて、特定の状況の話はしていないという前提を忘れてはいけません。そうしないと理解できないというか、理解し難いという印象しか残りません。
つまり、この状況だけを見れば「CPU の理想的な処理能力が DAW では活かしきれていない状況」である。だって全体のパフォーマンス画像から見ると 25% しか CPU の能力を発揮していないわけで 75% も処理能力限界を余らせている。どっちの表示を信じるのか、みたいな水掛け論は抜きにして、実際にはかなり複雑な問題が絡んでいるので、それらの情報を日本語で得ることはまず無理かもしれない。
え、でも待って「パソコンを新調すると明らかに処理能力が向上すると実感できるじゃん！」って人、いると思います。そうですね、新しいパソコンを新調したことと、CPU の処理能力が向上したことは、イコールなのかもしれませんが
「DAW のリアルタイム性能が向上したのは本当に CPU だけのおかげなの？」
この質問に完全に応えることができるのであれば、それは本当なのかもしれませんが、あなたは言葉に詰まるか、私に反論しても「でもそれってあなたの感想ですよね？」って言われるのが落ちかもしれません。または「たまたま あなたの場合は特定の条件が揃っていただけです」ってこともあるでしょう。いずれにせよ、この問いにはこの記事を全部読んで、すべてがちゃんと理解できるのであれば必然と答えが見えてくるでしょう。
いちいち書いてるとテンポが悪いのですが、通常 CPU が新しくなるとマザーボードだって新調する羽目になるし、通信規格が変わってシステム全体の処理限界や応答性能が良くなって、って感じで CPU 単体で換装することはほぼ稀でしょう。
2021 年以降の最新機種ではそこまで頻繁に影響される現象ではありませんが、下記の画像は一例で、GPU の処理能力がプラグインの描画にかなり処理を持っていかれているときの図です。実はこれ、DAW を再生していない状況で 8 Thread 持っていかれているので、マルチコア処理分散、マルチスレッド処理が難しい、苦手な DAW は速攻で CPU Overload、CPU Dropout が起きます。
まとめると「CPU パワーは余っているのにリアルタイム性能は非常に不十分である」という事実を受け入れましょう。「リアルタイム性能は CPU 性能が決定的な要因にはなり得ない」という事実を受け入れましょう。もちろん「シングルスレッド性能がー」とかいうと、ややこしくなるので、ここでは RT CPU の詳しいことは抜きにしています。
リアルタイムパフォーマンスと CPU パフォーマンスはシステム全体の様々な影響を受け、変化をします。これはもう受け入れましょう。量子力学と一緒です。納得できないけど実際に数式に沿って世の中は動いているんだ。
DAW とその他のアプリケーションの違い
非常に良く引き合いに出されるのですが「Word や Text Editor のデータが変わらないように、DAW のデータが変化することはありえない」という説明をされる方がおります。これはある意味正しくてある意味間違っています。
読み出すデータには変化はないでしょうが出力されるデータはそれはもうめっちゃ変化します。それについて長い議論はしたくないので、以下でも参照してください。
合わせて読みたい
限りなく誤差をなくしたいのであれば、外部デバイスなぞ一切使わないようにして、64-bit float 信号を常に利用し、プラグインを一切利用しない、そして書き出しするときも 64-bit float を心がけてください。この話はここでおしまい。
DAW というアプリケーションの構造を知る
DAW というのは、一部を除き Video Editer や Word や Excel、Web ブラウザなどとは違い、外部デバイスと常に通信を行う必要性があります。MIDI 機器だったりオーディオインターフェイスだったり、必ず、入力または出力デバイスが必要です。
そして、それらは頻繁に入力処理と出力処理を (それは超高速で) するため、入力処理と出力処理を行ったり来たりします。それがリアルタイムで行われることを考えるとデータを継続的に処理する必要があります。
例えば、MIDI キーボードを押してから実際にはレイテンシーがあって、タッチよりも遅くモニターに出力されます。これは皆さんもご存知ですよね？
ではビデオ編集ソフト (Video Editer) の場合はどうなのでしょうか。実は通常のビデオエディターはユーザー入力とプレイバック (再生) は完全に切り離されており、プレイバック (再生) とは別に微調整を行ってから再生の表示を行い、さらにまた微調整が入って、再生が開始されます。
従って調整が完了するまで再生ボタンを押しても再生が開始されません。
さて、この応答性がどのようにリアルタイムパフォーマンスと関係しているのでしょうか、のちのち理解できると思います。
割り込み処理の話
これについてはコンピュータのドライバー開発経験のあるプログラマーとかに詳しく聞くのが一番いいとは思いますが、まず知られていない情報としていくつか紹介しておきます。
DAW で音声を再生するときに必要な要素を知っていますか？
こう聞かれると、言葉に詰まってしまうと思いますが、答え自体は簡単です。
- 保存されているデータを読み出ししなくてはいけないので SSD/HDD からの読み出しが必要
- Virtual Audio Instrument を立ち上げる場合はメモリ上 (DAW 上) にソフトを立ち上げ、SSD/HDD からの読み出しが必要
- プラグインを利用する場合、メモリ上 (DAW 上) にプラグインを立ち上げる必要
- 実際にアナログ信号を扱う必要があるのでオーディオインターフェイスのドライバが必要
- オーディオインターフェイスが実際に相互通信するための USB/Thunderbolt が必要
考えうるだけでこれだけの相互応答が求められます。CPU がプラグインの処理だけをしているわけではなく、インターフェイスの相互通信をするためにを割り込み処理をかけたり、SSD や HDD の読み書きだしに割り込み処理をかけたり、CPU とメモリ上でデータを常にやり取りしたり、と非常に構造が複雑なのです。CPU くんは非常に短い時間の合間に、各部署から「これやってー、あれやってー」ってヒキリなしに仕事を振られながらそれををこなしてて偉い。
そこで問題となるのが、割り込み処理というもの。簡単に言うと コンピュータにおいて行われている処理を一時中断し、別の処理を実行すること を指します。この一文覚えておいてください。簡単に言うと「メインプロジェクトを進めているときに同時進行で雑務を頼まれる社畜」と同じ状況だ。
割り込み転送や処理というものは他の処理を停止させて、それ自体を処理させるというものです。これを踏まえて次の項目をお読みください。
みーんな間違えているバッファの話
簡単な構造の話、AD/DA Converter はどのようにオーディオをコンピュータと橋渡ししているのか。
知らないかもしれないけど AD/DA Converter Chip 自体にも Buffer があり、実は AD/DA Chip 自体にもレイテンシーがあります。つまり、みんな知らないかもしれないけどオーディオインターフェイスには超えられない遅延の壁が物理的に存在します。ただし、ms とかの次元の遅延ではないので、これはただの考慮しなくていい豆知識だと思ってください。
リアルタイム再生についての議論なので DA Convertion についてだけ考慮してお話しましょう。
以下の動画の 8:21 過ぎあたりからの引用を交えてお話いたします。以下の内容は私は専門家ではないので突っ込まれると困ります。ので、Steinberg の ASIO の設計者とかに聞くことを強くオススメします。
オーディオコンバーターは継続的に信号をモニターに出力する必要があるので、デジタルオーディオは連続的なストリームが必要です。このオーディオデータはいくつかの「塊」チャンクに分けて転送され、このチャンク「塊」はバッファサイズ (Buffer Size) と呼ばれます。
このバッファサイズはシステムの応答性に関係します。
オーディオがバッファに移動されると変換に時間がかかります。これはオーディオをバッファに移動するサイクルが継続的に行われるからです。そして DA がアナログ信号を生成することを待ちます。その変換のほんの僅かな時間の間に、次のバッファを埋める必要があります。デジタルオーディオを受信して、それをアナログ信号に変換するまでこのサイクルは延々と続きます。
DAW は即時に応答する必要があるため、このバッファは常に非常に小さくしなければならず、DA は１度に１つのバッファしか埋めることができないために、頻繁にチャンクが補充され、DA を繰り返します。(画像キャプションに補足あり)
従ってバッファサイズが小さいほどシステムへの応答が増加します。バッファが小さいほど効率的でシステムの他の要素は CPU が長時間ロック (長時間割り込み) されないようにする必要があります。そのため、DAW のパフォーマンスは他のほとんどのアプリケーションよりもリアルタイムパフォーマンスに大きく影響を受け、DA のバッファがシステムを極端に駆動させます。従って、他のほとんどの処理タスクに必要な応答時間よりも遥かに早い応答時間が求められます。
では「システム内のデバイスがリアルタイム性に優れている場合」というのはどういう状況なのかを考えます。つまりそれは、繰り返される割り込み処理にも対応しつつバッファも埋める事ができるシステムのことです。システムが要求する処理要件に対応しつつ、バッファも満たした状態を常に保つことができるため、安定して一定のストリームを DA に送ることができます。
では問題のあるシステムというのはどういう状況の事を言うのでしょうか。システムの一つが CPU を長時間ロック (と言ってもバッファサイズ並の僅かな時間) してしまうとバッファを埋められずにオーディオデータストリームにギャップがあるか、さらには文字化けしたようなランダムなデータの塊となって転送されます。
もちろん DA Converter はバッファの中身は知りませんし、考慮もしません。ゴミのデジタルデータをゴミのアナログ信号に律儀に変換し、最終的にスピーカーからゴミが聞こえてきます。
これらが時折聞こえるポップノイズやクリックオンやパチパチノイズ音で、コンピュータはバッファがいっぱいになるまですべてを一時停止するだけです。その場合に途切れた音が聞こえたり表示されたりします。どちらの場合にせよ、バッファが時間内に満たされなかったためにオーディオストリームが途中で途切れます。
これは こちらの項目で説明したように CPU 自体はすべてを処理するのに十分すぎるほど強力ですが、必要以上に速い音声処理、 特にリアルタイム再生の場合のオーディオストリームの問題は CPU が原因ではありません。不安定なオーディオストリームの原因は CPU の処理が追いつかなかったのではなく、他の割り込み処理デバイスに CPU がロックされているためです。
そのため、より強力なプロセッサを搭載したとしてもオーディオクラック音、パチパチ音は減少しないでしょう。CPU がボトルネックではない可能性が高い、と言えるのは CPU がいずれかのデバイスの処理要件に対処できないほど強力ではない可能性がある、とは、それは流石に現代では考えられないからです。
つまり、リアルタイム再生の性能を向上したいのであれば、CPU 以外のデバイスや外部機器の能力を見直すべきなのです。
よくある割り込みの問題の一例
ネットワークトラフィック (ネットワークドライバの割り込み処理)
ストレージの書き込み読み込み (I/O 処理やコントローラー処理)
バックグランドサービス (macOS ではこれは特定が困難な場合がある)
解決策としては、ネットに繋がない、ストレージの速度や容量を気にする、LatencyMon で自分で調査する、など
もちろん、利用しているサードパーティ製品に非常に左右される話なので、リアルタイムのプリントレコーディングと非リアルタイムの書き出し時間があまり変わらない、なんていうサードパーティ製品もゴマンとあります。
これらは CPU の処理能力がボトルネックと考えてもいいとは思いますが、それは DAW 自体のパフォーマンスとは関係がなく、プラグインのパフォーマンスの話となります。もちろん、プラグインの処理パフォーマンスを含めて DAW のパフォーマンスと定義付けるのであればその限りではありませんが、今話している内容は DAW 本来の応答性能について議論しています。
バッファサイズの簡単な総括
以上のことをもって リアルタイムプレイバック (再生) で問題が起きることが CPU が問題ではない、ということがわかったでしょうか？ DAW の機能自体で計算を飛ばしたり間引いたりしているわけではなく「Buffer が割り込み処理によって満たされていないから、リアルタイム再生に問題が起きる」という原理を十分に理解していただけたでしょうか。
もちろん、コンピュータをアップグレードしたらリアルタイム再生のパフォーマンスの向上を実感できた、というのは CPU だけが原因ではなく、システム全体のコンポーネントのパフォーマンス向上のおかげである、ということも挙げられるでしょう。
割り込み処理が非常に問題になるデバイスやコンポーネントがある場合、CPU を変えても意味がないということで、CPU の処理能力向上が絶対に影響しない、ということを言いたいわけではありません。シングルスレッド性能が物言う処理は CPU の能力がカギになっちゃうっていう。
オーディオの書き出しの話
こちらも動画からの引用を利用して日本語に翻訳しております。
リアルタイムエクスポートと非リアルタイムエクスポートには２つの違いがあります。
非リアルタイムエクスポートでは連続的なオーディオストリームではないため、オーディオインターフェースで要求されるような正確な時間間隔ではなく、データが利用可能になったときにディスクに書き込まれる可能性があります。これにより、プロセッサは実行する必要がある他のすべてのタスクの中でオーディオ処理を行うことができます。
つまり、リアルタイムプロセスとは異なり、バッファ転送がいつ発生するかを CPU が制御できるため、バッファ転送が失敗する状況は決してありません。プロセッサは各チャンクで一度に多くのデータを提供できるため、非常に強力なプロセッサを使用している場合は、 短時間で大量のデータを処理でき、リアルタイムの処理能力が低いプロセッサよりもはるかに高速にディスクに書き込むことができます。
リアルタイムシナリオでは、プロセッサは特定のバッファ期間中、単一バッファ分のデータしか提供できません。将来のバッファ転送に備えてデータを保存することができません。これは強力なプロセッサがビデオレンダリングするには大きく役立ちますが、DA ではそれほど役に立ちません。
オーディオは CPU が一度に提供できるデータのバッファーは 1 つだけであり、正確に定義された間隔で提供する必要があるため、CPU が他のデバイスによって邪魔されていない場合でも、※1 CPU の処理能力を使用してさらに多くのバッファーを埋めることはできません。
つまり、オーディオのバッファサイズを増やすと多くの問題を解決できるのはそのためです。つまり CPU がオーディバッファを埋める機会を増やせば他の処理のロックアップに対処する時間を回避できるということです。
非リアルタイムエクスポートには多くの時間が費やされますが、CPU は機会があればいつでも必要なだけバッファを埋めることができるため、結果として何か他の処理が起こるまで CPU が費やす時間が大幅に短縮されます。平均 CPU 使用率ははるかに高く、レンダリングパフォーマンスは CPU パフォーマンスに強く依存します。
これがリアルタイムプロセスと非リアルタイムプロセスの違いです。
ちょっと脱線
※1 に関して、実は Reaper には Anticipative FX Processing と言う機能があり、上記画像の真ん中あたり赤枠内に機能のチェックボックスがある。これはバッファを埋めるという意味で正確かどうかわかりませんが、可能な限り FX 処理を予測し、CPU の使用率を削減できる効果が見込めます。
バッファサイズ (オーディオドライバに一度に渡すサンプル数) が 128 であったとしても、CPU 能力が余っていれば先々まで処理を進めておく機能のようです。(すぐにドライバに渡さずに RAM に貯め込みます)
このため、突発的に処理が追い付かない場面が生じても貯金があるので簡単には音声が途切れなくなります。もちろん、その分設定した先読み時間だけ再生開始から遅れて音が出ます。
この DAW というかの Reaper の機能により、FX の処理の予測ができるという点で CPU の処理能力を使用してさらに多くのバッファーを埋めることが事実上可能です。
この機能は Buffer を埋める機能というよりは先読みをして Buffer Size を小さくできる、つまり処理指定した Buffer Size よりも余裕を持ってリアルタイム性を確保できるという意味を持ちます。つまり CPU 使用率が下がる、しかし、状況によってはポップノイズやクリック音の原因になる場合もある。
つまりは、ちゃんと機能を理解して設定を利用しよう。
そして VST プラグインの互換性というか状態維持の項目には Inform plug-ins of offline rendering sate なる項目がある。あまり詳しくないのだけど、Reaper 以外の DAW にも、もしかしたらサイレントで実装されているのかもしれませんが、Offline Rendering (Bounce) と Online Rerndering (Bounce) 時のプラグインの挙動に関して通知項目はない。
ただ、Reaper にはちゃんと設定項目がある、ということだけ覚えておこう。
この機能の意味としては、稀にオフラインとオンラインで動作が異なるプラグインがあるので、レンダリング時に問題が起きないようにレンダリングしてますよ〜ってプラグインに知らせておく機能で、簡単に言うと、ちょっとお馬鹿さんなプラグインのための機能。
表面的な機能として Rendering 速度が向上する。他の意味では通知を外すと、おそらく Repaer は Rendering 時でもリアルタイムと同じように処理する、と思われる。
もちろん Rendering オプションにも非常に多岐にわたる機能があり、一部の稀なプラグインは Offline で Rendering するとパフォーマンスやサウンドが異なる場合があります。そのために Online Render オプションがあります。これは他の DAW でもあるオプションですね。
(Idle) などのオプションは非常に難しいオプションで、Idle 状態で書き出したときの結果とそうではないときの結果を比較し、どちらかを選ぶ、みたいな、ちょっとかなりレベルの高いオプションになります。どちらがいいか、というのはセッションによって異なるため、極限を突き詰めたい方はご自身で検証しまくってください。
DPC Latency の話
僕らの界隈では既に語り尽くされている話ですが、一応、言及しておきます。
前に、データの保存方法で音が変わるのか、という記事を書いています。
もうちょっと端折りますが、これは USB の外部ストレージからデータを読み出し、USB の外部ステレージに保存するデータとコンピュータ内部の SSD からデータを読み出し、內部 SSD に保存したデータを聴き比べる、的な内容の記事です。
これらの差異を作り出したものに関しては特に言及していませんが、ほとんどの問題が割り込み処理と USB のデータストリーミングに関連していると推測できます。現代のコンピュータは DPC Latency に関してはほぼ対処が不要か対処困難になっているため、可能性をできるだけ排除する、ということを目指します。
macOS で一番厄介なのは Wifi やネットワークドライバの割り込み。特に対処法がないので本気で環境を構築するなら、Internet から隔離して、常にネットには繋がず、Offine で利用するとかを考えなくちゃいけない。
あと重要なのが USB のストリーミングアナライズ、正しいデータがちゃんとリアルタイムに相互に通信できているのか、は重要。これは非リアルタイム通信とリアルタイム通信で非常にごっちゃになる話なので、絶対に切り分けて考えよう。
これらの影響が強いコンピュータの場合、リアルタイムの再生では CPU のパワーはほぼ無意味になってしまう。現代ではほとんど考慮できなくなってきているので、CPU がボトルネックに当てはまる状況も増えているのは事実なんだけど。
また、どこの記事で言ったのか覚えていないのですが、ほとんどのユーザーは SN の壁にかき消されるノイズだらけの音を聞いたりしながら制作をしている、なんていう酷い皮肉を言っていた記事がどこかにあるのですが、実際そうなんですよ。ノイズまみれなんだけどノイズを知覚できていないって話。それの原因のほとんどが DPC Latency でしょうね。
みんなの決定的な誤解
ぶっちゃけて言えば、今まで語ってきた内容はこれから話すことの蛇足で以下が確信に迫る内容です。
これだけ頭に入れて今日は一度記事を読むのを辞めてもいいかもしれない。
それでは行くぞ。
DAW と Buffer Size は実は全く関係性がない
は？
そうだ、関係はない。なぜそう言い切れるか、は読んでくれ。
もちろん「DAW 独自の機能として Buffer Size の設定ができるという話じゃない」って意味も含み、システム全体を包括的に見ると DAW のリアルタイム再生能力と Buffer Size には関係性があるって話をごちゃ混ぜにしてはいけない。
Buffer Size というものは DAW の機能じゃない
もうこの辺も解説するのが蛇足すぎるかもしれないので、オーディオドライバについては以下の解説記事を読んでください。
なんだろ、全て過去記事に書いてあるって、有能すぎひんｗ？
Windows の場合、ASIO というものはコンピュータの複雑な問題を回避するために DAW とオーディオインターフェイスを直接繋ぐ役割をするものです。だからオーディオドライバ関連も DAW の機能だとちょっと錯覚するけど、Buffer Size っていうものは DAW の機能じゃなくて、オーディオドライバの機能 なんだ。
もう一度念押しして言うよ。「Buffer Size の設定というのは DAW 自体の機能じゃない」
バッファサイズは DAW のパフォーマンスとは関係ない
これについては Reaper の開発に関わっている人とか、ネットワークオーディオとか AD/DA 関連の知識人に掘って聞いたので反論がある人は別途なんかアクションください。
結局 DAW がバッファサイズ時間内に処理できるかできないか、というのは CPU のパフォーマンスメーターから見ても、DAW は処理できるけど、割り込み処理の関係上、バッファサイズ時間に間に合わない、って言う状況が続いていることがほとんど、というかほぼ間違いないということが状況証拠から言えるでしょう。
つまり、DAW だけのパフォーマンスは正直あまり関係がない、もちろん、すこし範囲を広げるとサードパーティ製品、主にプラグインやオーディオドライバの処理構造に準ずるけど。もちろん DAW 処理におけるリアルタイム CPU 処理能力とアベレージの CPU 処理能力の限界値がリンクしているような状況ではなおさら。
しかし、そのような状況は頻繁には起きることはない。って有識者たちの意見でした。何度も言うようだけど DAW のパフォーマンス性能と実際の CPU パフォーマンスがどちらも 100% になるような状況は稀である、ということ言っています。
もう少し厳密な議論
「CPU負荷が高くなりすぎると、DAWは (確率的に) 時間が足りなくなり、全チャンネルの全プラグインの処理を終えることを諦めて、次のバッファに移ってしまう。」
という主張。
これは「DAW が」というより、「システム全体の待ち時間が足らず、Buffer が埋まらず、次のバッファチャンクに移行する」という意味では間違いない。
ただし、CPU が高負荷の状態であって DAW 独自の基準で次の Buffer に強制移行する、という意味のでは、あり得ない。
これは DAW が処理を全部バイパスするとかそういう話ではなく、Buffer が足りないから次のチャンクへ処理の途中でも計算を辞めて次の Buffer のために計算を継続するの意味で、DAW 全体がこのような状況に陥るのは稀であるようだ。なんども言うようだけど、通常の問題は DAW 以外の待ち時間の影響のほうが大きいということ。
ここで重要なのはやはりリアルタイム CPU 性能と通常の CPU 性能の話をしなくてはいけない。
でもやっぱり CPU 性能必要じゃん
結局、DAW というかサードパーティプラグインというものは一つの CPU Core しか通常通過できない処理なので RT CPU、つまり全体の CPU 消費より、単体 CPU 処理が 100% になると、サードパーティプラグインの処理が Buffer Size をオーバーしてアーティファクトが発生する模様。
まーシングル性能云々は今はもう CPU 性能がリアルタイムの処理性能に関係あるじゃんって話だわな。
念押ししていうけど、これはプラグインや処理分散の話であって 基礎的な DAW の構造の話じゃないからね。DAW は CPU 性能と直接的には関係がない、でもやっぱり DAW を取り巻く環境のなかで関節的には結構影響はあるよねってこと。
Reaper は分散処理が得意ではあるけど、トラックごとの分散という意味で得意で、プラグイン側がシングルコア性能を求める場合は、DAW 側は何も対処できない。みんなすぐ DAW のせいにしたがるけど、ほとんどの問題は サードパーティ側にある って話、前にもしたよね？
合わせて読みたい
今回のまとめ
DAW が云々ではない、リアルタイム再生とレンダリング、バウンス (CPU パフォーマンス) で音が違うのは、処理構造が違うのだから当たりまえ。これは DAW の問題が主ではなく、要求頻度の高い Buffering が必要な構造のせい、割り込み処理が必要な構造上の話、ちゃんと理解して分けて考えること。
どちらかというとリアルタイム再生のほうが正確なデータ視聴ではない可能性が高い。だからバウンスで音が違うが、認識できる。つまりバウンスのほうがレンダリング精度は間違いなく、高い。
もちろん、レンダリング精度が高いことと「主観的ないい音」の関係性はまったくない。そして Reaper さんにはレンダリング精度についてのオプションがあることはこの記事の中で理解できたよね…？
DAW の計算結果と Buffering は基本的には関係がない。つまり、非リアルタイム処理時の DAW が出力している信号は (サードパーティによる例外あれど) 基本的には変化しないが、リアルタイム時の DAW 処理以降に出力される Buffer に関連する工程で音が変わる可能性があるので、リアルタイム再生の音を担保したい場合は、実時間の AD/DA をするほか無い。しかし、これもデータの担保という意味では全然厳密じゃない、割り込みの関係で毎回異なる出力がされる可能性もあり、もちろん內部バスで書き出しても基本無意味。
DAW は通常、処理を「バイパス」して次のバッファに移行するのではなく、システム全体の Buffer 自体が足りないために処理が途中でも次のバッファに移行するだけで処理が「バイパス」されているわけではない。
もちろん CPU 負荷が高いときに DAW が勝手に演算を辞めたり間引いていることは絶対にない。CPU の割り込み処理によって、演算を途中で放棄せざる負えないだけ。DAW の機能で演算を間引いたり、演算を管理するようなものは、存在しない。
「DAW の計算がー」とか、僕は元ツイート自体は DM で質問が来ただけで実はちゃんと読んでないのだが、DAW は実はリアルタイムプレイバック (再生) の性能には基本関係がなく、重要なのはドライバーの Buffer Size やシステム全体の割り込み処理の応答性能である。もちろん DAW が勝手に出力結果を改ざんしたりしないし、書き出し方で結果が変わるのは DAW のせいじゃないので正しい情報はこちらの記事で補完してください。
でも結局、リアルタイムの処理限界性能はシングルスレッド性能が世界を牛耳っていると思う。
こんなところでしょうか。
以上。頑張ってこの記事を書いたので以下の Paypal リンクから寄付待ってます。
