JPLAYのPC的研究と考察（オーディオの話題と言うよりはJPLAYの仕組みに関する素人的考察）

１．発端（きっかけ）

JPLAYでAudio PCとして使用している ファンレスPC に関して、Linux系のVoyageMPDとして使う場合はほとんど発熱しないのであるが、JPLAYの場合はCPU使用率は5～7%程度であるにも係わらずかなり熱くなってしまうという事象があってこれに疑問を持ち、JPLAYはPC上のソフトウエアとして一体どんなことを行っているのか調べてみたくなった。また、DAC Link値の設定で音の感じが変わることについても、仕掛け、仕組み等についてはJPLAYの公式情報として一切開示されていないため、それがどの部分に係わるどういうソフトウエア的な処理に起因しているのか導入当初から非常に興味を持っていた。そこで何とかこれを紐解けないものかと考えてアプローチを試みた。

（いろいろと確認した結果をここに纏めてみたが、あくまでも当方における事象の確認による推量でもあるので、その内容が正確なものかどうかは保証の限りではないことをお断りしておく）

２．JPLAYのスロットルON/OFFと電源管理の関係

一般的なCPUは動作クロックを変えることによって、省電力化、低発熱化が行われている。この動作自体はハードウエア依存であるが、OSやBIOSからもある程度コントロールすることが可能であり、Windows環境では「電源オプション」の設定がこれに当たる。

電源オプション（のCPUに係わる設定で）で「バランス」とした場合は、CPUの使用状況に応じて、CPUクロックは最低値5%、最大値100%の範囲で可変となる。「高パフォーマンス」とした場合はデフォルトでは最低値、最大値とも常時100%となる。ただし、この数値自体はユーザーが任意に設定することも可能である。

（注記）電源のオプションにはこの他にディスプレーやHDDに係わる省電力設定などもあるが、これらとJPLAYの関係は未調査。

当然ながら、「高パフォーマンス」の設定をすると常時最大に近い（最大値ではない）クロックでCPUが駆動され、消費電力、発熱も増大する。JPLAYはこの設定に対して、JPLAY Setting画面のスロットルパラメータで「ON」を選択すると、この「高パフォーマンス」モードに移行する仕掛けになっている。最低値、最大値はデフォルトの100%の数値となる。従って、この設定でAudio PCを動作させた場合、実際のCPU使用率とは関係なく高クロック、消費電力大となり、我が家のAudio PCではかなり発熱してしまうということが結果的に起きる。

もちろん、定格に近いクロックで作動させることによる得失は考えられる。高クロックであればタイミング依存の処理がより正確に行われる、が一方で、従来からも云われていることでもあるが、CPUの高周波動作に伴う電源系ノイズの発生の増大にもなりうる。Audio PCに対するJPLAYの動作要求から考えると、CPUクロック自体を可変とするよりは、一定のCPUクロックにしておくことが（負荷変動の排除からも）望ましいようには考えられる。

そこで、スロットルは「ON」のまま、Windowsの電源オプションで最低値、最大値をいずれも70%とする設定でまずテストしてみた。タスクマネージャでこのクロックの動作状況を確認することができる。100%でも70%でもクロック周波数自体は一定ではなく僅かに変動しているようではあるが、概ね設定値に沿った動作状況となる。当然ながら、70%設定ではCPU使用率は多少上昇する（と云っても10%未満であることには変わりない）が、大きな負荷という程の状況にはならない。

（注記）タスクマネージャで状況を参照する必要があるため、Audio PCはCoreモードではなくGUIモード、Hybernate OFFで稼動させている。

数値自体を50%から80%の範囲で変えてテストしてみたが、それに応じてクロック周波数および発熱状態は変わる。ただし、ここでの設定値の変更による「音の差」は当方にはほぼ感知できない。音への安心材料としては常に最大100%がベターなのかもしれないが、当方としては、使用しているPCがファンレスであるが故に無駄な電力消費と発熱の問題は無視できず、70%という設定値であれば発熱も人肌程度であるため、Audio PCは当面この設定とすることにした。（Contorol PCは更にCPU使用率が少ないので、60％とした）

逆に考えると、JPLAYのスロットルONの設定だけでは無駄に高クロックで動作させていると云えなくもないので、それぞれのCPUの性能に合わせて、この設定数値を決定しても良いのではないかと思う。設定を変えること自体は以下の画面のように至って簡単である。

電電オプション、プロセッサの電源管理（Control PC側）：


（注記）タスクマネージャから得られる情報として「メモリーの使用量」もあるが、これは総じて小さい。元々Windows Server自体はコンパクトであるので、Audio PC、Control PCのいずれであっても4GB程度のメモリがあれば必要にして充分な量と思われる。なお、搭載メモリの総量が音へのインパクトして現れるのかどうかはテストしていない。

Audio PCの再生中のCPU状況（GUIモード、Hybernate OFF）：


Audio PCの再生中のメモリー状況（GUIモード、Hybernate OFF）：


３．JPLAY DAC Link数値とControl PC、Audio PC間の伝送状況の関係　（Dual PC構成前提）

