abk1's scratched blog 3::AUDIO DIARY

まず、前のエントリーから引用する。

• 1）NAS音源 > 2570p > apu2
• 2）NAS音源 > Daphile > 2570p > apu2
• 3）Deezer > Daphile > 2570p > apu2
• 4）NAS音源 > 820G2 > apu2
• 5）NAS音源 > Daphile > 820G2 > apu2
• 6）Deezer > Daphile > 820G2 > apu2

3）＜ 2）≦ 1、5、6）＜ 4）、こんな感じ。

引用内容から導かれる仮設。

1. 2570pよりも、820G2のほうが音が良い
2. mpd/upnpサーバーを、LANの経路上、PPAP Back-Endから離した方が音が良い
3. upnp(upmpdcli)を使うより、使わないデータ伝送の方が音が良い

さて、その後どうだったか。

まず、Back-Endの近くにあった2570pを、820Gの傍に移動して音を比較。
結果、両機種の音に僅かな差異はあるような気がするものの、音質は同等と結論した。

こうした過程で、移動した2570pの音が改善したことが分かった。
一つ目の仮説は否定され、二つ目の仮説は正しいと思われることが分かった。

さて三つ目の仮説は、一つ目の仮説が反証され二つ目の仮説が実証される過程で再検証された、といっていいのかな？
どうもやはり、upnp/upmpdcliを経由するよりも、NASやCDから直接（と言っていいのか？）、mpdの入力プラグインに音声データを入力する方が音が良い。

PPAPでは、mpdサーバーから、DACに信号を送る機能を分離している。
DACに信号を送る機能はPPAP Back-Endが受け持っているが、Front以前の状況によって音が変るということは、遠く家庭内LAN経由で複数のハブを介して離れていても、Frontの負担がBack-Endに影響しているということだ。

僕としては、upnp経由の音（Deezer hifi / Daphileの音源）を、mpd単体の音と同等にしたい。
upmpdcliといえば、過去にはpolipoを組み合わせて高音質化する手法を見たことがあった。
polipoは「キャッシュウェブプロキシ」というもので、キャッシュや負荷を制御することでmpdの負担を減らす、ということだった？と思う。
当時、よく分からず、今もよく分かっていない。
簡単にできたというネット上の書き込みもあるのだけど、よく分からないのでこの手法は使いにくい。

そこで思い付いたのは、PPAP Back-Endを2連直列、タンデム化するというアイデアだ。もともとPPAP自体がタンデムシステムなので、Back-Endがタンデムということは三人乗りになるわけだけど。
前回、ノイズ源を減らすとか言いながら、また増やしている。
下図のような感じに。
出来るだろうか。

最初は、Back-End化したraspberry pi B+ / piCore7で試した。
設定ファイル「bootlocal.sh」には、「/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=1024 --buffer-size=16384 -t raw -f S32_LE -r768000 -c2"」というようなコマンドが書き込まれていて、OS起動時に読み込み実行され、PPAP Back-Endとして機能する。
これを下記のように書き換える。

sudo vi /opt/bootlocal.sh

/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/ncat 192.168.1.89 4400"

filetool.sh -b
sudo reboot

こんな感じに、中継機として設定してみる。
コマンドの記述は思い付きである。
ちょっと思い付きというのは乱暴なので書き直し。Frontのmpd.confのpipe出力に記載している内容を参考に、というか、そのまま引用して書き加えている。 要は、ncatで受けてaplayに送ってDACに出力していたのを、ncatで受けて再度ncatから送り出すようにした。上の例だと、ipアドレス「192.168.1.89」のPPAP Back-End、つまり2台目のBack-Endにデータを送るということだ。

PPAP Frontのほうも、中継機のipアドレスにデータを送るようにmpd.confを書き換え、mpdを再起動。
これで動かしてみたら、、、普通に音が出た。我ながらびっくりした。

さて、44.1/16のデータ転送では音が出たが、Ras pi B+ではスペックが足りない。192kHzでは使えなかった。音が途切れるしクライアントの操作から出音が５～６秒以上遅れる。
そこで、前回エントリー時にシステムから外して余っていたapu2c4を復帰させた。もともとBack-Endとして動かしていた機体なので、再設定も簡単。
ハードのスペックが上がったら、前述のような問題は全くなくなった。768kHzでもストレス無く使える。

音はどうか。
結論から言えば、目論見どおり、upnp経由のDeezer hifi / Daphileの音を改善できた。
S/N、階調が深まり、弦楽器の倍音、余韻が細やかに減衰する。パーカッションの基音が聴き取りやすい。環境音の鳥の声や、録音時に紛れ込んだノイズのリアリティがアップする。一皮剥けて見通しが良くなった。
mpd単体の音と比較して差異が全くなくなったとは言えない感じだけど、かなり差が縮まった。ブラインドで区別する自信はない。

mpd単体再生で、Back-Endが１台のときと2台のとき、変化はどうなのかということになると、かなり難しい。差異を聴き取れない。

しかし、こんなところに改善を目指せる余地が残っていたということに驚いた。
やってみるものである。
あとは、追加したBack-Endを何処に設置するのがいいかの検討が残っている。追々やる。

今日からパラリンピックが始まる。まったく世界はカオスだ。感染回避を心掛けるのみならず、可能な限り身辺安全を確保し、病院のお世話になるような怪我や体調悪化を、ひたすら回避する。命に関るようなことがあっても、現状、病院が守ってくれる余力は限られているのだから。
諸兄も頑張ってください。ご自愛を。

世の中はオリンピックで盛り上がっている。
何よりも大過なく終わっていただくこと（中止含む）を祈るばかりだが、非常に危うい。
パラリンピックはやるんだろうか。
コロナ禍は各自で身を守るしかないのだろう。医療崩壊のリスクが高い今、感染回避を心掛けるのみならず、可能な限り身辺安全を確保し病院のお世話になるような怪我や体調悪化を回避する必要がある。頑張ろう。

以前に「mpdでCD再生に対応する」というエントリーを挙げたことがある。
テスト用システムのhp Elitebook 820G2で設定したままになっていて、時々、CDを鳴らすのに使っていた。
820G2につないだUSB-DVDドライブでCDのデータを読み込み、768kHzにアップサンプリングする。PPAPフロント機能でLAN経由でメインシステムのPPAPバックエンドにデータを送る。これで、メインシステムでCDを聴くことが出来る。

そうこうするうちに、気付いたことがある。

昔、オーディオ用のLANネットワークを100Base-Tで組んでいた頃、700kHz台にアップサンプリングしたデータと768kHzのハイレゾファイルのデータを転送出来なかった経験がある。
当時はFX-08miniを使っていた。FX-08miniは音がいいスマートハブだけど通信速度は100Base-Tだ。768/32では音が途切れて使えなくなったので、ハブを替えて、768/32のデータが通る回線は1000Base-Tでつないで、以降は問題なく音声再生できるようになった。
そうした経験から、768kHzのPCMデータを100Base-Tで転送することは出来ないと思っていた。

しかし現在、テスト系の820G2とPPAPバックエンド（apu2）の間には一部、FX-08miniを使っていて100Base-Tの区感がある。それにも関わらずデータの転送が出来ている。

現在のPCオーディオのLANネットワークを図にしてみた。
以前のアップした図にテストシステムの820G2も描き加えて整理している。820G2はメインシステムからはかなり離れたところ、Daphileサーバーとして運用しているCompaq 6730bの隣に置いてある。

さて、どういうことだろう、、、
バックエンド直前のハブが1000Base-Tである必要があるのか？と思って、試しにADI-2 DAC直前のFXG-05RPTを外してFX-08miniに替えてみたところ、問題なく音が出る。これは違う、、、
他に考えられることといえば、以前と変わっているのは普段使いのノートPCのスペックが上がっていること。Compaq 6730bから、Probook 450G3に替えている。オーディオシステムから遠く離れた場所につないだPCでも、負荷が大きくなると音に悪影響がある。しかし、それが原因で768/32が100Base-Tで通るようになるというのは、考え難いかな、どうだろう、、、

以前から感じていたんだけど、テストシステムで再生するCDの音が意外に良い気がする。DVDドライブでガンガンCDが回っているからノイズだらけなはずなのに、音は悪くない気がするのだ。

音がいいと感じるのは、テストシステムのアップサンプリングサーバー（820G2）がPPAPバックエンドから離れているからではないのか。加えてテストシステム、Daphileサーバーの電源と、PPAPバックエンドを含むメインシステムの電源は、分電盤上で分離されている。820G2のノイズはメインシステムに伝わりにくいかもしれない。

Daphileで聴いているときはどうなのか。
このときはDaphileから44.1/16のデータを、PPAPバックエンドのすぐ傍にあるPPAPフロント兼アップサンプリングサーバー（2570p）に送ってアップサンプリングしている。つまり、バックエンドにノイズの影響が及びやすい場所でアップサンプリングしていることになる。

テスト系とメインシステム系、どちらサーバーのほうが音がいいのか。そもそもサーバーに使っている機種が違うので単純に比較できない面もあるけど、比べてみた。
ブラインドでは、まず分からないと思う。
しかし繰り返し切り替えて比較したら、テスト系の方が僅かに音がいいのが分かる。雑味が少ないのだ。
これは僅差でも戻れない差異か、と思いながらテスト系を継続して使っていたら、普段の日常的用途に使っているノート（450G3）を操作したときに音が途切れることが時々あった。
テスト系と450G3は電源タップを共有している。
アップサンプリングサーバーをノイズが多い環境に置くのは望ましくないということか。
こういう場合、経験的には暫く使ううちに不具合が増えて上手くいかなくなっていくことが多いように思う。

そこで、メイン系アップサンプリングサーバー（2570p）をつなぐハブを変えてみた。
FX-08miniでつないでいる場所よりPPAPバックエンド側のGS105Eにつないでいたのを、手前のLSW4-GT-8NSのところに持ってきた。
これまでバックエンド側に置いていたのは768/32の信号は100Base-Tを越えられないと思っていたからで、伝送できて越えられると分かったからにはバックエンドの近くににつなぐ必然性はない、という判断だ。

音の違いは、テスト系を使った時より少ない。しかし極めて僅差だが、良いような気がする。
普段使いの450G3であれこれしていても、音は途切れない、かな？
と思っていたら、再生音が途切れるようになってきた。
Daphileを再起動したら一旦は落ち着いた。しかし以前には無かったことであり、結局は768/32で100Base-Tを通すのは難しいということになるのだろうか。100Base-Tで768/32を通すのは、送信側にも負担になるのだろうか。Daphileは44.1/16を送信しているだけなのだけど、受信側が上手く動いてなかったら送信側にも負担は生じるかもしれない。
それとも、他に原因が？、、、

取り敢えず、2570pをつなぐハブを変更前のGS105Eに戻して様子を見る、、また音が途切れる。
Deezer、休日は人気がある曲はつながりにくいのか？、、、
Daphileサーバーの6730bの温度を確認したら80℃以上と。
熱すぎる（Daphileはウェブブラウザインターフェイスからサーバー温度を確認できるのだ）。

一旦シャットダウン、本棚の下から引っ張り出す。
使っていない内蔵HDDが熱くなっている。これが原因ではないとは思うが取り敢えず外す。ついでにメモリも4x2GBだったのを1枚に減らす。風通しが良くなったら違うかもしれない。DVDドライブは使ってないのでbiosで止める。
置き方も変えてみる。底板が熱くなりやすいので上下を逆さまにセッティングしてみた。多少は冷えやすくなるんじゃないだろうか。
本来、加熱するから冷やすじゃなくて加熱しないように使うべきだと思うが、仕方ない。

