iOS音楽アプリプロデューサーがM1 Macを使ってみたら

最安M1 Mac mini、まだApple Silicon最適化されていないPro Toolsの性能に脱帽（2/2 ページ）

公開 2020年12月16日 14時29分

更新 2020年12月16日 02時27分

著者

山崎潤一郎

[ITmedia]

印刷する連載新着通知を受け取る

M1 Macのコスパ恐るべし

　ノートラブルは、もちろん喜ばしいことではあるが、M1 Macの検証原稿を書く身としては、ドラマがないと文章が盛り上がらない。何らかのトラブルを気持ちのどこかで待ち望んでいたことを今ここに告白しよう。まあ、それだけ、Rosetta 2が優秀ということの証左なのかもしれない。

M1 Macで192KHz/24bit録音の24トラックのプロジェクトを起動し、普段の作業をシミュレートしながら、一通りのプロセスを実施

　ただし、1つ変化があった。それまで、かすかなファンの音とともに、背面の排気口から常温の微風を排出していたMac miniだが、排出風の温度が微妙に上昇していることに気がついた。さすがのM1 Macも、8GBメモリで192KHz／24bitの24トラックプロジェクトをRosetta 2で駆動するのは、それなりに負荷がかかるのであろうか。とはいえ、排気風は少しだけ暖かいかな？　と思える程度に過ぎず、本体表面の体感温度は、何も変化していない。

　考えてみれば、Pro Toolsの推奨メモリは32GB以上だ。こちらは、Intel Macを想定した動作条件なので、一概には比較できないのだが、それにしても8GBメモリで同等かそれ以上のパフォーマンスを発揮するわけだから、M1 Macのコスパ恐るべしといったところだ。

恐るべしApple Siliconの実力　静音性は音楽制作にピッタリ

　このままでは、面白くない（？）ので、意図的に負荷をかけてみることにした。「Fabfilter Pro-R」というサードパーティー製のリバーブプラグインを、各トラックに個別に差し込んでみた。普通はこのような使い方はしない。リバーブやディレイ系のプラグインは、複雑な演算処理をしている場合が多いので、CPUの負荷も高くなるとにらんだからだ。

　まずは、Intel Macから、いじめてみよう（？）と思い、32GBメモリを搭載したIntel MacBook Pro 2020でPro Toolsを起動し、再生しながら、24あるトラックの端から順番に、Fabfilter Pro-Rを追加していった。すると、10トラックを超えたあたりから、ファンが大きな音をたて始め、17トラック目で、とうとう図のようなCPUエラーが出て再生が止まってしまった。このときのバッファサイズは、最大の「2048サンプル」にしてあった。

各トラックに順次リバーブプラグインを追加していくと、17個めでCPUエラーが発生し再生が止まった

　それならばと、3個のトラックからプラグインを外し、再度プレイバックを始めると、一応は動作するものの、ファンがけたたましい騒音を上げて高速回転を始めた。野獣の咆哮を連想するその狂気のごとき回転の様は、どうにも心臓によろしくない。壊れるのではないかという恐怖心を覚え1分ほどで再生を止めてしまった。するとファンもゆっくりと回転を下げるものの、本体下部は、かなりの熱を持っている。音楽の制作現場でこんなにノイジーなマシンは使い物にならない。このときのアクティビティモニタのCPUの状態が次の図だ。

Intel MacBook Pro 2020の14のトラックに個別にリバーブプラグインを刺して再生中のCPUの負荷。アイドル状態が約19％と高負荷状態

　お次は、M1 Mac miniで、14トラックにリバーブプラグインを刺した同じプロジェクトを起動し再生した。約5分の曲をループ状態にして5回は再生しただろうか。それでも、Mac miniは静かなものだ。排気口からは、かすかなファンの音とともに、微風がそよぐだけ。ファンの音といっても、本当に小さく本体に顔を近づけ耳をすまさないと聞こえない。Mac mini本体近くに設置してある、FOSTEXのニアフィールドモニター（スピーカー）の内蔵アンプが発するヒスノイズの方が大きいくらいだ。このときのバッファサイズは、最小の「128サンプル」だ！

　恐るべしApple Siliconの実力。ただ、この事例の場合、Fabfilter Pro-Rに関しては、M1 Macに対応しているようだ。「Intel or Apple Silicon processor」とサイトの互換情報のところに明記されている。この様にホストのDAWが非対応で、プラグインが対応済みという場合は、arm64命令あるいは、 x86_64命令、どちらのコードで実行されているのだろうか。

　文末で紹介しているAppleの開発者向けサイト「About the Rosetta Translation Environment」の内容から推測すると、Rosetta 2の翻訳時に、2種類のコードが混在することは避けるべきとあるので、この事例の場合は、Fabfilter Pro-Rもx86_64命令で実行されていると推測される。もし、これらが全て、Universal対応になった場合の底力を想像し、拳を突き上げて「あっぷるしりこん、ありがとー」と叫びたくなった。叫んではないけど...。このときのアクティビティモニターのCPUの状態は下図。

Intel MacBook Pro 2020と比較してCPUの負荷がかなり小さい。これだけの高負荷再生を実施してアイドル状態が51％であれば十分か

Apple Silicon 対応・非対応のプラグインが混在した場合はどうなる？

　ここで1つ疑問。この先、サードパーティーのプラグインが順次M1 Macに対応してくることが考えられる。そうなると、例えば、Pro Toolsや付属のプラグインは非対応のままなのに、サードパーティーのプラグインだけが対応している、といったケースも考えられる。前述したFabfilter Pro-Rのような混在事例だ。今回の検証時には、トラブルはなかったが、いかなる場面でも、プロジェクト全体として、終始安定的に動作するのだろうか。

　仮に、DAW本体がUniversal対応であれば、「情報を見る」の「Rosettaを使用して開く」をチェックすることで、DAW本体はもちろんプラグインも全てRosetta経由で動作するようにユーザー側でコントロールできる。Appleの開発者向けサイト「About the Rosetta Translation Environment」に、次のように明記されている。

バイナリにarm64命令とx86_64命令の両方が含まれている場合、アプリの『情報を見る』からRosettaを使用してアプリを起動するようにシステムに指示することができる。例えば、ユーザーはRosetta翻訳を有効にして、arm64アーキテクチャをまだサポートしていない古いプラグインをアプリで実行できるようにすることができる