お馬鹿な実験の果てに：

PCオーディオ周りで自分なりに音質に影響を与える要因について 多少の仮説 を立ててその実証実験を続けている。これもまた果て無き禅問答のようで正直正解にはまだ至っていないと感じるし、そもそも「解」のあることなのかも判然とはしない。注意しなければならないのは、自分で実験している環境が判ってしまっているので、何らかの先入観、思い込みによってバイアスがかかってしまっている可能性（危険性）もあるということ。

だが自分なりに見えてきたかも？　という点もあるので取り急ぎ纏めておきたい。仮説や実験内容は前回を参照していただくとして、今回はAoE Symphnic-MPDの環境前提となるが、大まかに確認できた点は以下の通り。結果は相対比較的なものとしたが絶対値で表すことはやはり困難、、、
（相対関係の比較については　>　>>　>>>　で一応自分なりの重み付けをしてみた）

１．ライブラリ音源の所在
　フロントエンドに内蔵　>>　サーバーPC（NAS相当）に置く

２．フロントエンドのハードウエア的要素
　CPU速度高　>　CPU速度低

３．LANの速度や構成
　ハブ無し（直結）　>>　ハブ有り

４．電源系の対策効果
　バックエンド　>>>　フロントエンド

１．の音源の所在に関しては今までそれ程意識はしておらず、サーバーPC（NAS相当）に置くことをある種「当然のこと」としてきたのだが、これは今回の実験で改めて認識した収穫であると思う。ただし、これはSymphonic-MPDの機能的特徴でもあるAudio over Ethernetとの関りもあって３．のネットワーク的要素も多分に入り込んで互いに関連している結果ではないか、と考えている。

ライブラリ音源のアクセスについては、サーバーPC（あるいはNAS）経由よりもフロントエンド直下に置く（内蔵SATAあるいはe-SATA、USB3.0接続など）方が遥かに高速であることに起因するものなのか、それともネットワークトラフィックへのインパクトが要因だろうか。単純には因果関係を説明し難いのだが、逆にNAS機能の持つ本来の利便性は多少失われることにもなるので、その得失で考えねばならないだろう。

２．CPU速度は定速の1.6GHzと2.4GHz（これでもかなりクロックダウンしている）の二通りで試したが、サーバーPCの場合は差を検知できなかった。フロントエンドについてもサーバーPCに音源を置いた状態で高速化しただけではかなり微妙なのだが、音源を直下に置く（内蔵SSD）ようにすると変化が見えてくる、という相乗効果がここにもある。

３．LANの低速化（100MHz）はサーバーPCの音源かつバックエンドをハブ経由接続とすることによる負荷の影響（フロントエンドでの音源読み出しとバックエンドへの送り出しという逆方向の伝送トラフィックがハブを通過するから？）なのかインパクトを受けるように感じるが、これも単独では意識しにくい。バックエンドと直結した際に見通しが向上するということとも関連すると思うが、総合的な伝送能力という点を勘案するとここは1GHzの方がベターなのかも。（ただしこれは多分に介在するハブの能力、性能によるだろう。高価なオーディオ用ハブであれば異なる結果となるかもしれないが、、、）なお、ハブ無し直結という構成は今回好結果であったが、フロントエンドとバックエンド間の処理（伝送タイミングや伝送データサイズなど）にも関連することなので、使用するソフトウエアによっては効果は異なるかもしれない。

総合的には１、２、３の構成で、内蔵音源、フロントエンドCPU速度アップ、バックエンドとハブ無し直結、という三要素で纏めた構成の時が一番しっくりとくる。これはそれぞれの相乗効果もあってより明確となるものと推測する。
（注記）ただし、ここでいう効果はAudio over Ethernetという仕組み、Symphonic-MPDのフロント、バックエンド間で少量データを高頻度にて送り込む、という伝送処理形態が大きく係わっている可能性が高い。

４．フロントエンド、サーバーPCを各種ノイズ対策済みのPCとそうでないものを入れ替えてみたが、サーバーPCでは全く差がわからない。フロントエンドでは気持ち、向上するかな～という感覚の程度。しかしバックエンド（ラズパイ４）の場合対策実施済みと未実施の比較ではそこそこ顕著。これは「オーディオ的後段処理」なのである程度変化の期待値はあるものなのだが、そもそもがS/PDIF出力なので対策として行っている高精度クロックに換装、クロック専用電源の注入、あたりの効果が大きいものと思う。