家庭内LANの状況とか、Deezer側の状況？とか、なんだかいろんな要素が複合的に作用しているようだ。
その後、サーバーの温度が安定したので、再び2570pをLSW4につないで様子をみているけど、、、どうだろうな、、、

そんな感じであれこれやっていく中で、音の比較もしてきている。
うちではCDリッピング音源をNASに置いているんだけど、Deezerにも同等の音源がある場合、6通りの再生方法が考えられる。
以下の通り。

• 1）NAS音源 > 2570p > apu2
• 2）NAS音源 > Daphile > 2570p > apu2
• 3）Deezer > Daphile > 2570p > apu2
• 4）NAS音源 > 820G2 > apu2
• 5）NAS音源 > Daphile > 820G2 > apu2
• 6）Deezer > Daphile > 820G2 > apu2

比較したところ、3）は他と比べたら良くない。 1）5）6）は若干の音色の違いはあるようだが、ほぼ同等だと思う。
難しいのは2）で、差があるようで無いようで、明確に言いにくい。
一番いいのは、4）だ。 3）＜ 2）≦ 1、5、6）＜ 4）、こんな感じ。
テスト系で鳴らしたCDの音が良いと感じたのは、順当だったということらしい。

サーバーを何処に置くかよりも、サーバーに使っているハードの違いのほうが影響が大きい可能性もある。
今後、確認していきたい。

もう一点気になってきたことが。

以前は、PPAPバックエンドが2台あって、USB DACへの出力切り替えは使用するバックエンドをssh経由で切り替えることで変更するようになっていた。しかし、それが面倒な時には物理的にUSBケーブルの抜き差しで切り替えることがあった。それどころか、いつの間にか切り替えに便利なようにUSBケーブルに中継アダプターが入っている。

こんなことをして音質に影響があるかと思ったら、特に問題を感じない。
だったら、ケーブル抜き差しの切り替えでいいんじゃないか、と。
どうせ上流を切り替えたら下流もXLRケーブルやアンプセレクターなど切り替える必要があるので、手間としては大して変わらない。
そうなると、apu2を1台に出来る。ノイズ源を１つ減らすことが出来る。

現在、ADI-2 DACにつながっているapu2d4の前にはFXG-05RPTを入れている。過去の経験からは、ここに音の良いハブ1台をかませたほうがいい。所謂ハブのカスケード接続だ。
Pegasusにつながるapu2c4のほうは、これが入っていない。
前述の100Base-T伝送の関連で一時、FXG-05RPTをFX-08miniに戻してみたんだけど、ウォーミングアップが足りないせいかLANターミネーターを刺してなかったせいか理由は分からないが、音質が低下した。以前には散々聴き比べてFXG-05RPTにしたけど、今回は差が大きいと感じたのだ。

2台のapu2の条件を合わせようとするならFXG-05RPTをもう1台購入する必要がある。しかし今購入するなら以前の倍の価格で売っている。というか、前に買った時が安売りだったのだ。
apu2を1台にするなら追加購入を考える必要はなくなる。

そういうわけで、apu2を1台にした。
余ったapu2でDaphileを運用するというのも考えられるかと思う。

現状、そんな感じで細々したところを弄っているけど、取り組みは気まぐれな感じなので、セッティングが確定して落ち着くにはもうしばらく時間がかかりそうだ。

以前のエントリーで、pulseaudio経由の音声信号伝達について書いていた。
現在は、ras pi2とM500（USB-DAC）をつないでシステム化している。piCore7にalsaとpulseaudioだけ組み込んだ簡素なサーバーだ。
Youtubeなどの再生に使うんだけど、実はもうひとつ他に目的があって、MQA再生環境が必要な時にM500を使おうと考えていた。

今回、普段使いのノートPCでmpdを動かして、MQAデータをpulseaudio出力しpulseaudioサーバーに転送、M500で再生したところ、MQAを認識し再生した。
MQAはpulseaudio経由で転送することも可能なことが分かった。

大したことはしていない。
ノートPC（OSはFedora）の.mpdconfに下記のようにpulseaudio出力を設定、サーバーのipアドレスを設定し、mpdでMQAファイルを再生しただけだ。

audio_output {
        type            "pulse"
        name            "My Pulse Output"
##      server          "remote_server"         # optional
      server          "192.168.1.77"
##      sink            "remote_server_sink"    # optional
}

MQAの音は、綺麗だと思う。
うちではメインの音源は主にCD相当のデータをlibsamplerateでアップサンプリングして鳴らしていて、これはこれで高音質なんだけど、なんというか、MQAの音には無理がない軽やかさがある。スムーズで余裕があり歌心がある鳴り方をする。

MQA対応のハードというのは「オーダーメイドの服」みたいな理解を僕はしていて、つまり、MQA音源とハードウェアがあつらえた服のように合っている、というイメージだ。
従来のPCM再生はハードウェアがPCM音源に合わせないといけないが、限界があるというイメージ。
MQAはハードウェアの合わせ方が予め決まっていて、ハード側がそれに沿って合わせるように作られているので、PCMの限界を越えるというイメージ。
うちでやっているPCM768kHzへのアップサンプリングは音源をハードに合わせる努力であって、だから良質な仕立て（libsamplerate）が必要なんだけど、確かに音質改善があって楽音の情報量としても多いけど、何処かしら頑張ってる音という感触がある。これはハードのスペック向上によって改善するのかもしれないけど。
MQAの音は、そういう野暮ったさがない。スマートな音がする。

今回はpulseaudioで転送したけど、一般的なUPnPでも転送は可能だと思う。そもそも、UPnPで転送してMQAだと読めなくなるようなら、使いものになってない筈だ。
うちではUPnPで転送するなら、転送先にmpd、upmpdcliをインストールしないといけない。他にUPnPレンダラーの作り方を知らないからだ。
そうそうMQAは使わないし、当面は現在のシステムでいいと思っているけど。

タイトルの「切り替えケーブル」って何？という感じだけど。

5月頃からDACとアンプの接続を切り替えるのに、コネクターパネルをオーディオラックに設えて、ケーブルをつなぎ替えることで対応している。
セレクターも考えたけど、既製品で良さそうなのだと、どうやっても7万円以上かかることになってくるし、スイッチが介在することで回路上の接点も増える。まずはケーブルのつなぎ替えをしやすくなるようにしながら、なるべく接点が少なくなるようにと考えた。

当初、DAC側にインターコネクトケーブル（classic pro：CXX003）を延長用に追加することで、DACとアンプの切り替えをしやすくしようとしたんだけど、音の情報量が減ってしまった。最初は安価なケーブルの所為かとも思ったが、考えてみたらBrooklyn Ampとmonitor1の間に同等と思われるケーブルを使っていて、こっちは問題がない。
何が違うんだろうと考えて、もしかしたらケーブル間の接続部位を揺れないように固定したら、情報量が減るのを防げるのではないかと思い付いた。
そこで、ケーブル間をつなぐのにコネクターパネルを使ってみることにしたということだ。

最初はコネクターパネルの上流下流ともに通常のXLRケーブルでつなぐように考えていたんだけど、それだと接点が2ヶ所増えることになる。
上流のケーブルをコネクターパネルのXLRコネクター（オス）に半田付けしてしまえば、接点を1ヶ所に減らせる。ケーブルを交換したくなったら、XLRコネクターごと交換すればいい（これが手軽じゃないと知ったのは組んだ後だ）。
そんなふうに考えた結果、下図のようになった。
便宜上、上流側のケーブルを切り替えケーブルと呼んでみた。

まずは手元にあったBelden 88760で作ってみた。

細くて硬いのと慣れないのとで作業自体は難儀したけど、とりあえず使えるものは出来た。
音はというと、クリアで情報量の低下も少なく、コストパフォーマンスが高いと言われて評判が良いのも分かると思った。しかし若干中高域が強く中域が引っ込む印象。これで決定とするのではなく、他にも試してみようと思った。

次に試したのがキャブタイヤケーブル。３芯入っているのを入手しやすく作業もしやすい。
前のエントリーにも書いたが、1.25sqは個性が少なく嫌味が無いけど主張がない。聞きやすいけどオーディオ的には緩く、出て然るべき情報が表に出て来ないような印象だ。
2sqは若干ふんわりした感触の音になるが、比較的、情報量は保持している感触だった。
もう少しメリハリがあってもいい。

次にVVFケーブル。
スピーカーコードで使うにはコスパが高いという定評があるようで、うちでもアンプとアンプセレクターの間に使っているけど、インターコネクトに使ってるのはあんまり聞いたことがない。
この際だから使ってみることにした。
ケーブルの先だけ被膜を剥いで、コネクターに半田付けした。

VVFケーブルの被膜は、剥いだのを叩くとカチカチ音がする。
だからというわけじゃないかもしれないけど、音は平べったい感じ。ぺたーっとスピーカー間のライン上に貼り付いた感じで立体感、奥行きがない。
スピーカーで使うときにはそんな違和感ないんだけど。

そういうわけで、シースを外して捻ってみた。
多少、ましになった。
ましになったけど、依然として音が硬い。音像が棘を纏っていてSNも悪く潤いがない。

どうしたものかと考え、布を巻くことにした。物理的対策だ。
古くなったワイシャツを切って端切れにして保存していたものを、包帯ほどの幅に裂いて、少しきつめに巻いて養生テープで留めた。
ワイシャツともなれば肌触りがいい方向に音が変わるのではないか、、、

結果は、何と、期待したとおりの改善が得られた。
刺々しさが消えて、空間もかなり綺麗に表現できるようになった。
しかし、若干潤いに欠ける。ワイシャツって濡れてもすぐ乾くからね、乾きやすいんだろうかね。
これは許容範囲で収まるのかな、、、

https://www.amazon.com/Donnergrollen-und-Rotbauchunken/dp/B00KAYSSAA
この音源。
雷鳴や小鳥の声、雨音などが以前よりもリアルになった気がするんだけど、アブが近くに飛んで来なくなった。
これはいいのか悪いのかよく分からない、と最初は思っていたけど、そのうち気付く。、、飛んでいるアブの動線が、以前より明確に分かる。嵐で雷鳴が鳴る中、遠くの何処かでアブが飛んでいるのが聞こえたりもするのだ。雷鳴も以前より良くなっている。

https://www.amazon.com/BOULEZ-CONDUCTS-BART%C3%93K-Wooden-Multi-channel/dp/B08BTL9YRZ/
この音源、ブーレーズのwooden Prince、NYP。CDからリッピングして、以前から試聴用に使っていた音源だけど、序曲の弦を弾く音がより鮮明に聴こえる。鮮明になったらいいとばかりも言えない筈だが、とりあえず凄いと思った。大音量にしたときの見通しも以前より良いような。

どうもケーブル1本でDAC/アンプをつないだ場合より、改善している面がある様子。
単純に考えたら、音声信号の経路に介在物が増えた分、劣化するほうが自然なのだと思うのだけど、何がどうなっているのか。