JPLAYは「タイミングパーフェクト」という思想で、「遅延の排除により音の向上を図る」としているのだが、このDAC Link値がどのような処理に関与しているのか明確には説明していない。上述した電源オプションに係わる部分からの推測では単なる負荷の低減のみならず、「負荷の平準化」という視点もあるように感じられたのだが、これは推測で定かではない。だが、上記に掲載したAudio PCにおける再生中のCPU（ならびにメモリー）の使用状況を見れば一目瞭然、ほとんど変動していないことが分かる。

さて、Dual PC構成において、Control PC、Audio PC間は単に音楽データを送っているだけであることは間違いないのだが、DAC Link値によって何からの差異があるのだろうか。この点を調べるためには、両PC間の伝送内容とタイミングを解析すれば良いのだが、当方のような素人ではそのような解析ツールは持っていないし、簡単には使いこなせないであろう。そこで、もっとも単純な方法であるが、これもタスクマネージャのネットワークの使用状況から追ってみることとした。

タスクマネージャによって示されるネットワークの状況は「トラフィック量」が時間推移とともに示されるのであるが、結果としてかなり興味深いものが得られた。DAC Link値を350Hz 、10Hz 、１Hzと変化させて音楽再生を行い、その時のそれぞれのネットワークトラフィック状況を以下に示す。

（１）350Hz
ネットワーク上の送信トラフィックの変動はきわめて小さく、タスクマネージャで表示される時間軸上は一定（ほぼ直線）となる。特徴的なのは受信トラフィックが他のケースに比較してかなり多くなること。

DACLink 350Hzにおけるトラフィック状況（Contorol PC側）：


（２）10Hz
ネットワーク上の送信トラフィックに微細な山谷が発生する。（が一般論としてはこれでもある程度平準化されていると考えられる）

DACLink 10Hzにおけるトラフィック状況（Contorol PC側）：


（３）１Hz
一定間隔（数秒単位）でトラフィックのピーク（山）ができる。推測としては、このピークのタイミングで大きなデータを送信しているものと思われる。

DACLink 1Hzにおけるトラフィック状況（Contorol PC側）：


それぞれのケースでも送信における時間単位のトラフィック量そのものは変動していない（当然かも）。一方で、350Hzの場合は受信トラフィックがかなり大きくなっていること。この表示内容やデータ量の結果から大胆な推測を含めて云えば、両PC間での伝送パケットサイズがDAC Link値に応じて変化している。より小さなパケットサイズで高頻度に送ることにより、ネットワークトラフィック自体がここでも平準化されていると云えるであろう。ネットワークトラフィックが均一になっているということは、Audio PCにおける処理負荷もまた平準化されることに繋がる。

なお、より大きなDAC Link値にした場合に受信トラフィックが増える理由は、Audio PCからの「応答」の頻度が増えていることに起因しているものと思う（小さなパケットを高頻度で受信するため、応答回数が必然的に増える）がこれは推測の範囲を出ない。

４．PCバッファー数値

JPLAYの音の要素の設定値としてPCバッファーというものがあり、0.01秒から5秒程度までの範囲が設定できる。これは一体どこに関与しているものなのであろうか。一般論で考え、推測するには、ひとつにはControl PC、Audio PC間における伝送バッファーの大きさを決める数値。前述したパケットサイズと混同してはいけないのだが、こちらは音楽再生に使用するバッファーの「容量」である。仮に1secという設定であれば、1秒分のバッファーが（おそらく）用意されることになる。そして、このバッファーに1秒分の音楽データが満たされた（受信された時に）送信元に応答を返し、デバイスドライバーに対してデータの送り出しを開始する。

なお、このような伝送処理と音楽再生処理の連携においては、通常は最低でも二つのバッファーが用意され、伝送処理（受信処理）と音楽再生処理のバッファーを交互に切り替えて使用する。仮にバッファーAとバッファーBとすれば、Aが受信完了した時点で、このAを用いて音楽再生を開始し、もうひとつのBで受信を継続する。Aのバッファー内容の再生が終了したタイミングでバッファーを切り替えて、今度はBで音楽再生を開始、Aで受信を継続する。当然ながら、バッファーAの内容の再生が完了するまでに、次のバッファーBの受信は完了していなくてはならない。もし、終了していなければ、「バッファーアンダーラン」という状況が発生し、音楽再生は（通常はであるが）中断してしまう。一般論的にはこのバッファーサイズが大きければ、何らかの理由によりネットワーク上の負荷変動があってもこのような事態は起こりにくくなる。（小さな数値ではこの発生リスクが増大し、大きい数値では再生が安定する、ということに繋がる）