この観点からは、分散構成とする場合は「オーディオ的後段処理」側に注力して電源系ノイズ対策等を施すことがより効果的だということか。逆に言えばフロントエンド側は分散構成の場合その効果は比較すれば小さい。ただし、構成自体をシンプルにするという目的で一台構成とするケースも多いと思うのでその場合でも総合的な電源系ノイズ対策を実施した方がやはりベターと思う。なお、一体構成の場合（今回試していないが）でもCPUの高速度設定ならびに音源の内蔵化の効果はあるものと推測している。

さて、このような結果（多分に独断と偏見であることに留意）から仮説を評価するとどういうことになるだろうか。「仮説１」はフロントエンド側の構成や環境の変化はバックエンド側の音に影響を与えない、というものであったが、、、

ここは素直に懺悔するしかないだろう。バックエンド側が同一構成、環境であってもフロントエンド側およびネットワークを含めた全体構成が再生音に対して「影響を与え得る」という結果である。従って自分での評価としても「仮説１」は却下となる。

却下する場合、変動要因となる要素を見極め、それをリストアップして因果関係を明らかにせねばならないのだが、納得できるような明快な説明はやはり難しい。これをもって元の木阿弥、と断じることは容易いが、納得できる部分は少しでも積み上げてみたい。つまるところ先の「仮説３」の領域にもっと踏み込まなければならないと思う。だが、どうアプローチすれば良いのか、現状これを具体化するアイデアがあまり浮かんでこない、、、

これにて実験ならびに探求が終了した訳ではまだまだないが、今回の結果によって通常利用するSymphoic-MPDの構成を原理主義ということでなくてもせっかくの？成果を多少なりとも活かしたいので、これに沿って組み替えた。JPLAYの時代にはDual PC構成（で直結）はある種当然のように考えていたが、その時点でも音源はサーバーPCに置いていた（これはJPLAY自体がUPnPで音源を読み込みという仕様であるため）。その後JPLAYの構成を縮小する時に、敢えてDual PC構成を廃止したのだが、それ自体は結局望ましいことではなかった訳だ。AoE Symphonic-MPDではフロントエンド、バックエンドの分散構成は維持していたが、便宜上ハブ経由の接続とすることで安穏としてしまっていた。構成的にはハブ経由とする方がどうしてもネットワーク的な管理や障害対応の面で便利なのだが、これは改めて反省点となった。なお、ハブについてももう一段の研究が必須なことも確かなのだが、直結がベターとなれば敢えてトライする必然性はどうなんだろうか。ここは迷うところ。

フロントエンド直下に音源を置く、という方式に関しては現状は内蔵SSDとしているが、これは改めてe-SATAも試す必要があるだろうか。M2.SSDなども然り。ただし、M2.SSD（NVMe）は高速になればなるほど発熱が大きくなることのデメリットもあるのでファンレス構成との兼ね合いもあるか。外付けで電源を別供給するスタイルであればUSB3.0接続も良いかも、とも思う。この場合HDD（発熱と振動、騒音の課題はあり）でも良いかもしれない。この辺りはいずれも継続実験課題。

さて、自分のライブラリ音源を再生するAoE Symphonic-MPDの構成における実験と見直しはこれでまずは第一段階としても、じゃストリーミングはどうなる？　と考えると実は頭が痛い。ストリーミング用の機器はBluesound Nodeなので現状出来ていることは電源換装ぐらいでしかなく、もう一段高みを目指したいとは思うのだが。RoonでBluesound Nodeを出力デバイスにすることも可能だが、今まではハブ経由の構成しか経験がなく、その場合の音質変化は実感できていない。RoonはAmazon Music対応していないので実験のモチベーションが今一つ上がらない、ということも今まであったかも。

だが、RoonもCoreからアウトプットデバイスをLAN直結できるのでNodeでどうなるか試してみる価値はありそう。この場合、最早Bluesound Nodeを単独のストリーマとして使うことは不可能（iPADなどのリモコンソフトからNodeへのアクセス不可となるため）になってしまうので、この構成は今まで頭の片隅にもなかった。これ自体はストリーミング対応の構成として操作をRoonに一本化してしまう、ということを是とすれば意味があるのかもしれない。また、NodeはDHCPによるIPアドレス取得のみでスタティックIPアドレスのユーザー設定ができないので、果たして直結できるんだろうか、、、