理由として思い付いたのは、硬いVVFケーブルを介してオーディオラックとDACがつながることで、DACとXLRケーブルの接続部が補強された結果、音に改善面がみられたのではないか、ということ。VVFというのは本当に硬くて、たるむということがない。ラックにDACを固定して動かなくするような感じになっている。
物理的な変化が音に影響しても不思議はない。
ここで気になったのがDACによる違いはどうかということだ。というのは、Pegasus R2RのXLR端子は丈夫な筐体にがっちり固定されていて、ADI-2 DACはそうではなく緩い感じなのだ。だからADIのほうが音質変化が大きいのかな、と思ったら、どうも単純には言えないような感じ。細かい確認はしていないが、両方とも其々に相応の改善がある気がする。

数日経って養生テープは剥がれることに気付いて、テーピング用のテープに貼り替えた。貼り替えついでにワイシャツ布を二重にしている。
潤いに欠ける感じが少しだけ解消された？気もするが、気のせいかもしれない。
聞こえ方が変わるので、音源によっては良くなるばかりではないのがあるような。これは仕方がないかもしれない。

とりあえず、今のところそんな感じ。
そこそこの音質になったので取りあえずは良いのだけど、こうなるともうちょっと手を入れてみたいという気持ちも出てくる。
余裕がある範囲でやっていく。

最近のシステム構成は下図のような感じ。
なんだかごちゃごちゃしてるけど、これでいいかって感じ。

前回のエントリーで上げたDACとアンプの切り替え板だけど、切り替えは非常に簡単になり便利になった。
DACにつなぐケーブルの種類が増えている。キャブタイヤとかVVFとか、そんなんでいいのかなというようなケーブルでインターコネクトをつないでいる。

最初はベルデンの88760でつないだのだ。
情報量の低下は許容範囲。
ケーブル2本で普通に延長して垂らすより、板で補強を入れてつないだ方がしっかりするからだろうか、音の劣化が少ないように感じる。気のせいかな、、、

しかし、88760は若干特性が変わるような気がして（やや中高域が強く中域が引っ込む？）細身になるような気がしたので、他のケーブルも試してみようと思ったのだ。
オーディオ用も考えたけど、まずキャブタイヤでつないでみた。
1.25sqは個性が少なく嫌味が無いけど主張がない。
2sqの太さがぎりぎり使えた。若干ふんわりした感触の音になったけど悪くない印象。
次に1.6mm VVF。硬くて難儀した。
音はやや平面的かなと思ったので、シース（爪で叩くとカチカチ音がする）を剥いでケーブルに軽くツイストを入れた。これが両端を半田付けした後だと大変だということを知ったが、これで改善した？かな。シースを外したのと撚りを入れたのと、どっちが効いてるのか分からないが。

そういうわけで、前段後段で違うケーブルをつないで音を出している。
1本のケーブルでつないだ方が当然いいだろうと思っていたんだけど、どうも、意外にそうでもない。1本でつなぐと個性が強く出る弊害があるのだろうか、単純に接続部が少ない方が良いとも言えない感じだ。 何をどうしたらいいのか試行錯誤中だ。

Raspberry Pi2 / piCore7 でPulseaudioサーバーにした。

以前はUPNPレンダラー兼mpdサーバーのElitebookで相乗りさせていたんだけど、どうもssh経由で指示を打ち込む際にコマンドの種類が多すぎて使いにくい。
Pulseaudioで転送する音声データはYoutube、らじるらじる（英語講座を鳴らしたりとか）等を想定している。アップサンプリングしてオーディオ的な高音質を狙う必要性は少ないだろうとも判断して、幸い上流の切り替えも以前より楽になったことだしと思って、別建てにした。
最初はpiCore13で考えたんだけど、初期設定ファイルの書き方が変わっていたせいか上手くいかなかったので、早々に見切りを付けて7で作ってしまった。今から思えば13で作っておけば良かったかもしれない。まあ、追々必要になってからにする。

現在、上流の構成は、Deezer HiFiとDaphile、UPnP、mpd、PPAPの連携。自分的には最強仕様だ。自画自賛である。
サブスク44.1/16のデータは音源のデータ量としては十分。これをDaphileによりUPnPでmpdに転送、libsamplerate(SRC)でアップコンバートしPPAP方式で転送出力しUSB-DACに送る。
これ以上の音も世の中にはあるんだろうけど、自画自賛状態なので無いも同じである。

メインの音源はDeezer HiFiのストリーミング音源に移ったんだけど、それでもちょくちょく、NASのCDリッピング音源も鳴らしている。
操作は主にはWebブラウザで、Daphileの操作画面から行うことが多いんだけど、NAS音源へのアクセスなどの操作が早いのでncmpcppも使う。
Deezer内の検索は、DeezerのWeb Player画面から行うことが多い。「お気に入り」などへの登録もそこから行う。
DaphileからDeezer内を検索したりも出来なくはないんだけど、ちょっと操作画面が煩雑で使いにくい面がある。

Deezerで聴ける音源が少ないという不満は言って言えないこともないけど、日本の著作権周りが悪いんだからと思うとあんまりそこに文句言う気にもなれないし、音源が少ないったって膨大だ。Spotifyは音質的にはやや不足だけど、それで補完してもいいし、どうしても高音質で欲しければCDやダウンロードで買えばいい。
正直、ストリーミングに頼りっきりになるのは個人的には不安がある。

そんなこんなで、いよいよ不満らしい不満が無くなっている。
というか、PCオーディオ的には、今の自分にできることはほぼやり切って、これ以上手を入れる余地も少なくなっている。現状の音質を維持出来たら言うことはない。

Pegasus R2R DACは1MHz以上のサンプリング周波数を入力可能なので、うちのシステムで試してみたんだけど、途切れ途切れで再生速度も合わず上手くいかなかった。
たぶんハードのスペックをもっと上げるとか、リサンプリング方法を負担が少ない方式に変える必要があるのだ。以前だったら何とかやってみるか、とか考えたんじゃないかと思うのだけど、どうも今の自分にはそこをやるモチベーションが無いんだな。

PCオーディオは日進月歩の上、今日自分のとこで出来てることがハードが変わるだけで再構築しないといけないなんてこともあったり、今日提供されてるソフトウェアやディストリビューションが何時までもあるとは言えないので、スキルは維持しないといけないと思っているけど、とりあえず、オーディオを聴きながら、何をしようかと考えていこうと思っている。

18日、追記。
PCオーディオ周りの説明が何が何やら分かりにくい。
そこでもう少し詳細をエントリーに追記しておくことにした。

構成図のPCオーディオ周りだけ抜き出してみた。電源ラインは省略。
左から右にデジタルデータが流れていく感じかな。

まず左上がDaphile サーバー。
古いノートPC（Compaq 6730b）をUSBメモリから起動し使っているが、不具合は感じない。

左下にHP Probook 450 G3。普段使いのPCでOSはFedora。
ここからウェブブラウザ（Daphileのコントローラーでもある）、ncmpcpp、sshなど使って、データの流れをコントロール、設定する。

右に寄ると、Webにつながっている。
Deezer、Spotifyの他にも、YOutube等のストリーミングや日常的なウェブの使用、アップデートなどインターネットからのデータはここから降りてくる。

図の中央に来たら、NASがある。
収録音源の殆どはCDリッピングのflac + cue sheetだ。幾何か購入したハイレゾもある。

中央下にRaspberry Pi2。
Pulseaudioサーバーとして使っている。OSはpiCore7。
Probook 450 G3をPulseaudioクライアントとして使い、そこからのデータを受ける。

更に右に行くと、右上にHP Elitebook 2570p。
OSはTiny Core pure 64。
mpdサーバーであり、UPnPレンダラー、PPAPフロント、libsamplerate (src)を使ったリサンプリングサーバーでもある。
送られてきたデータを768/32にアップサンプリングして、右下のPPAPバックエンドに送る。

右下にApu2が2台。ともにOSはTiny Core pure 64。
PPAPバックエンドとして機能する。
2台のうち、どちらにデータを送るかは、右上Elitebookのmpdサーバーに設定する。左下のProbookからsshを介してアクセスし、mpdの設定ファイルを書き換える操作が必要で、ちょっとだけ手間がかかる。

使用状況に合わせて、図にデータの流れを書き込んでみる。

まず、Elitebook（mpdサーバー）にマウントしたNASの音源を、Probookからncmpcpp（mpdクライアント）で操作して鳴らす場合。
Daphileを導入する以前は、これが中心的な使い方だった。

操作指示の信号は赤い点線で表示。
図の左下、Probookからmpdクライアントのncmpcppで、右上Elitebookのmpdに指示を送る。

音声のデータは、赤い実線で表している。
図中央上のNASから、右上mpdサーバー兼PPAPフロントのElitebookにデータ送信。
Elitebookで768/32にアップサンプリング処理し右下のApu2に送信。

次に、Daphileの操作で運用するときの流れ。

Probookでウェブブラウザ上のアクセス画面からDaphileに指示を送る。
ウェブブラウザは、Daphileの操作をするだけではなく、Deezer自体も開いて検索や登録等に使用したり、ネットで情報確認するなど、あれこれと同時に使っている。

Daphileの役割は、サブスク（主にDeezer、サブにSpotify）のデータ、NASのデータを、UPnPに載せてmpd サーバーに送ることだ。
最近はNAS音源をDaphile経由で送ることも多い。
DaphileはTidal、Qobuzにも対応していて、Deezerと同じように使えるのではないかと思うんだけど、うちでは契約していないので確認は出来ていない。Apple MusicやAmazon Musicには対応していない筈？だがAirPlayプラグインを使えばiPhoneから転送可能、ということらしく、これもうちでは確認していない。もしも使えるようなら、音質上、運用上のメリットがあるかもしれない。

音声のデータの流れは、まずWeb、NASから、Daphileに。
DaphileはそのデータをUPnPによってElitebookに送信。
Elitebookで768/32にアップサンプリング処理され、Apu2に送信。

最後に、Pulseaudioサーバー。
Youtubeの音声など主にウェブブラウザの音声をメインのオーディオシステムで再生するのに使う。
pulseaudioの操作は、慣れないと煩雑だと感じるかもしれない。

まずProbook、ターミナルソフト上でPulseaudioのクライアントを設定。そこから音声出力するソフト（主にウェブブラウザソフト）を起動する。
更にProbookからsshでRaspberry Pi2にログインし、Pulseaudio起動の指示を送る。
これで設定終了。
バックグラウンドで常時動いてくれるというものではないようなので（何処かで設定できるのかもしれないが、出来ていない）、使用の度にこうした操作が必要になる。

設定した上で操作すれば、クライアントの音声出力ソフトを操作することで、音声のデータがRaspberry Pi2に送られる、という仕組みだ。
図では、ウェブからのデータをProbookでpulseaudioに乗せてraspberry pi2に送る流れを表示している。

さて、ここまで書いて、読み返してみて、やっぱり面倒に見えるだろうな、、、と思った。
サブスク周りは、手を付けようと思ったら本当に分かりにくくて面倒だ。
じゃあ、製品を買えばいいのかといえば、どうもそっちも面倒くさそうだ。

最近、オーディオ関連の雑誌社からサブスクに関するムックが出たり、他の某誌の誌面でも特集されていたりする。しかし件のムックを読んでも、結局は何をどうしたらいいのかは簡単には分からないことが分かるという感じだし、特集を組んでる某誌ではDeezerは名前が出てこない（！）。まあ業界雑誌だからそういう推す推さないのメリハリがはっきりしてるということだろうけど、そういう雑誌はあんまり信用できないってことになるんじゃなかろうか。余計なお世話か。