逆の事象として、Aで再生中にBの受信が完了したからといって、Aに受信を再開してしまうと、「バッファーオーバーラン（上書き）」という状況が発生してしまうので、Aの再生が完了するまでは、次のデータをAに書き込むことはできない。Aでの再生が完了した時点で「応答」を返し、再度Aに受信が可能となることを送信側に知らせる必要がある。このような処理の同期を制御することは通常のソフトウエア処理では不可欠なのでであるが、処理が複雑化し面倒でもあるので、一般的なソフトウエアの場合はOSにこのような処理を任せてしまうことが多いのであるが、この辺りの同期処理をOS任せにしないでJPLAY自らが行っているようにも考えられる。（JPLAYの内部ロジックの詳細はもちろん不明なので、ここも全くの推測である）

従って、この推測が正しければであるが、より小さなPCバッファー値の指定によって、頻繁にバッファー切り替えと応答（受信トラフィックが多くなることはここに起因する）が行われ、結果として処理負荷の平準化に寄与することになる。一方でちょっとしたネットワーク上の遅れが発生すると、前述したバッファーアンダーランが起き再生が停止するという事も起こってしまうことになる。（JPLAYではよく起こる現象でもある）

さてここで、DAC Link値やPCバッファー値とは、このような両PC間のトラフィックならびにPCの負荷変動の平準化という目的だけのものなのであろうか。USB DDC/DACのデバイスドライバーならびにハードウエアとの連携にも関与しているのであろうか。何となく、連携がありそうな気もするのであるが、残念ながら、この部分を捕捉できるような方法は当方では考え付かなかった。ただし、Latencyやバッファーサイズを指定できるようなデバイスドライバーの場合（Thesycon社のXMOSドライバーが代表的であるが）、JPLAYのControl PC、Audio PC間で行われているような制御がAudio PC内部のJPLAY Service、デバイスドライバー間にも適用されていると思う。結果として、デバイスドライバーのLatencyをミニマムに、バッファーサイズを最小にすると、DAC Link値はより大きいものを使用できるようになることになるので、そのように考えている。

Thesycon社のデバイスドライバー設定画面：


５．総括

JPLAYがOSとしてWindows Severを推奨していることも、OSを含めてPC全体に余分なことをさせない、という考えをベースにしているものであり、この「負荷そのものの低減」と「処理負荷の平準化」ということがJPLAYの基本理念である「タイミングパーフェクト」をPC上に於いて実現する具体的な方法論だと思われる。これらはまた、WindowsやMacOS、Linux（一部を除く）がリアルタイム処理に不向きなOS構造である、ということにも遠因があるのかもしれない。

ただし、これで音が変わる、良くなる、ということの根拠や因果関係の証明にはなっていない。PC上の変動要素をなるべく排し影響を小さくして、音楽データを受け渡そうとしているのみである。

最終的に音に大きく関与しているのは、それがXMOSであるか、FPGAなどであるか問わず、USBインターフェース部とその先にあるDDCチップであり、また、USBそのものの経路においても数々の信号劣化やノイズという難関が待ち受けている。さらに、S/PDIFあるいはI2Sを介した先のDAC部分にも大きく依存することになる。こうして復元されたアナログ信号の「質」そのものとここからの「伝送」や「増幅」、更には電気信号からの「音波への変換」などにおいて、また極めて多様な要素が絡んでくる訳だが、これらはオーディオにおける「音を良くする工夫」の醍醐味であることは間違いない。PCベースのデジタルトランスポートという範疇も、オーディオにおける音を左右するひとつの重要な要素機器として既に認知されたと思うし、PCのハードウエアの領域はもとより、OSを含むソフトウエア領域（注記）もまた重要であるという点において異論はないと思う。

（注記）ここでは楽曲のデータベース的な管理機能やGUIによる操作性やその出来というアプリケーション的な部分ではなく、サウンドデバイスを「正確に駆動」するという観点で述べている。JPLAYの推奨するKernel Streamingの他にASIOやWASAPIなどの方式もあるので、そこでの音の違いをどう可視化できるのか、方法論を考えてみてはいるのだが、、、

しかしながら、PCベースのデジタルトランスポートという概念において、どのような要素が音に対して支配的になるのか、その比重はPCパーツなどのハードウエア領域が大きいのか、はたまたソフトウエア領域なのか、電気的な 各種ノイズ対策 なのかを含めて、その因果関係について実のところは当方はまだ良く判ってはいない。一方で、単にOSの機能にのみ依存しているだけでは、音楽再生ソフトウエアはオーディオ的な音の改善は為し得ないこともまた事実だと思う。むしろOSの機能を「削ぎ落とす」という方向性が重要なのかもしれないし、これも従来からいろいろと行われてきたことでもある。しかし、LinuxベースのコンパクトなOSと一体化しこの軽量化の方向で進化してきたVoyageMPDに比しても、JPLAYのアドバンテージは認められるという不思議さもある。ここでの違いは何か。「負荷の平準化」という観点からの徹底度の違いくらいしか思いつかないのだ。

ひとつひとつの要素自体は改めて気付かされた事実であるということでは決してなく、今までもPC上の音へのインパクトがある事項と考えてきたことでもある。前述したこれらの個々の内容や結果は興味深くはあるものの、結局のところまだまだ自分でもPCオーディオならびにJPLAYにおける「音の秘密」について納得できるような境地に至ってはいない。