レコードだ、CDだと言ってた頃は、何でもいいからコンポを選んで鳴らしたら音が出た。
今はそうはいかない。どこから音楽を買うのかとか、何を使って再生するのかというとこまで、考えないといけないことが多過ぎると思う。スマホとイヤホンだけで取り敢えず済ませるのは簡単だ。そこから拡張しようと思ったら、わけが分からなくなる。
どのコンポは何に対応してるとか確認するだけでも一苦労する。
上記で取り上げた誌面とか、軽く見ただけだが、なんだか対応状況が間違ってるとこがあったり。専門で仕事する人が誌面を作っていても間違えが出てくる、それぐらい分かりにくい。もうスマホでいいや、と思う人は多いのではないだろうか。

そういう意味では、、、うちのシステムなんか簡単な方かも知れないな、、、
使ってるOSはすべてタダだし、PCも安価に間に合わせているし、、、それは難しさとは関係ないか。
まあ、ともかく、これからサブスクとオーディオの状況がどうなっていくのか、、、付いていくのがやっとになるかもしれないが、、、

DAC２つ、アンプ２つになった。
切り替えて使いたいんだけど、市販のセレクターには手頃なものがなかなか無い。自作するにはケースの加工とかハードルが高い。
しかし、気付いた。
バランス接続はノイズに強いんだから、ケースなんかなくてもいいんじゃなかろうか。
そういうわけで、自分なりにセレクターを工面してみようという気になった。

最初は、スイッチが付いている方が使いやすそうだと思っていたんだけど、信号経路に接点が増える。
試しにDAC-アンプ間のXLRケーブルにサウンドハウスで扱っているXLRケーブル（classic pro）をつないで延長して聴いてみたら、若干だが劣化がある感じ。amazonで入手した7000円弱のセレクターを通したときほどではないけど、しかしこれは、劣化なしにセレクターを作るのは簡単ではないかもと感じた。
とりあえず、スイッチは使わずケーブルの抜き差しをしやすくするためのボードを作ることにした。抜き差しがしやすくなるだけでも、かなり使いやすくなるはずだ。

作るといってもどうするか。
既製品で何か使えないかな。
サウンドハウスの通販サイト内を探していたら、使えそうなものが見つかった。

TOMOCA ( トモカ ) / P-112N コネクターパネル
https://www.soundhouse.co.jp/products/detail/item/92117/
NEUTRIK ( ノイトリック ) / NC3MD-LX-B
https://www.soundhouse.co.jp/products/detail/item/113754/
TOMOCA ( トモカ ) / M3×8mm
https://www.soundhouse.co.jp/products/detail/item/239776/

これらを組んで、うちのオーディオラックに取り付けることが出来ないか。
うちのオーディオラックは20年以上前にホームセンターなどで扱っているフレームを組んで作ったものを、組み直すなどしながら今も使っている。昔はマンテンという会社が作っていたが倒産し、現在はキタジマ　カラーアングルに引き継がれている、のかな？
https://www.kitajimasteel.com/shopbrand/C_karaanguru/
同じ規格？で作られているので、20年前に組んだラックを今でも拡張できる。
もっとオーディオラックらしいものにいつか替えたいと思いながら今まで来ている。ここまで来ると、多分もう替えないかなあ、便利だし。

トモカのパネルとカラーアングルとで、寸法は合うんだろうか。

とりあえず、やってみないことには始まらない。
部品を入手してみたら、ラックに組み付けることが出来そうだ。

コネクターパネルにノイトリックのXLR端子（オス）を専用ネジでネジ止め。ネジを締めても僅かにガタがあるので紙片を挿んで固定した（6月、追記。追加購入した端子はガタがなかったので紙片無しでネジ留めしている。ロットによってそういうことがあったのかも）。
この端子にDACにつなげるケーブルを半田付けする。配線には手元にあったBelden 88760を使う。数年前にXLRケーブルを作るつもりで入手したままになっていたものだ。これの先に、手元に余っていたXLR端子(メス)を付ける。88760は硬くて扱いにくかったが、何とか半田付けした。

これをラックにネジ止め。カラーアングル用のネジとコーナープレートが使える。
組み付け、出来ました。

裏はこんな感じ。半田付けしたまま剥き出しだが、まあ、いいかって感じ。

音はどうかというと、最初はピアノの音が硬く特定の音域が強く響いて、こりゃ88760で失敗か？と思ったけど、数時間でエージングしたのか、自然に聴こえる様になった気がするが、どうなのかな。
DACなどにつながっているケーブルを直接差し替えるよりは、ずっと扱いやすくなった。
あとは音の変化だけど、これは簡単には可否を決められない。暫くは使いながら、時間をかけて判断したい。

ネット上にはR2Rで768kHz対応という自作DACの記事がある。
以前から気になっていたけど、自作は手に余る。

それが先日、既製品でNOS R2Rで1536kHz対応というのがあると知った。
DACは数台あるし、安価とは言えないので迷ったが、入手した。
そもそもNOSだからR2Rだからどんな音になるとか決定的なものではないとは思うんだけど、R2R方式のDACは所有したことも聴いたこともないので。

MUSICIAN Pegasus R2R DAC
http://www.musician-audio.com/en/col.jsp?id=122

中国白雲区広州市の企業らしい。香港のすぐ近くだ。広東省深圳市からも近い。
10数万円とかでこんなん作るのは反則業だと思う。

amazonで購入手続きした後で気付く。
USBで1536kHz、それ以外で192kHzまでとamazonに記載があるけど、それって300、700kHz台は対応していないってこと？いや、まさか、、、
届いたamazonの箱を開けると、ダンボール箱が出てきて、それを開けたら製品の箱が出てくる。三重の梱包だ。
本体はずっしり重い。
脚は３つで前２後１なので背面にXLRケーブルを刺すときに揺れやすいので注意。筐体デザインの関係で右XLRケーブルの着脱が若干やりにくい。これは直してほしいところ。
テスト環境につなぎ、mpdサーバーにコマンドを打つ。

tc@box:~$ cat /proc/asound/card0/stream0
MUSICIAN USB HiRes Audio at usb-0000:00:10.0-1, high speed : USB Audio

Playback:
  Status: Stop
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000, 1411200, 1536000
    Data packet interval: 125 us
    Bits: 32
  Interface 1
    Altset 2
    Format: SPECIAL DSD_U32_BE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000, 1411200, 1536000
    Data packet interval: 125 us
    Bits: 32

とりあえず、よかった。まあ、変な心配しすぎだよね。
以下、レビュー等のアドレス。

Musician Audio Pegasus R2R DAC Review
https://soundnews.net/sources/dacs/musician-audio-pegasus-r2r-dac-review/
Measurements of Musician Pegasus R2R DAC
https://www.audiosciencereview.com/forum/index.php?threads/measurements-of-musician-pegasus-r2r-dac.18786/
Musician Audio Pegasus R2R DAC Review
https://headfonics.com/musician-audio-pegasus-r2r-dac-review/
MUSICIAN Pegasus R2R DAC
https://audiophilestyle.com/forums/topic/59435-musician-pegasus-r2r-dac/

さて、1週間たった。エージングも進んだ筈。
音はどうか、、、
NOSの設定で、音源は768kHz32bit。アンプはSM-SX100。

それが、、、ADI-2 DACと区別がつかない（ｗ；）。
なんとなくPegasusのほうがまろやかで、なんとなくADIのほうが清涼感がある、ような気もするが、ブラインドで当てろと言われたら全く自信がない。いや、ブラインドでなくても、あれ、、、今、どっちを鳴らしてたっけ？と思って確認を要するような、そういう感じ。
音が同じじゃ使い分けも出来ない。
どうしたものかと思っていたら、更に数日で、もう少しだけ音が変わった。

音場が、広く深く、拡大したような感触。見渡しが良くなり余韻の響きがより細やかになった。
空気感があるというのか、湿度感というのか、独特の雰囲気がある。音の実体感の違いと言う方がいいのか、注意して聴いたら耳当たり、聴こえ方に差がある。

Pegasusu (NOS)は空気感、湿度感があり柔らかい。羽毛で優しく撫でるような心地良さがある。これは、嵌る人は嵌るんじゃないだろうか。
ADI-2はクールで硬質な鳴り方で、こういうのはモニター的という表現が当てはまるのだろうか。
以前、ADI-2の音について珊瑚礁の海のようなと表現したことがあった。潜るときは息を詰める。冷たい水のように聴く者を覚まさせるような鳴り方をする。それに対してPegasusの音は暖かい空気だ。優しい空気で包まれていて、大息をついても寝てしまっても問題ない。音源の性格によって、どちらが似合うかが違うように思う。楽音の明瞭さ、情報量、スピード感は同等で、クオリティの差は聴き取れないように感じるが、音像にまとわり付く余韻の質が違うという感じ。それらがどうリアリティに結びついているのかが、判断できない。これはもう比較試聴のスキル、経験が足りないとしか言いようがない気がする。

NOS設定を解除すると音色の感触が変わる。若干、ADI-2の音に近付く。比べるとNOSのほうがまろやかな音がする（まろやかと言っても緩い訳ではなく、キレは良い）。
昔、ΔΣ方式でNOS（アップコンバージョンOFF）で使えるというDACを一時所有し聴いたことがある。そのときのNOSの音は刺々しさがあり、うちでは使えないかな、と思った。
PegasusはむしろNOSのほうがいい。
OS有りがいけないというわけではないけど、硬めの音色になったときにはADI-2のほうが説得力が高い。
NOSのほうがPegasusの持ち味を生かせるのではないかと思う。

今回の試聴では、途中からAmazonで入手したセレクターでDACを切り替えていた。入手自体は1年前。
https://www.amazon.co.jp/gp/product/B07R1661QH/
DACとアンプをつなぐケーブルの接続変更には時間が掛かり、聴いた音のイメージが薄れてしまう。
セレクターを使ったら切り替えは迅速になるけど、若干だが音が劣化する。DACの本領が発揮されないが、高品位なセレクターで対応となると現状では難しい。ケーブルの抜き差しで比べるしかない。

そんなこんなで、あれやこれやとやっているうちに、聴き比べも飽きたというか、、、根気が尽きた。
ほぼ同等のDACが2台になったでいいんじゃないかな、という気分に。
いや、ほぼ同等だが、、、
もしかしたらだが、メインのDACは代替りするかもしれない。
というのは、Pegasusは時が経つに連れて更に良くなってるような気がするからだ。デジタル系コンポのウォーミングアップには数週間かかることもある。もう暫く使いながら様子を見る。

さて、一息ついて、確認しておいた方がいいことを確認しておく。

まず、1536kHz PPAPを試す。
ncmpcpp上で「paused」になり音が出ない。何処がボトルネックなのかも分からない。今後の課題。
PPAPなしで1536kHzなら出来るのか、その辺りから試してみることになるだろうけど。

次は、アップサンプリングなしでどうなのかを試す。
R2R NOS、44.1/16で聴いてみる。

ADI-2 DACと比較すると、Pegasusのほうが聴きやすい、、かな？
ADI-2の音は硬さが強調されがちで、ときに聞き辛いときがある（libsamplerateによる音源のアップサンプリングによってそういう聞き辛さは減っていくのだが）。
Pegasus (NOS)の音は、そういう硬さが少ないような。じゃあOS有りだとどうなのかというと、意外とこれも悪くない。硬くなりすぎずに透明感が出てくるのでピアノなどは音源によってはこっちのほういいかもしれない。NOSだと少しふんわりした感じになる。何れにしても、耳馴染みが良い音がする。

しかし、そうは言っても、うちでは768/32にアップサンプリングして使う。
その方がよりリアルで高品位な音がするのは、Pegasus R2R DACもADI-2 DACも同じだ。

画像ではLEDの光が白く飛んでいる。実際はもっと赤い光だ。
768kHzのデータを入力すると48k、x2、x8のLEDが点灯する。
DACとアンプが2×2になって此処からどう組んでいくか、使いながら考えていこうと思う。しかし、どちらの音も捨てがたい感じ。簡単には結論が出そうにない。

tc@box:~$ /usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=2048 --buffer-size=16384 -t raw -f S32_LE -r1536000 -c2"
aplay: main:642: bad speed value 1536000
aplay: main:642: bad speed value 1536000
aplay: main:642: bad speed value 1536000
^C
tc@box:~$

https://fossies.org/linux/alsa-utils/aplay/aplay.c

Member "alsa-utils-1.2.5.1/aplay/aplay.c" (14 Jun 2021, 90204 Bytes) of package /linux/misc/alsa-utils-1.2.5.1.tar.bz2:

    ＊snip＊

644   if (tmp < 2000 || tmp > 768000) {
645       error(_("bad speed value %i"), tmp);
646       return 1;
647   }

    ＊snip＊

tc@box:~$ vi .mpdconf

resampler {
plugin "libsamplerate"
type "Linear Interpolator"
# type "Fastest Sinc Interpolator"
}

audio_output_format   "1536000:32:2"
# audio_buffer_size "65536"
audio_buffer_size "130000"
buffer_before_play "80%"


tc@box:~$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 1536000 (1536000/1)
period_size: 32768
buffer_size: 131072
tc@box:~$

今回は備忘録。
うちのメインシステムにはCDプレーヤーがない。
でも、リッピングする前に聴きたいと思うこともある。そこを何とか出来ないかということ。

参考にした記事はこちら。
海上忍のラズパイ・オーディオ通信（10）ラズパイ・オーディオで音楽CDのダイレクト再生に挑戦！果たして使い物になるか？
https://www.phileweb.com/review/article/201602/12/1965.html

この記事にもあるけど、トラックの選曲が出来ないのでリッピングしたほうが便利に使えるしCDドライブがうるさいので、限局的な使用に留まるだろうとは思った。けどまあ、使えるようにしたよ、ということで。これはこれで楽しい。

今はテスト環境で運用中。
sshでサーバにログインし「mpc」でCDをmpdのプレイリストに登録して鳴らしている。CDからmpdが768kHzにアップサンプリングし、PPAPでメインシステムに送る。
リップしたファイルより音がいい？
これは、多分に気のせいだと思う。ブラインドでは区別不能だ。

手順をごく簡単に書いておく。Googleにアップしたアップサンプリングサーバーを加工する。
まず、tceでCD関係のtcz、以下をインストール。

libcdio.tcz
libcdio-dev.tcz
libcdio-paranoia.tcz
libcdio-paranoia-dev.tcz

続いて、mpdを再インストールする必要がある。
mpdがcdio-paranoiaに対応していないからだ

tc@box:~$ mpd -V
Music Player Daemon 0.20.20

Protocols:
 file:// http:// https:// alsa://

まず、インストールされているのをアンインストールする。
/mnt/sda1/tce/optional にあるmpd関係を削除。
続いて、/mnt/sda1/tce/onboot.lstのmpdの記載を#でコメントアウト（今回、行削除せずコメントアウトでも問題ないことを確認した）。
これで再インストール行程に入れる。

sudo ntpclient -s -c 1 -h ntp.nict.jp
wget https://www.musicpd.org/download/mpd/0.20/mpd-0.20.20.tar.xz
xz -dv mpd-0.20*
tar -xf mpd-0.20*
ls
cd mpd-0.20*
./configure --enable-pipe-output --enable-cdio_paranoia-input
make
mkdir ../mpd
sudo make DESTDIR=../mpd install

cd
mksquashfs mpd mpd-0.20.20.tcz
md5sum mpd-0.20.20.tcz > mpd-0.20.20.tcz.md5.txt
sudo mv *tcz* /mnt/*1/tce/optional
sudo vi /mnt/*1/tce/onboot.lst
sudo rm -rf mpd*

これで、mpdがCD-DAに対応。

tc@box:~$ mpd -V
Music Player Daemon 0.20.20

Protocols:
 file:// http:// https:// cdda:// alsa://

input {
    plugin "cdio_paranoia"
    speed "1"
}

input {
    plugin "cdio_paranoia"
    speed "4"
## mode "overlap"
mode "disable"
}

audio_output_format   "384000:32:2"
audio_buffer_size   "32768"
buffer_before_play   "75%"

input {
    plugin "cdio_paranoia"
    speed "4"
## mode "overlap"
mode "disable"
skip "yes"
}

操作は「mpc」から行う必要があるので、インストール。
当初は最新のバージョン0.33をインストールしようとしたが、例によってmesonを使うので慣れないので0.28にした。

wget https://www.musicpd.org/download/mpc/0/mpc-0.28.tar.xz
xz -dv mpc*
tar -xf mpc-0.28*
cd mpc-0.28
ls
./configure
make
mkdir ../mpc
sudo make DESTDIR=../mpc install

cd
mksquashfs mpc mpc-0.28.tcz
md5sum mpc-0.28.tcz > mpc-0.28.tcz.md5.txt
sudo mv *tcz* /mnt/*1/tce/optional
sudo vi /mnt/*1/tce/onboot.lst
sudo rm -rf mpc*

これでインストール完了。
使うには、CDドライブを表すデバイスファイルのパーミッション変更が必要とのこと。
/opt/bootlocal.sh にコマンド追記し、OS起動時に変更するように設定しておく。

sudo vi /opt/bootlocal.sh

chmod 666 /dev/sr0

filetool.sh -b
sudo reboot

設定保存し、再起動。これでCDから音を出すことができる。
CDドライブが2つ以上ある時はどうなるかは検証していない。

CDをドライブにセットしsshから「mpc add cdda://」と打つことで、CDをmpdのプレイリストに登録。
続いて「mpc play」で、音が出る。
CD１枚が1つのファイルとして認識されるので不便だけど、通しで聴くとか、それでもいいならという感じ。

音量調整や再生停止程度のことはmpcで出来る。「mpc volume 70」「mpc stop」こんな感じ。
下記、操作説明書のアドレス。

mpc 0.34 documentation
https://www.musicpd.org/doc/mpc/html/

最近のシステム構成は下図のような感じ。上流を若干整理した。

Daphileサーバーはオーディオシステムから離した。音質上の配慮ではなく使い易さの事情だ。音質上の変化もないと思う。
当初はDeezerの再生だけ想定していたんだけど、NASマウントの再生でも使用するようになった。流れというか、ついついというか、いちいちncmpcppを開くのが面倒で、Daphile画面からNASのディレクトリ階層構造をたどって鳴らしている。
本当は、ncmpcppから操作する方がずっと速いのだ。Daphileはいちいち表示に時間がかかる。サクサク快適なのはncmpcppのほうがずっと上だけど、、、
NAS音源再生の音は、Daphileからの操作とncmpcppからの再生では、わずかだがncmpcppのほうが勝る。upmpdcliとnfs、後者の方が負担が少ないということなんだろう。しかし、ふだん聴くのに神経質になるほどの差異ではないので、目の前で開いているDaphileのインターフェイスから操作してしまうということだ。朝三暮四というか怠惰である。
Deezerに置いてない音源もざらにあるので、未だにCDを購入することもあるし、リッピングしたファイルは捨てられない。

DaphileではYoutubeも鳴らすことが出来るらしいんだけど、なんだか手順が複雑で分かりにくく感じられて出来ていない。
そういうわけで、アップサンプリングサーバーのPulseaudioサーバーとしての機能も維持している。Youtubeの音声をサーバーに転送し上限384kHzにアップして再生する手法で、所謂空気録音の試聴とかで使うつもりなんだけど、まだ整備できていない。

FX-08miniを１台戻している。電源アダプターが壊れたので、過去にRaspberry Piに使って意外に好印象だったUSB電源を使って動かしている。
音楽信号が700kHz台の領域とそれ以外を100Base-Tで分ける形になっている。一応これは音質上の配慮なんだけど、おまじないレベルで留まっていて、音の変化があるかどうかの確認をしていない。たぶん、しないまんまになるんじゃないかなあ、、、なんとなく良くなってる気がするで済ませている。

アップサンプリングサーバーのディスクイメージをアップして半月だが、どの程度ダウンロードされているのか、分からない。まあ、それはGoogle Driveの仕様みたいなので仕方ないけど。
もう暫くツイッターのトップには掲示ツイートを留めておこうとは思っている。

柄にもなく今回アップしたのは、今回のイメージは比較的使い易くまとまったので、アップしておく意味もあるかな、と思えたというのが大きい。

数年前にイメージをアップしないのかと訊かれたことはあったんだけど、当時はしなかった。
有志の努力で広く公開され提供されているものを、此方でダウンロードして組み合わせただけで、作ろうと思えば誰でも作れるものを、自分で作ったもの？のようにアップする気にはなれなかったというのが大きかった。
加えて、自分が使っているのが一般的にみて使い易いシステムとは思えなかったというのもあった。使いにくいところに、大したフォローもできないということになれば、興味を持ってダウンロードしてくれた筈の人が興味を失うことになり、そういうのは残念なので。

しかし手前味噌だが、今回アップしたイメージのセットは使い易く出来ていて、アップしてもいいだろうと思った。
初心者でも左程困らずに動かせそうだし、多少マニアックな使い方にも耐えそうだ。
ただ組み合わせただけ、という意味では以前と同じだけど、かかる手間暇の軽減という意味も今回のはあるだろうし、まあ、いいか、という気になった。いろいろネットから世話になっているので成果物を置いとくというのもおかしいが、何処かしら、こっちの気が済むというのがある。自己満足に過ぎないといえば、そうなんだろうけど。

当初からの目的は、libsamplerateの音を実際に聴いてみてほしいというのがあった。
環境を整えた上で聴いたことがある人は、実は少ないのではないかと思うので。
充分にPCのスペックを上げて、300、700kHzとサンプリング周波数を上げてこそ、libsamplerateを使う本当のメリットが生まれてくるというのが僕の実感だ。そういう再生をしてもらって、どんなシステムだとどんな風に聴こえるのか、僕自身が知りたかったというのがある。

そんな手法では聴きたくないという人もいるだろうし、当然そういう人には薦めない。
しかし、どうなのかね、、、
この数年間で、音質改善するいろんな手法が技術的に生まれてきているし、ニーズも興味をもたれることも、あんまりないかもしれない。libsamplerateは使っても意味が無いということになっているようで、いろんな事情で廃れる技術というのはあるんで、それならそれで仕方ないということになるのかも知れないが。

先日アップしたイメージをPPAPに転用する方法について記載した日記をPhile webにアップした。

いや、人に説明するというのは難しいものだ。こっちは分かってるから相手もある程度分かってるかのような気になってしまう。とりあえず、理解してもらう説明は後回しで（というか、それって大変すぎ）、動かせるようにということで書いている。それでも何かしら不備がある。

アップしたイメージのPPAPへの転用について
https://community.phileweb.com/mypage/entry/5010/20210425/67563/

PPAPでの使い方なので、バックエンドもアップした。
両方のイメージファイルを置いてあるGoogleのアドレスを書いておく。

20210418-TC64-mpd-pa-upnp-AutoStart.img
https://drive.google.com/file/d/1eZ-ijekRj-ond1OIa7aZXgLxjWYbsIPy/view?usp=sharing

tc64-11-1-base1z-2020-04-05-PPAP-BE.img
https://drive.google.com/file/d/1kHhCtR4WCWs3_8i32JrVgGFin-YK9KIZ/view?usp=sharing

先日、Google Driveにうちで使っているアップサンプリングサーバーをイメージ化したものをアップした。
Phile Webで記事にしている。

UPnPレンダラー兼アップサンプリングサーバーのディスクイメージをアップしました
https://community.phileweb.com/mypage/entry/5010/20210418/67519/

https://drive.google.com/file/d/1eZ-ijekRj-ond1OIa7aZXgLxjWYbsIPy/view?usp=sharing

うちのシステムそのままだと不便だろうと思ったので、アップする前にいくつか改造を施した。
それらの点についてメモしておく。

１）OSブート時にmpd、upmpdcliが自動的に起動するようにした

うちではmpd、upmpdcliはsshでログインして起動するようにしている。 これを、OS boot時に同時に起動させるようにした。

sudo vi /opt/bootlocal.sh

mpd /home/tc/.mpdconf
adduser upmpdcli -H -D
upmpdcli -D -c /home/tc/.upmpdcliconf


vi .upmpdcliconf

mpdhost = localhost
logfilename = /home/tc/.upmpdcli.log
loglevel = 2
friendlyname = MPD-SRC
mpdport = 6600

これで、mpdはrootで起動する。 upmpdcliはrootでは起動できない仕様なので、ユーザーupmpdcliをboot時に作成し、これを依り代に起動させる。

うちのシステムでは何故こうしていないかというと、mpdがrootで起動していたら「mpd --kill」コマンドが効かないからだ。 mpd.confを書き換え設定変更することが多かったので、たびたびmpdを止める必要があった。いちいちps打ってプロセスidを確認してsudo killとか、面倒でやっていられない。 だから自動起動は不採用になった。

upmpdcliについては、そうした問題はないので採用してもいいんだけど、mpd起動のついでにupmpdcliもコマンド1発で起こせるので、ほったらかしになっているという感じ。この際だから、うちでも使うことにするかもしれない。

２）alsa出力設定を２つにした

mpd.confでalsa出力を設定している。 古いノートPCや、現在のうちのアップサンプリングサーバーでは問題なかったんだけど、新しいノートPC（といっても、10年近く前に発売だけど）でbootしたとき、BIOS設定でPCのサウンドカードをオフにしただけでは音が出ないことがあった。 aplay -lで確認したら、0,0ではなく1,0がUSB-DACに振られている。

tc@box:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: IncRAL2496UT1 [RATOC Systems, Inc.RAL-2496UT1_], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
tc@box:~$ 

BIOSでPCのサウンドカードをオンにしたままでPC起動したら、PCのサウンドカードが1,0、USB-DACが2,0になった。 つまり0,0が振られないのだ。

tc@box:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: PCH [HDA Intel PCH], device 0: ALC3228 Analog [ALC3228 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: IncRAL2496UT1 [RATOC Systems, Inc.RAL-2496UT1_], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
tc@box:~$

なぜこんな仕様になっているのか分からないけど、alsaを設定するのには困る。

対策が見つからなかったので、0,0と1,0、両方にalsa出力するようにmpd.confに記載した。 BIOSでオンボード音声をオフにして、USB-DACひとつだけ繋いだ状態なら、0,0か1,0、どちらかに引っかかって音声出力できるのではないだろうか。 うちにあるいくつかのPCで試した限りでは、問題なく機能した。 こんな感じ。

vi .mpdconf


audio_output {
 type   "alsa"
 name   "My ALSA Device 0"
 device "plughw:0,0"
}
audio_output {
 type   "alsa"
 name   "My ALSA Device 1"
 device "plughw:1,0"
}

３）alsa出力先サウンドカードの設定を変更しフォーマット変更に対応させた

alsaの出力先は、mpd.confで一般的には下記のように記載することが多い。

device "hw:1,0"

以前のエントリーで書いたが「hw:0,0」のような記載だと、mpd.confで指定されたフォーマットに出力が固定される。 うちではそれでいいが、他者が使う想定だと、個々のUSB-DACに設定を合わせないといけない。それには、mpd.confの書き換え、保存という手順が必要で、sshでログインして、viを使わないといけない、なんていうのは扱いにくいだろう。

device "plughw:0,0"

そこで、「plughw:0,0」に設定記載を変更した。 この記載だったら、USB-DACが対応しているフォーマットを、alsaが読み取って調整してくれる。DACが対応している最上限のフォーマットに自動的に合わせるはずだ。 mpd.confに書かれている768/32がセットが対応する上限設定ということになる。

下記内容の日記をPhile webにアップした。
https://community.phileweb.com/mypage/entry/5010/20210418/67519/

このたび思う処あり、ディスクイメージをGoogleにアップしました。
どなたでも使っていただいて結構です。

https://drive.google.com/file/d/1eZ-ijekRj-ond1OIa7aZXgLxjWYbsIPy/view?usp=sharing

イメージについて説明します。

１）セット内容とコンセプト：
linux OS（Tiny Core Pure64 11.1）ベースで作成しています。
有線LAN経由でUPnP/DLNAサーバーから信号受信。mpd、upmpdcli、libsamplerate(SRC)で処理し、alsa経由でUSB-DACに出力することを想定しています。
この際にUSB-DACから処理できるフォーマットを読み取り、アップサンプリングします。例えばUSB-DACが対応しているフォーマットの上限が384/32だった場合、そのフォーマットにアップサンプリングしてDACに送るということです。768/32までのアップサンプリングに対応しています。

つまり、このセットはlibsamplerateによるアップサンプリングの音を聴くためのシステムということです。
libsamplerateは以前はmpdのデフォルトとされていましたが、情報処理の負担が大きい割りにメリットが少ないと考えられたようで、最近はSoXによるアップサンプリングが主流です。
しかし、libsamplerateのほうがより正確な音声情報処理が行われ、44.1/16のデータからでもハイレゾファイルと同等の再生音が得られます。特に300、700kHz台で優位性が得られると考えています。処理の負荷は高いので、PCに要求されるスペックは高くなります。700kHz以上にアップサンプリングする場合、DDR3以上のメモリを積んだPCが必要です。

２）使用方法：
イメージをusbメモリ等のストレージに書き込み起動ディスクとします。
Tiny Core Pure64ベースなので、AMD64、Intel64のPCで使用できます。
有線LANにつないでください。無線は対応できていません。

PC起動に際し、BIOSでPC自体のサウンドボードをオフにしてください。こうすることでUSB-DACがalsaから最優先の出力先に選択され、細かい設定をssh経由で行う必要がなくなる筈です。
セットを書き込んだストレージから起動するようにBIOSを設定してください。
無事に起動したら、UPnP/DLNAのコントローラーから「MPD-SRC」を選択し音声出力できる状態になります。

３）その他の機能：
sshでログインし設定など変更可能です。パスは「tc」です。
pulseaudioサーバー、PPAPフロントとして機能させることができます。

04.20. 追記です。-------------
sshでログインに際して、ユーザーは「tc」です。書き忘れていました。
Tiny Core Pure64ベースのセットで、扱い方はTiny Coreそのものです。
mpd.confは、/home/tc/.mpdconfで設定しています。
追記終わり。-------------

出来れば使っていただいた所感を、この記事のコメントで教えていただければ有難いです。
何分にも、このような試みは私自身初めてでもありlinuxのスキルも限られているため、トラブル等のフォローはできないと思いますので、自己責任でお使いください。質問等には可能な限り返信させていただきますが、出来ない場合もありますのでご容赦ください。

以上、宜しくお願いいたします。

思う処あって、ということなんだけど、実際、迷ったけどアップしてみることにした。
どんな反応があるかは分からないが。

うちではlibsamplerate(SRC)なしではオーディオシステム自体が成り立たないというような重要なコーデックであるにも関わらず、世間では意味が無いとされている。世間と書いたが、少なくともpulseaudio界隈ではそうなっている。なるようになるしかないのかもしれないが、意味が無いということはないということを井の中の蛙のようなうちのサイトで書いてるだけではダメかなと思うことがあり、、、まあ、なるようになるだろうということで、イメージをアップしてみたということだ。

僕自身が井の中の蛙だということがある。
他のオーディオファイル諸氏の音を聴いたことがない。うちの音を聴いてもらったことがない。
コロナ禍でいよいよ困難になった。イメージでもアップして試してもらうしかないじゃないか。

そういうわけで、宜しければ使ってみてください。
レスはphile webか、twitter（ https://twitter.com/flyingnote）で受け付けます。

何が忙しいって、新譜を聴くのに忙しい。
正確には新譜ではなく、Deezerの「Top Charts」に上がってくるアルバムを聴くのに忙しいんだけど。

DeezerのWeb Playerには「最も再生されたアルバム」という項目があって、ここに上がってくるアルバムはDeezerが僕の嗜好に合わせてくれるようで、好みの音源が次々に上がってくる。アルバム100枚が１～数日？で入れ替わって表示されるようだ。
何で僕の嗜好に合わせているのが分かるかというと、僕以外の誰が再生するんだ？というような音源で、且つ僕が数日内に再生した音源が、いくつか混じっているからだ。僕と似たような嗜好のDeezer利用者が最近聴いている音源を集めてみました、ということらしい。
けっこう重宝して利用していた。

Daphileではこれが「Top Charts」の中の「Albums」という項目で表示される（僕の好みに調整されたチャートで、どうしてTopというのかとは思うけど）。
Web Playerでは100作品までが上がっているけど、どういう仕組みか分からないけど、Daphileだとさらに200作品が追加され、Web Playerの3倍のリストになる。とても全部は聴けないので、気になるものだけ聴いてるけど、それでも充分過ぎる量になる。

ちなみに「Top Charts」には「Albums」以外に「Tracks」「Artists」という項目もある。しかしTracksは雑然としすぎていて掴み所がない。Artistsは変化が少なく新鮮味に欠ける。
Albumsのチャートは日々変化し、聴いてみたら面白いと思うものが多く刺激的だ。
ネット配信で曲単位の時代と言われるが、アルバムのほうが僕みたいなのにはとっつきやすく分かりやすい。
なんというのかな、アルバムというのはコース料理なのだ。
前菜だけとかメインだけとかでは物足らない。シェフを並べられても困るのだ。コースを食うことで世界観を掴めるような気がする。まあ、1トラックで満足できる曲も勿論あるのだけど、最近の曲より昔の曲で多いような気がする。

そんなことはさておき。
うちのオーディオシステム構成図を見ていて気付いたことがある。

前回のエントリーで、Deezer/DaphileとNAS音源の比較は「僅かに違うような気もするんだけど、気のせいレベル」と書いたのだけど、もしかしたらNASの音は、DaphileにNASをマウントしたほうが、mpdアップサンプリングサーバーの負担が減って良くなるんじゃないのか。
つまり、DaphileにNASをマウントして鳴らさないと、厳密な比較は出来ないのではないか。
下図のような感じ。

以前、RAMメモリー再生という再生方式を採用していたことがあるのだけど、マウントしたNASの音源を再生するよりも音が良かった。UPnPも試したことがあったが、cueシートに対応できないので採用しなかったんだけど、その音は何処かRAMメモリー再生の再生音と通じるものがあると感じていた。
PPAPで鳴らしている現在、大きな変化はないかもしれないけど、簡単に試せるだろうし、と思ってやってみた。
問題は、うちのリッピングファイルはアルバム単位のflacで、Daphile/UPnPだとおそらくはアルバム単位でしか選曲できないということだ。しかし、ダウンロードしたファイルはトラック毎になっているので使えるかな。、、、と思っていたんだけど、、、

大きな番狂わせがあった。それは後述。

とりあえず、DaphileにNASの共有ディレクトリをマウントする。
最初のマウントには再起動の操作が必要で、数分かかることもあるようだ。
せっかくなので、手順を記載しておく。

Daphileの操作画面からSettings、Storageを開くと、「Network drives」という項目がある（画面上では既に「ariel」という共有ディレクトリが登録されている）。

新たにNASの共有ディレクトリをマウントするには「Add new」をクリック。
選択肢が出るので、うちでは「nfs」を選択。

入力項目が追加される。ここに必要項目（サーバーのip、共有したいディレクトリの名称）を記載していく。portは入れなくても良いようだ。「Local mount name」にDaphileに登録する名前を記入する（しなかったらどうなるかは試していない）。
記入後、下の「Save & Restart」で再起動。
再起動しないとマウント作業自体が行われないようだ。
うまくマウントできなかったら、赤丸のエラーマークが表示されるのだけど、スクリーンショットは撮り忘れた。

Daphileにマウントされた共有ディレクトリは、Home画面の My Music > Music Folder > Network Drives に表示される。
共有ディレクトリ内の音源のデータは、My MusicのAlbum Artists等の項目にも反映される。しかし、NAS上の全てのデータを取りこめてはいない。取りこぼしが多く充分には当てに出来ない。訂正。これは僕の勘違いだったっぽい。ちゃんと取り込んでるのかな、、、
アルバムのアートワークも何処からか引っ張ってくるようだ。これも正確ではないこともある。
「Network Drives」以下はNASの共有ディレクトリ自体の階層構造が反映されるようで、こっちのほうがAlbum ArtistsやAlbumsのデータよりも正確に見える。

共有ディレクトリの中の階層を下っていくとflacやcueシートが表示される。
だけどcueシートは機能しないはず。これはUPnPの仕様なので仕方ない、、、
と、思っていたら、、、
なんとcueシートが使える！
これはどういう仕組みなんだろう。僕のようなNASの音源にcueシートを多用する人間には朗報だ。

どうもflacファイル自体に対しては再生操作は出来ず、cueシートのほうから再生などの操作が出来るようになっている。

これは、「Albums」のリストから音源を表示した画面。
Album ArtistsやAlbumsからの操作では、CD１枚で１つのflacになっているはずの音源が、曲別での操作が可能になっている。
うちのNAS上の音源自体はCD１枚のflacとcueシートだが、あたかも個別の曲ごとのファイルに分かれているかの様に、曲選択や再生ができるということだ。

Daphileというのは、すごいディストリビューションだと改めて思った。
しかし、本当に上手く機能してるのかな、、、
暫く使いながら確認していく。

音質の話。
Daphileマウントとmpdマウントで、音を比較。
比較に使った音源は下記。
CD1枚のflacファイルを試聴に使うので両方1曲目だ（分かりにくいので追記。試聴していた時は、cue sheetが使えることに気付いていなかったので、こんな文面になった。直し忘れていたということ）。

ヘンデル：オラトリオ「時と真理の勝利」（ユンゲ・カントライ／フランクフルト・バロック管／マルティーニ）
HANDEL: Trionfo del Tempo e della Verita (Il)
Part l: Sonata dell'Overtura, HWV 46a (Allegro) - Adagio - (Allegro); Sinfonia, HWV 46b - Allegro - Adagio

ハイドン：バリトン三重奏曲全集 1 （エステルハージ・アンサンブル／ピッコロ・コンチェルト）
HAYDN, J.: Baryton Trios (Complete), Vol. 1 (Esterházy Ensemble, Piccolo Concerto)
Baryton Trio No. 1 in A Major, Hob. XI:1: I. Adagio

正直、ほとんど区別が付かない。
僅かにDaphileマウントのほうが滑らかでmpdマウントのほうが強いような気がするが、気のせいで片付くレベルだ。

ここで、Deezerからストリーミング音源と比較する。
上記の音源はDeezerでも聴くことができる。リマスターとかこちらにとって不都合なことは多分してないだろうと思われる。

https://www.deezer.com/ja/track/83013464
https://www.deezer.com/ja/track/84850231
（これらはDeezerにログインしていないと表示されないことに後で気付いた）

正直、これも区別が付かない。
mpdマウントの音に近いのか？気のせいで片付くレベルだ。明日には評価が変わりかねない。
PPAPを止めたら違いが出るのかも知れないけど、そこまでしなくていいかと思っている。

今回は、すごい発見があった。僕にとってはすごい発見なのだ。
引き続き、取り組んで行きたい。

昨年度末までに、Deezer用にDaphileをUPnPサーバー、Tiny Core/mpdをUPnPレンダラーとして使うことで、ストリーミングサービスの音も768/32にアップサンプリング、PPAPで再生できるようになった。
いやー、いいですよこれは。
音が良いのも勿論だけど、上流2系統を切り替えて使うことが、以前よりもずっと容易になった。
手元のPCで音源再生する操作自体で切り替わる。

以前のDeezer再生システムは、時期によってpulseaudioだったり、piCorePlayerだったり、Daphile自体だったりしたけど、ずっとNAS音源再生のシステムとは音声信号の処理方法が違っていた。だからUSBケーブルを物理的に繋ぎ変えることでしか、上流の接続を切り替える方法がなかった。
USBセレクターの自作まで考えたが、結局できていない。

現在、上流はNAS用とDeezer用、2系統のPPAP Front。
中流以降はADI-2 DAC/SM-SX100系とM500/Brooklyn Amp系、2系統をそれぞれのPPAP Back endが受ける。
それらが両方がPPAP 768/32になった。
PPAP Back endは、常に768/32のデータが来るのを待っている状態なので、そこにデータを流し込む操作さえすれば、その音が出る。
データを流し込むだけでいいのだから、手元のノートPC上で音を出す操作をするだけで切り替えが出来る。具体的には、ウェブブラウザからDaphileを操作するか、ncmpcppからNAS音源再生の操作をすると、操作した方の音が出る。セレクターに類するものは弄らない、というか、ない。
感覚的には切り替え操作自体を意識する必要が殆どなくなる。
ただ、上流両方から出力しないように気をつける必要はありそうだけど。

ストリーミング音源とCDリッピング音源の差異は、殆ど無い。
聴き分けは僕の耳では不可能だ。僅かに違うような気もするんだけど、気のせいレベルだと思う。 Frontのハードの差異か、LANへの繋がり方の違いはあるんじゃないかと思うのだけど、同じ条件でストリーミング音源とCDリッピング音源を比較したら、違いがあるとは言えない感じだ。upmpdcliが動いているかどうかも、差異を生むとは言い難いと思った。

出力先の変更は、もう少し面倒だ。
PPAP Frontの出力先の設定を書き換えることでPPAP Back end-USB DAC-アンプを選択し、mpdを再起動することで、変更する。
DAC、アンプがセットで切り替わるので、スピーカーから音が出るようにアンプセレクターのところまで歩いて行って切り替える必要がある。

今のシステムでは、DACとアンプの接続を切り替えるには両者をつなぐXLRケーブルを抜き差ししないといけないので少し面倒だ。結果、SM-SX100はADI-2 DACと繋ぎっぱなしだし、Brooklyn AmpはM500と繋ぎっぱなしということになる。
市販のセレクターはRCA用だと選択肢が多いけど、XLRケーブル用で上下2系統というのは、なかなか手頃なのが無い。
しかし今後、切り替えが出来るようにしたい。検討中。

それにしても、現在のシステムはこんな感じ。

上流が、ごちゃごちゃしていて分かりにくい。もっとすっきりさせたい。
どうするかこれも検討中。

一応、RatocのDACを残しているのは、youtubeなどの音源をウェブブラウザ-pulseaudioの経路で聴くため。とかいいながら、使う機会がないんだけど。

前回に引き続き、UPnPでデータを飛ばしてレンダラーに組み込んだlibsamplerateでアップサンプリングするプラン。
DebianやFedoraなどではリポジトリから読み込みが出来る様なんだけど（訂正。今のFedoraではソースからのインストールが必要。リポジトリからのインストールが出来たのはv30、31の頃のようだ）、今回は、Tiny Core Pure 64での試み。ソースからのインストールが必要になる。
これが本丸だ。
相当梃子摺るかと思ったが、案外順調にできてしまった。順調と言ってもPulseaudioと比べたら、だけど。
以下、経過を記載しておく。

今回、打ち込んだコマンド等、過程の詳細な記載は省略した。要点だけ書いている。
いつもはこまごまと書くんだけど、長くなりすぎるので。

Daphileの操作画面キャプチャ画像。
右下にTiny Coreのmpdがレンダラーに選択されているのが見える。MPD-90というのはipアドレスだ。
Daphileサーバーはcompaq 6730bに戻している。有線LANに繋がらない2570pは返品、返金となった。

準備

最初からTiny Core Pure 64を組んでいくのは面倒なので、以前にmpdを組み込み、Pulseaudioを組み込みして、昨年10月にバックアップしたイメージを使う。
ストリーミング音源をpulseaudioで転送しアップサンプリング再生する（10月15日、追記）
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20201011a.htm

ハードはapu2c4。
以前はこれで768kHzへのアップサンプリング再生をしていたけど、最近は使っていなかった。
apu2c4で768kHzへのアップサンプリングに取り組む
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20181208a.htm

SDカードにイメージを書き込み、apu2c4に刺して起動。 sshでログイン。

まず、upmpdcliの説明サイトから引用。

Upmpdcli and associated libraries downloads
https://www.lesbonscomptes.com/upmpdcli/upmpdcli-manual.html#UPMPDCLI-PACKAGES

For building from source, you will need a C++ compiler with full C++11 support, and the development packages for the supporting libraries: libcurl, libmicrohttpd, libmpdclient, and libexpat.
Also the Python modules for streaming service support use the python-requests package, so you may need to install it (it is only needed at run time).
If you are using the source from the git repository, you will also need the autoconf, automake, libtool trio. Use the autogen.sh script to set things up.

この説明サイトは膨大で目が回りそうだけど、今回は要所だけ読んでなんとかした。
ライブラリとして、「libcurl, libmicrohttpd, libmpdclient, and libexpat」が必要と書いている。あと、python-requests、「autoconf, automake, libtool trio（トリオなんだ）」が要るような。

Tiny Coreの状況を確認。
curl expat2 expat2-devは既にインストールされている。
tceで、以下インストール。

# tce
curl-dev.tcz libmicrohttpd.tcz libmicrohttpd-dev.tcz

libmpdclientはリポジトリにtczがないので、ソースからインストール。
最新のはインストールにmeson-ninjaを使う。
敢えて面倒な事はしたくなかったので、以前のバージョンを選択。

wget https://www.musicpd.org/download/libmpdclient/2/libmpdclient-2.11.tar.xz

# tce
doxygen automake

doxygenがないよ、と指摘される。そうだったっけ？
一応、確認したらautomakeもない。既にインストールされてるとばかり思っていた、、、
更に、作業の前には時計を合わせておかないと、エラーになるので合わせる。

sudo ntpclient -s -c 1 -h ntp.nict.jp

./configure、makeの過程で以下警告あり。今回は気にせず進む。

/home/tc/libmpdclient-2.11/include/mpd/connection.h:98: warning: explicit link request to 'MPD_HOST' could not be resolved
/home/tc/libmpdclient-2.11/include/mpd/connection.h:98: warning: explicit link request to 'MPD_PORT' could not be resolved
/home/tc/libmpdclient-2.11/include/mpd/connection.h:99: warning: explicit link request to 'MPD_TIMEOUT' could not be resolved

sudo make DESTDIR=../libmpdclient install

libtool:   error: '../libmpdclient/usr/local/lib' must be an absolute directory name

sudo make DESTDIR=/home/tc/libmpdclient install

make installから、tczファイルを作って、/mnt/*/tce/optionalに保存する。
ここらへんで、python-requestsをインストールしとく（インストールし忘れていた）。

# tce
python3.6-requests.tcz

upmpdcliをインストール

下記のソースコード配布ページからソースをダウンロード。

Upmpdcli and associated libraries downloads
https://www.lesbonscomptes.com/upmpdcli/pages/downloads.html

Current version (tar files):

libnpupnp-4.1.1.tar.gz
libupnpp-0.21.0.tar.gz
upmpdcli-1.5.11.tar.gz
sc2mpd-1.1.8.tar.gz

順次、インストールしていく。
sc2mpdはOpenHome関連で、うちの環境とは関係ないのでインストールしていない（後でインストールしとけば良かったかなと思ったけど、動く環境作る方が優先なので）。
これらのソース、あちこちファイル読んでもインストールの手法が見つからない。
./configure、make、make--install、tcz保存、通常の流れでインストールできる。

wget https://www.lesbonscomptes.com/upmpdcli/downloads/libnpupnp-4.1.1.tar.gz
./configure
make

checking whether build environment is sane... configure: error: newly created file is older than distributed files!

時計を合わせるのを忘れたらこんな警告が出る。

sudo ntpclient -s -c 1 -h ntp.nict.jp

順次、インストール。

wget https://www.lesbonscomptes.com/upmpdcli/downloads/libupnpp-0.21.0.tar.gz

wget https://www.lesbonscomptes.com/upmpdcli/downloads/upmpdcli-1.5.11.tar.gz

途中で足りないライブラリがあると指摘され下記インストールしている。

# tce
jsoncpp-dev.tcz

mpdを再インストール

さて、これで動くかというと動かない。下記、mpdの状況を確認。

tc@box:~$ mpd -V
Music Player Daemon 0.20.20

Database plugins:
 simple


pi@volumio:~$ mpd -V
Music Player Daemon 0.19.1

Database plugins:
 simple proxy upnp

Storage plugins:
 local smbclient nfs

Neighbor plugins:
 smbclient upnp

Tiny CoreとVolumio 1.55のmpdの状況を比較。
使えるプラグインの表示が違う。Tiny Coreのほうはupnpの表示がない。
再インストールだ。

sudo ntpclient -s -c 1 -h ntp.nict.jp

wget https://www.musicpd.org/download/mpd/0.20/mpd-0.20.20.tar.xz

./configure --enable-pipe-output

mpdインストールのいつもの工程で再インストールしたが、それだけでは動かなかった。
./configureのオプション指定を変える。

./configure --enable-pipe-output --enable-upnp

configure: error: UPnP client support: libupnp not found

# tce
libupnp.tcz libupnp-dev.tcz

なんと、、ここでlibupnpがないと指摘された。
実は、tczリポジトリにはupnp関係のtczは沢山あって、でも何が要るやら分からなかったのでインストールしてなかったのだ。
tceでインストール。
その後は順調に進んで、インストールできた。

tc@box:~$ mpd -V
Music Player Daemon 0.20.20

Database plugins:
 simple proxy upnp

Storage plugins:
 local curl

Neighbor plugins:
 upnp

インストール終了時点　概要

インストール終了時点でのonboot.lstは下記の通り。

sudo vi /mnt/*1/tce/onboot.lst

openssh.tcz
i2c-5.4.3-tinycore64.tcz
alsa-modules-5.4.3-tinycore64.tcz
alsa.tcz
gcc.tcz
boost-1.65-dev.tcz
pkg-config.tcz
bison.tcz
autoconf.tcz
libtool-dev.tcz
bc.tcz
cmake.tcz
compiletc.tcz
squashfs-tools.tcz
ntpclient.tcz
libsamplerate.tcz
libsamplerate-dev.tcz
lame.tcz
lame-dev.tcz
libmad.tcz
libmad-dev.tcz
nfs-utils.tcz
nmap.tcz
libcap-dev.tcz
alsa-plugins-dev.tcz
alsa-config.tcz
alsa-dev.tcz
gudev-lib.tcz
dbus-dev.tcz
pulseaudio-13.0.tcz
libmicrohttpd.tcz
libmicrohttpd-dev.tcz
curl-dev.tcz
doxygen.tcz
automake.tcz
libmpdclient-2.11.tcz
python3.6-requests.tcz
libnpupnp-4.1.1.tcz
libupnpp-0.21.0.tcz
jsoncpp-dev.tcz
upmpdcli-1.5.11.tcz
libupnp.tcz
libupnp-dev.tcz
mpd-0.20.20.tcz

upmpdcliを動かす

mpdを起動（うちではssh経由で起動するのがデフォルト）。
DaphileにUpNPレンダラーとして認識されたら、ウェブブラウザ操作画面のプレーヤー表示部に出てくるはずなんだけど、出て来ない。
upmpdcliがインストールしただけでは動いてないので、起動しないといけない。

Upmpdcli
https://www.lesbonscomptes.com/upmpdcli/upmpdcli-manual.html

In most situations, upmpdcli will be run as follows:

upmpdcli -D -c /etc/upmpdcli.conf

The -D option tells upmpdcli to fork and run in background. The -c option specifies a configuration file. See the upmpdcli(1) manual page for more information about the command line.

マニュアル、膨大なんだけど。
わけが分からないと言いながらあれこれ、、、

tc@box:~$ upmpdcli --help
upmpdcli: usage:
-c configfile 	 configuration file to use
-h host    	 specify host MPD is running on
-p port     	 specify MPD port
-d logfilename	 debug messages to
-l loglevel	  log level (0-6)
-D    	 run as a daemon
-f friendlyname	 define device displayed name
-q 0|1	 if set, we own the mpd queue, else avoid clearing it whenever we feel like it
-i iface    	 specify network interface name to be used for UPnP
-P upport    	 specify port number to be used for UPnP
-O 0|1	 decide if we run and export the OpenHome services
-v      	print version info
-m <0|1|2|3|4> media server mode (default, multidev|only renderer|only media|embedded|multidev)

Upmpdcli 1.5.11 libupnpp 0.21.0
tc@box:~$ 

試行錯誤するうちに、こんなんが表示された（実は --help 以外でも、例えば --x とかでも表示される）。
ここから起動コマンドを考える。

upmpdcli -D -m 1 -f MPD-90 -d /home/tc/.upmpdcli.log -l 2 -O 0

sshから上記コマンドでupmpdcliを起動。
出来ました！
Daphileにupnpレンダラーとして認識された。これで、音が出る筈。
本当は、upmpdcli.confで設定して運用するほうがスマートなんだけど、当面はこれで動かすことにする。

upmpdcli.confの原本は下記に保存されている。コピーして使えばいいのだろうか。
まだ使い方が分からない。
/usr/local/share/upmpdcli/upmpdcli.conf-dist

PPAPで音を出す

実はこのTiny Core Pure 64、もともとのイメージファイルがPPAP Frontとして機能するように作られている。
768kHzにアップサンプリングして、PPAP Back-Endに送る設定がこの時点で既に出来ている。

USB DACを繋いでmpd.conf再設定とか面倒だったので、いきなりそれで使ってみることにした。
PPAP環境は常日頃から使っていて出来ているので、Daphileから音を出す操作をしたら、そのままPPAPシステムに繋がる筈ということだ。
こんなイメージ。

音は出ました。

Frontの状況。

CPU0: 45.8% usr  3.5% sys  0.0% nic 50.0% idle  0.0% io  0.0% irq  0.5% sirq
CPU1: 10.7% usr  3.3% sys  0.0% nic 85.9% idle  0.0% io  0.0% irq  0.0% sirq
CPU2:  9.9% usr  2.5% sys  0.0% nic 87.5% idle  0.0% io  0.0% irq  0.0% sirq
CPU3: 43.7% usr  0.3% sys  0.0% nic 55.2% idle  0.0% io  0.0% irq  0.5% sirq
Load average: 1.09 0.97 0.56 3/386 3852
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 6776     1 tc       S     507m 12.8   0 26.5 mpd
 2841  6776 tc       S    16480  0.4   2  1.4 /usr/local/bin/ncat 192.168.1.89 4400
 3637  6742 tc       R     4016  0.1   1  0.2 top
15901     1 tc       S    1743m 44.2   3  0.1 upmpdcli -D -m 3 -f MPD-90 -d /home/tc/.upmpdcli.log -l 2 -O 0

Back-Endの状況。

tc@box:~$ cat /proc/asound/card*/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 768000 (768000/1)
period_size: 4096
buffer_size: 32768
tc@box:~$ 

Mem: 103904K used, 3925992K free, 18384K shrd, 5676K buff, 34188K cached
CPU:  0.2% usr  2.1% sys  0.0% nic 97.1% idle  0.0% io  0.0% irq  0.5% sirq
Load average: 0.06 0.04 0.00 3/113 17254
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
17204  1213 root     S    15484  0.3   3  1.0 /usr/local/bin/ncat -kl 4400 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=32768 -t raw -f S32_LE -r768000 -c2
17205 17204 root     S     4608  0.1   1  0.5 /usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=32768 -t raw -f S32_LE -r768000 -c2
   30     2 root     IW       0  0.0   1  0.1 [kworker/1:1-eve]
17254 17226 tc       R     4016  0.1   2  0.0 top
 1213  1094 root     S    15484  0.3   1  0.0 /usr/local/bin/ncat -kl 4400 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=32768 -t raw -f S32_LE -r768000 -c2
17222  1211 root     S     5872  0.1   0  0.0 sshd: tc [priv]

音の方は、NASの音に比べてDaphileからのほうが固いような気がする。NASが絹のような感触だとしたら、Daphileからのほうはガラスのような感触というか。
そもそもアップサンプリングサーバーがHP Elitebookとapu2c4で違う機械だとか状況が違うので、音も違うのが当たり前だと思う。

もう少しだけソフトだったらいいかなと思うけど、768kHzじゃないと出ない音が出ている。
運用しながら調整していきたい。