abk1's scratched blog 3

去年のエントリーで、PPAPでCD同等音源（サンプリング周波数が44.1kHz）を鳴らそうとしたら上手くいかない、という話があった。音がブチブチ途切れたり、コントローラーでの操作が反映されるのに数10秒かかる。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20241212a.htm

今回、これが概ね解決したのでエントリーにしておく。

mpdサーバーが繋がっているスイッチングハブ、GS105Eは、ポートの速度を調整できる。44.1kHz音源を扱うmpdサーバーが繋がっているポートの速度を、自動（1000M）から 100M Full に変更したら、問題なく音が出て、違和感なく操作できるようになった。
といっても、mpdとalsaの設定で多少の調整は必要だったが。

つまり、Back-Endへのデータ送信が速すぎたのだ。

多分、PPAPのmpdサーバーは、音声再生時にはデータがあればあるだけ先を見ずに送ってしまう。
過剰なデータは、ncatかalsaのバッファに保存されるのだろう。
44.1kHzの音源は音声の時間あたりのデータ量が比較的少ない。だからコントローラーから出音を止めようとしても、何10秒も音が出続ける。
一方、アップサンプリングしたデータ（うちでは8倍以上にアップサンプリングする）は時間あたりのデータ量が多いので、数秒以内で反応し音が止まるので、比較的、違和感なく使える。

だから、44.1kHz音源のmpdサーバーの通信経路を100Base-Tにしたら、通信量は1000Base-Tの10分の1なので、安定して違和感なく音声再生される。100Base-Tのスイッチングハブを使ったらいいかもしれない。
あるいは、無線LANのほうが有線より遅いので、問題なく再生されるようになる（有線LANに問題があると思ったが、そうではなかった）。
mpdサーバーのLANポートへの設定ができるなら、そういう対応でもいいかもしれない。今回は試していないが、ethtoolというソフトでポートの速度を設定できるということだ。

PPAPというシステムは、サーバー間で伝送を調製する仕組みが殆ど無いということがわかる。
たぶん、ncatというのはそういうことをするソフトではないのだ。
だから人が調整してやらないといけない。
今更、そんなことに気付いた。
良くも悪くも複雑でないぶん、システムの負担が少ないので、音質上はメリットがある筈だ。
しかし、音が途切れたりバッファにデータを溜め込んだりするようでは、少ないはずの負担が増えるだろうから、そうしたメリットも目減りすることになるだろうけど。

さて、この問題を解決してみたら、意外に44.1kHzでRaspberry Piでも、そこそこ音がいい。
去年は、ちゃんと再生できていなかったのかもしれない。

前回のエントリーでは、テストシステムで、CD同等の44.1kHzを鳴らしてみる試みについて書いた。
音はそこそこ聴けるようになった。しかし完全に安定しているとは言えず、ときに音が途切れるような感じがする。

ここ数ヶ月、44.1kHzを聴いてきて、最初に感じていたのは優秀録音音源のありがたさだ。
libsamplerateで384kHz以上にアップサンプリングするメインシステムを使っていて感じていたのは、録音が悪い音源って実はあんまり無いよね、ということだった。大抵の音源が気持ちよく聴ける。
それが、44.1kHzだとそうはいかなかった。
大抵は不満が出る。優秀録音音源は、オアシスのように感じられた。それでもメインシステムには到底及ばなかった。
それが、44.1kHz PPAP直結にすると、メインシステムほどではないけど、多くの音源で不満が少なくなる。
そして、優秀録音音源は、ほんとうに気持ちよく聴けるようになる。これってメインシステムだっけ？という音がする。アップサンプリングなんてしなくても44.1kHzでいいんだよ、という見解が、すごく説得力を持って迫ってくる。
しかし、この差異は、なんで生じるんだろうかね。

久しぶりにメインシステムを聴いてみたら、なんだかしゃきっとしない。おかしいなあ、と考えるうち、PPAP Back Endのapu2d4に銅板仮想アースを繋ぎっぱなしだったことを思い出す。これは１、２週に1回ほど外してやらないと、副作用が蓄積するのだ。数ヶ月、繋ぎっぱなしでは音が濁ってしまう。
外して暫く待つうちに、本来の音が戻ってくる。
44.1kHzよりもいい音だけど、差はかなり縮まっている。

もっと多くの44.1kHzを満足できる音質で鳴らせるシステムを作れないだろうか、というのはある。
ひまがあったらやれたらいいなあ、とか思う。そんなのは音質に定評のあるディストリビューションを使えばいいじゃないかという考えもあろうけど、自分でやってみるというのが僕にとってのオーディオらしい。趣味だからそれでいいのだ。
しかし、ひまがないなあ。

とりあえず、前エントリーに書いたようなFrontとBack-endの直結を試みたが、上手くいかなかった。
FrontにnfsでマウントしたNAS音源は問題なく鳴らせるのだけど、upmpdcliがmpdを認識しない。つまり、LMSサーバーからupnpで送り込むストリーミング音源を受けられないのだ。これは権限の問題らしいんだけど、解決策がはっきりしない。仕方がないので、Middle-end経由に戻している。
音質については、Middle-end経由と比較して特に優れているという印象はなかった。

しかし、こうなってくると、何でMiddle-end経由だとupnpを伝送できるのか、よく分からない。
いろいろとすっきりしないが、様子見だ。

現在のシステムはこんな感じ。今回からIPアドレスを書き込んである。
Roonが外れたので、以前よりはすっきりしている。まだごみごみしている。しかし、あんまり直ぐには手を入れるつもりはない。

今年も新年が来た。歴史が続く限り新年は来る。

やっておれんわとか、なんとかならんのかとか、感じることもあるけどそんなことも言っておれない。
ぼやくのは正月で終わらせたい。
また普段の生活が始まる。それだけでも自分は恵まれている。

前回のエントリーで、最近はCD同等の音源をアップサンプリングせずに聴いていると書いた。
メインのシステムではなく、テストに使ったりするのが目的のサブシステムだ。
PPAPで、Middle Endを使わず、Back EndはRas Pi2。
満足できる音色ではない。

Ras Pi2を、直結にしてみたいと書いたが、やってみた。
mpdサーバー兼PPAP Front（ノートPC）、PPAP Middle End（apu2c4）、Back End（Ras Pi2）、という流れで、後半のMiddle End、Back Endを直結し、家庭内LANからネットワークを切り離す。

音は、明らかに良くなった。
正直、ここまで変わるのかと驚いた。
淀みが消えて透明感が増して、音自体の強さが立ち上がってくる。SNが改善してきめ細かな階調。ザラつきが取れてシルキーだ。見通し風通しが良くなり、騒がしくなく耳あたりがいい。
384kHzのデータを流しているメインシステムのapu2d4を直結化したときよりも、聴感上の変化はずっと大きい。

ただ、音全体のクオリティアップに比して情報量の改善が少なく感じて、なんだか違和感がある。もう少し細かい音が聴こえるはずだろう、と感じてしまう。うちのリファレンスは384kHzで、それに僕が慣れてしまってるので、仕方がないかもしれない。

大きな問題は、操作に音が着いてこないということ。
つまり、コントローラーであるノートPCからボリュームを変えたり曲を止めたりする操作をしても、音への反応が10秒以上遅れる。数秒なら我慢できるが、10秒を超えたら、なかなか不便だ。

以前、こんなんだったかな、と思って過去のエントリーを読み返してみた。
PPAPを始めた頃は、どうも既にアップサンプリングして24/96で使っていて、44.1kHzではどのようだったかは書いていない。
去年の秋に44.1を試みた記録がある。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20231031a.htm
アップサンプリングなしでは使い物にならないということで、このときは操作に数十秒（！）かかるとか、書いてある。

そんなこんなで、考えられるのは、PPAP middle Endを中継すると操作への追随が遅くなるらしいということ。
先日までMiddle Endなしで使っていたときには、こんなことはなかった。

どうしようかね。
まあ、しかたない。当面は多少の不便は気にしないことにしようか、、。
とか思ってたんだけど、聴いていたら、ときどき途切れそうになるのが分かったり、やはり不安定だ。いずれ、なんとかせにゃあおえん。

そんなわけで、44.1kHzで使っているmpdサーバー、EliteBook 820G2を、なんとかすることにした。

策は、WiFiで家庭内LANにつなぎ、有線LAN端子から直結でRas Pi2に出力することでネットワーク分離する、というもの。
Middle Endを排除することで操作性は改善できる筈。

問題は、いらないパケットが来ないかわりに、ノートPCというノイズ源がBack Endの傍に来る、ということだ。
メリットが上回るかどうかはやってみないと分からない。
最近は機械のノイズが多いなら光で繋げばいいじゃんというのもあるけど、今回はそこまではしない。

という方針で、とりあえず820G2を無線LAN接続にする。
wifi.tczというのをTiny Coreにインストールして設定。詳細は、下記エントリーを参照。piCoreの記事だが似たようなものだ。今回はtceコマンドで見ることができるwifi.tczの説明書きどおりで、問題なく動いた。
http://blown-lei.net/endive/blosxom.cgi/pc/20211109a.htm

さて、無線LANで繋いでみたので、ためしに音を出してみる。
すると、なんと、操作に動作が遅れる問題が、解消した。解消してしまった。

どうも有線接続に問題があったようだ。これは問題である。
去年の秋に上手く行かなかったときに使ったのは、同じサーバーだ。
しかし、だったら、なんで、アップサンプリングしたら問題なく動くんだろう。
分からない。
しかたがないので、当面、よしとする。

音は、有線の時よりも、落ち着いた。
音の強さが減って、大人しくなった。自然になったかもしれない。先に情報量の少なさに違和感を感じると書いたが、感じなくなった。

どうやら、システムが安定しないときのデジタルオーディオの眼光凛々の剣豪の効果が出ていたらしい。
眼光凛々の剣豪というのは下記エントリーを参照。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20161025a.htm
しかし、これは本当は、なんなんだろうかね。
気を付けないといけない。

剣豪はいなくなったが、十分、満足できる音だ。
ネットワーク分離の効果は大きく、それだけでも相当のノイズ対策になったと思われる。今回は勉強になった。

最近、オーディオサーバーのノイズ対策に、筐体内に銅メッシュを仕込むというのを試みている。

まずPPAP Back-End、Middle-Endときて、Daphileサーバー2台に仕込んだ。
次に、mpdサーバーに仕込む。
mpdサーバーはPPAP Frontであり、UPnPレンダラーでもある。うちではそういう構成で運用している。

まず、テスト用mpdサーバー。
機種は、Hp Elitebook 820 G2。中古のノートPCだ。OSはTiny Core 64 11.1。
仕込み中の写真は撮り忘れた。
銅メッシュはキーボードの裏側に置ければ良かったんだけど、分解の手間が多い。本体の底面側を開けるのは簡単なので、そこに絶縁用の藁半紙と一緒に設置した。GNDはファンの縁の地金に銅メッシュを押し付けて取ることに。
気になるのは、銅メッシュの設置位置が筐体の空気吸入孔に重なるので、冷却機能に影響しないかということ。あまり温度が上がるようなら、設置場所を再検討しないといけない。

前回エントリーと同様の方法で、温度を確認した。
3秒ごとの数値を5分間計測しtxtファイルに打ち出し、それを集計し電卓等を使って平均値を出す。

tc@box:~$ watch -t -n 3 cat /sys/class/thermal/thermal_zone0/temp > temp.txt
[ab@fedora1 Documents]$ awk '{sum+=$1}END{print sum}' temp.txt

44438 (min:44000 max:45000)

音を出していないときの温度は、若干、上がった。風通しが悪いからか、、、

次に、音楽を鳴らしてどうなるか確認した。
ちなみに前エントリー以降、温度計測に際して音源に使っているのは下記CD box、1枚目CDのリッピングflacファイル。NAS音源だ。
Quator Danel - Shostakovich - The Complete String Quartets
https://www.discogs.com/release/8599892

Fastest、192kHz
47926 (min:47000 max:50000)

Fastest、768kHz
51383 (min:48000 max:58000)

Medium、768kHz
57876 (min:51000 max:65000)

Best、192kHz
56093 (min:53000 max:62000)

銅メッシュをつける前と比べたら、若干温度は下がっているのかな。どうだろう。

音質はどうなのか。
Medium、768kHzで鳴らす。
ぐっと、良くなった、気がする。何より色合いが濃くなって力強くなった。以前のテスト系 Medium 768kHzは、メイン系のBest 384kHzと比べたら、良く言えばスマートでモニター的だが線が細い印象だったんだけど、厚みが出てきた。

NAS音源でメイン系と比較してみる。libsamplerateの設定が違うので、音は違う。しかし差異はかなり小さくなった気がする。ブラインドでの聞き分けは、僕には出来ないだろう。

ストリーミング音源はどうだろうか。上述した音源は、Deezerにもある。
以前より、ずっと良くなっていると感じる。
NAS音源との比較では、差はある。比較したらNASの方がキレが良くて生命力が強いのだ。若干、情報量も多いような気がする。しかし、以前よりも差は減った。ブラインドで当てるのは、かなり聞き慣れた音源でないと難しそうだ。

テスト系とメイン系で、ストリーミング音源再生を比較してみる。
設定が違うので音も若干違うが、NAS音源のときと同様、音色の濃さがほぼ同等になった。
テスト系の音は、以前はクールで淡白な感触だった。それが銅メッシュを組み込んでからは、熱を帯びて鳴るようになっている。音色がメイン系に近付いて、色合いが濃くなったような感じだ。同時に、余音のような、音と音の間を埋めるような音が、より明瞭にリアルになった感触がある。
なんというか、これだけ聴いていたら、ストリーミングだけで何が不満なのか、という感じに鳴っている。

ここでテスト系とメイン系、mpdの設定を同じにして比較してみる。
メイン系をテスト系に合わせて、Medium 768kHzに。これはテスト系サーバーにとっては相当重く、メイン系サーバーにとっては比較的軽い操作だ。
音源はストリーミング。
温度だけ見たら、テスト系は20℃近く、メイン系は15℃弱ぐらい上がるようだ。
音は、メイン系の方に余裕があるようで僅かに反応が早い。ブラインドでは分からないんじゃないかな。
以前は、ここまで僅差ではなかった。それでも、この微妙な差は、もしかしたら重要な感じで、響きの美しさはメイン系の方が僅かに良いのかな。

ストリーミング音源使用時の温度。
前述のCDリッピング音源と同じ作品の、Deezer音源を使用した。下記が結果。

Fastest、192kHz
49952 (min:49000 max:51000)
Fastest、768kHz
53644 (min:51000 max:61000)
Medium、768kHz
60738 (min:53000 max:68000)
Best、192kHz
57295 (min:52000 max:63000)

やはり、温度は上がっている。UPnPの負担が増えているので当然か。
そういえば、銅メッシュなしのとき、ストリーミングでどうだったか、記録してないな、、、
銅メッシュを外して、ストリーミングで鳴らしてみた。結果は下記。

Fastest、192kHz
47786 (min:47000 max:49000)
Fastest、768kHz
53748 (min:51000 max:62000)
Medium、768kHz
60738 (min:53000 max:69000)
Best、192kHz
58291 (min:54000 max:64000)

温度はメッシュを付けているときよりも低いときがある。前回エントリーで挙げた、NAS音源を鳴らしていたときよりも低いときもある。銅メッシュで温度が下がるというのが、怪しくなってきた。筐体の蓋を開閉した直後に測ったせいかもしれないが、関係ないかもしれない。本当はもっと繰り返しデータを取るべきなんだろうが、そこまで取り組む根気はない。

銅メッシュを外すと、音は良くも悪くもクールになる。奥行、深みは少ないが、これはこれで、そんなに悪くはない。すっきりしていて涼しくて淡麗だ。しかし比較し評価するなら、メッシュがあるほうがいい。
温度を表にしておく。

さて、次はメイン系mpdサーバーの処理だ。

他のサーバーに比べたら新しい。
機種は、Hp Probook 450 G9。OSはTiny Core 64 14.0。
作業に入る前に、銅メッシュなしの状態で温度のデータを取る。
mpdの設定は、Best、384kHzで固定。そのかわり、音を出してるときのデータは、4回取る。

音を出していないとき
47000 (min:47000 max:47000)

NAS音源
70896 (min:69000 max:73000)
71262 (min:64000 max:75000)
71705 (min:65000 max:75000)
71514 (min:70000 max:74000)

ストリーミング音源
71442 (min:66000 max:75000)
71252 (min:68000 max:74000)
71292 (min:69000 max:74000)
71609 (min:68000 max:74000)

以上、時系列。
NAS音源を鳴らし始めて3分後からデータをとり始めたけど、ちょっと早いのかもしれない。10分ぐらい待った方がよさそうだ（テスト系のときは数10分後から測り始めている）。

意外だったのは、テスト系ではストリーミング音源で温度が上がる傾向があったのに、メイン系では上がらないことだ。NASとストリーミングの音質の差と温度の差に相関関係がありそうだと思っていたのだけど。

いや、考えてみたら上流のデジタルデータを受け付けているmpdサーバーで、データが同じなのに（まあ、調べたわけじゃないけど、同じだと思うんだよね、、）、上流のサーバーが違ったら発熱量が違うほうが、本当はいけないのだ。
でもそこは、ジッターの差によって、負荷が違うのだろうと想像していた。
メイン系は新しい機種で性能も上で、処理能力が大きいので温度差が出ないのだろうか。

テスト系の音を聴き直してみる。設定は、Medium、384kHz。
たしかにNASとストリーミングでは音質に差があり、聴き比べたら、テスト系よりもメイン系の方が音質差は少ない。しかし少ないながらも、音質の差はあるのだ。CPUの温度には現れないレベルということなのだろうか。
そして、驚いたこと。
テスト系より、メイン系の方が、音が乾いて聴こえるのだ。テスト系の方が生々しい気がする。

テスト系を768kHzで鳴らしてみる。音の雰囲気が変わり、こうなると、メイン系との比較が出来なくなった。

メイン系に銅メッシュを仕込む。
筐体の底板を開けるのは比較的簡単。銅メッシュを仕込む隙間もある。
しかし、簡単にGNDがとれない。丸形端子をネジ止めできたらいいんだけど、意外に適当な使えるネジがない。銅メッシュにケーブルを半田付けし、その先の丸形端子を筐体の地金にテープで貼ることにした。
こんな感じ。

電源を入れ、しばし放置して温度を測る。

音を出していないとき
46000 (min:46000 max:46000)

NAS音源
70991 (min:69000 max:74000)
71154 (min:64000 max:74000)
72029 (min:70000 max:75000)
71775 (min:64000 max:74000)

ストリーミング音源
71775 (min:62000 max:75000)
70706 (min:56000 max:74000)
72010 (min:64000 max:75000)
72282 (min:71000 max:74000)

銅メッシュを設置する前より、温度はむしろ、上がっているかな。
音質はどうなのかというと、あんまりぱっとしない。良い方に変化した感じはしない。しかし、それより問題があって、なんだかサーバー自体が安定しない感じがするということだ。Daphileからのコントロールが不安定な感じ。
なにしろ、上手く行っていない。

温度が上がるのは良くない。
銅メッシュのサイズが大きすぎて冷却が上手くいっていないのかもしれないと考えて、メッシュの量を半分にして、やや小ぶりに、薄くした。細い針金を編んでいるので、切れ端から銅線がこぼれないように注意が必要だ（コンピューターに入れるので、切れ端が変なところに紛れ込んではまずいと思う）。

音はむしろ、そのほうが良いようだ。
硬い感じがとれて色彩感も出てきた。

温度を再計測。

音を出していないとき
47000 (min:47000 max:47000)

NAS音源
72375 (min:70000 max:75000)
71825 (min:67000 max:75000)
71571 (min:70000 max:74000)
71867 (min:64000 max:75000)

ストリーミング音源
71896 (min:69000 max:76000)
71328 (min:64000 max:74000)
72049 (min:69000 max:75000)
71961 (min:66000 max:75000)

温度は、あんまり、変わらない。
音はというと、それでも、どうにもすぐれない。
いくつか音源を聴くうちに、濁りがあるように感じられてきた。ベールのように霞みが掛かっている。そのせいか、見え方が違ってくる。遠くまでとどかないのだ。
副作用の方が強い。
銅メッシュを外す。
見通しの良い、以前の音が戻ってきた。

しかし、こうなってくると、テスト系の音も慎重に評価しないといけない。
何らかの歪みが、逆に心地良く聴こえているのかもしれない。GNDにものをつなぐときには注意が必要だ。しばしば反応は鋭敏でいいことばかりではない。
それにしても、2台の違いはどこから生じているのだろう。

ともあれ、しばらく、様子を見ていく。

現在のうちの環境では、Daphileでmpdサーバーに送るDeezerの音は、同じCD水準のデータでもNAS音源の音には及ばない。

前回のエントリーで、ストリーミング音源はupmpdcliがボトルネックになっていると考えたら、mpdサーバーへの対策が有効ではないか、銅メッシュをmpdサーバーのノイズ対策に使えば負荷が減るのではないか、と考えた。
ここでふと、mpdの負荷を減らしたいなら、アップサンプリングしなければいいんじゃないか、と思い付いた。

Daphileからmpdに送られるのは44.1kHz/16bitのPCMだ。それを何もせずPPAPで送れば、どう聴こえるだろう。
mpdサーバーの負担は減ると思う。
過去に試したときは、アップサンプリングした方が良かった。
今はどうだろう、ストリーミング、いや、UPnP音源だったら、どうなのか。

もともと、僕がアップサンプリングを使うようになったのは、コンピューターをオーディオに使い始めた頃に、SRC2496という機器を使ってアップコンバートして鳴らしていたことがある。これは音が良くなった。あと、壊れかけたNASの音源は、mpdによる非力なアップサンプリングでも音が良くなった。

こうしたことから、ジッターが多い環境では、アップサンプリングしたほうが音が良いのではないか、という仮説を思い付いた。なんでアップサンプリングで音が良くなるんだろう、というところから考え始めている。
つまり、そうした現実の理由付けとして考え始めた仮説だ。

そのうち、アップサンプリングと一言で言ってもいろんな手法があり、音も違うことが分かった。
手法で音が違うということは、DACに入力されるデータが異なっているということだ。
そして、DACチップ内でアップサンプリングするという知識も得る。

アップサンプリングによる音質改善の根拠は、DACチップ自体でアップサンプリング（オーバーサンプリング）するより、良質なアップサンプリングが出来る高スペックのPC等で代行したほうが良いという説明に、比重が移った。
というか、世の中でそういう説明が見られるようになった。
SRC（libsamplerate）などを使って良質なアップサンプリングを行うと音が良くなるのはなぜなのか、という問いの答えが、DACチップはナイキスト定理通りの理想的なDA変換が出来ないのでオーバーサンプリングして精度を高めるより他なく、DACへのデジタル入力前に、より良質なアップサンプリングを行うことが可能なら、そのほうがDA変換の精度が上がるから、ということに現在はなっている。
というのが僕の理解。

音の情報量自体はCDで充分だが、DA再生で充分な精度を出すには技術的限界があるから、理論だけで固めた理想論では済まない。だから高品質なアルゴリズムでアップサンプリングすることが有効ということだ。
精度が要らないなら、この限りではない。精度が出てなくても良い音はざらにある。精度が出ていさえすれば良いというものでもない。

そういうわけでアップサンプリングの品質は重要だと思うけど、ジッターを如何にして減らすかも同時に重要だ。
以前は、アップサンプリングすることでジッターの影響を少なく出来るのではと考えていたけど、今はそれだけで事足りるとは考えない。
ジッター対策は音色に効いてくる気がする。
というか、映画に例えてみると、サンプリング周波数やビット深度がフィルムの大きさ、つまり情報量に影響し、ジッター対策はピントに効いてくるとでもいうか、出てくる音の鮮度、色彩感、陰影に影響する。
両方を高めるのが、今のデジタルオーディオで高音質を得る近道だと思う。

正攻法は、安定して高精度なクロックだ。
しかしクロックを生かすには、ノイズや電源の対策が必須になる。ノイズや電源の上でクロック素子が動いているからだ。当然、デジタル信号そのものも、それらの上で動いている。デジタルで01だと言っても実体は電圧変動なのだから、ノイズや電源の影響を受けないわけがない。その影響こそがジッターということだ。

話が広がりすぎか。話を戻す。
何が言いたいのかというと、アップサンプリングを止めることで、音質は低下する。
しかしmpdサーバーの負担、仕事量が減るので、ジッターの減少、音質の向上に繋がるのではないか、ということ。

逆も言えることで、アップサンプリングを行えば音質は向上する。
しかしmpdサーバーの負担、仕事量が増えるので、ジッターの増加、音質の低下に繋がる。

では、どうすれば一番良い音になるのか、良好なバランスとなるのはどんな設定なのか、という考え方だ。
実際に聴いてみて、確かめるしか術はない。

さて。
うちでは2台のmpdサーバーが動いていて、1台はメイン使用で384kHzへのアップサンプリング用、もう1台はテスト用兼768kHzへのアップサンプリング用になっている。なんでわざわざ2台なのかというと、そのほうが設定切り替えの手間がないからだ。
PPAP Back-Endで両方の設定に対応するコマンドが動いていて、どちらのFrontからでも直ぐに音を出すことが出来る。
Back-Endでtopを打つとこんな感じ。

Mem: 93208K used, 3936688K free, 18376K shrd, 5560K buff, 34180K cached
CPU:  0.0% usr  0.0% sys  0.0% nic 99.9% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 0.00 0.00 0.00 2/109 1319
  PID  PPID USER 	STAT   VSZ %VSZ CPU %CPU COMMAND
 1318  1290 tc   	R 	4016  0.1   0  0.0 top
 1208  1092 root 	S	15484  0.3   0  0.0 /usr/local/bin/ncat -kl 4400 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=2048 --buffer-size=16384 -t raw -f S32_LE -r384000 -c2
 1242 	1 tc   	S	15484  0.3   1  0.0 /usr/local/bin/ncat -kl 4444 -e /usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=32768 -t raw -f S32_LE -r768000 -c2
 1286  1202 root 	S 	5872  0.1   0  0.0 sshd: tc [priv]

まず、テスト用サーバーの設定をいじって、アップサンプリング無しの音を出すことにした。
mpdサーバー（Front）をアップサンプリングしない設定に変更。
Back-Endでは、上記のtop表示だったら「kill 1242」で、テスト用のデータを受信するコマンドを止める。
改めて以下、コマンドを打つ。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=64 --buffer-size=512 -t raw -f cd" &

メインサーバーからのデータを受けるコマンドはrootで起動。テスト用サーバーからのはtc（ログインユーザー）で起動している。
コマンドは２つだが、aplay自体は、もともとひとつだ。

音源がCD同等だと、バッファーの数値はずっと小さくなる。音源データが小さいのでコマンドの設定もそれに合わせている。
しかしメイン用の方はもともと、大きい数値がバッファーに振られている。
多分、テスト用からの音源を鳴らしている時も、メイン用のコマンドが同時に動いているから、バッファーの設定がそっちのまま、大きいままなのではないか。
CD相等の音源にとって、それは過剰なバッファーとなる。
結果、操作に対する反応が遅くなる。mpdサーバーの出音を止めても、バッファーに溜まったデータが切れるまで、暫く音が出続けるのだろう。それが20秒前後にもなる。

どうするか。
そもそもの目的、サーバーの負荷を落とすということなら、アップサンプリングの「質」の設定を落とせばいいという考えもある。
テストサーバーのlibsamplerateの設定は「Medium」なので「Fastest」にしたら負荷は下がる。
そしてメインの384kHzに近い値で低めに設定したら、バッファー数値の影響は回避できないだろうか。
ままよ、やってみた。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=1024 --buffer-size=8192 -t raw -f S32_LE -r192000 -c2" &

これだと反応の遅れは数秒で、使用に耐える。
音色は良い。
768kHzよりも艶っぽい気がする。
しかし情報量は少なくなる。音像間で分離していた空間が、グラデーションで埋まる。まあ、768kHzと192kHzでは、デジタルデータの情報量は4倍の差があるので、仕方がない。768kHzは良くも悪くもモニター的になる。これは、どちらがいいのかという話になりそう。
テスト用といいながら僕が768kHzで鳴らす環境を維持しているのは、これはこれで捨てがたい面があるからだ。

しかし192kHzだと、USB-HDD音源とストリーミング音源の音の差は、かなり縮まったような気がする。
いや、ほんまかいな、と自分でも思うけど、たぶん縮まってるんじゃないかな（でも、こういうときの自分ってあてにならないんだよな、、）。
Fastest、192kHzの設定だけで比較したら、もうストリーミング中心でいいかもと思うかもしれない。

Back-Endで、メイン用の設定のほうを見直すという方法論もある。
大きいバッファーを小さく出来たら、テスト系への影響を小さく出来るのではないか。

そもそもなぜ、「--period-size=2048 --buffer-size=16384」という設定になっているのか、記憶にない。
たぶん、アップサンプリングするmpdサーバーの増大したバッファーの設定に、合わせて増やしただけだと思うのだ。
減らせるかもしれない。
とりあえず、「--period-size=512 --buffer-size=2048」まで減らした。
問題なく音は出ている。あらー、、、

この状態で、テスト系のアップサンプリングをやめて、まともに使えるかどうか、試してみる。
音の出方は、以前よりは良くなった。
しかし、不安定だ。途切れやすい。
mpdサーバーの方を調整。「audio_buffer_size」を増量、"2048"に。多少は安定したが、再生停止に10秒程かかる。
なんでかわからんが、mpdが音源データをどんどん先走って取り込んでいるようなのだ。Daphileなどのインターフェイスで見ると、曲の時間表示が実際よりもどんどん先に進んでいく。
これでは困る。

結局、多少はアップサンプリングしないと安定しないという、よくわからない状態で、今回はけりをつけることにした。
libsamplerateは「Fastest」、負荷軽減優先だ。
サンプリング周波数は、とりあえず192kHz。
テスト系を受けるBack-Endの設定は「--period-size=256 --buffer-size=2048」に、今はしている。
なんだか、あちこちバランス取りながらの設定で、詰めきれないままのことが今までにもよくあったような気がする。

気のせいかもしれないけど、Fastest、192kHzは、昔よりも良い音が出ている気がする。
ノイズ対策などを経て、ジッターが減っている分、改善があるのかもしれない。
USB-HDD音源とストリーミング音源の音の差も、Fastest、192kHzだったら前述したとおり、差異が少ない。なんとなく、バランスがいい音という印象で安心感がある気がする。

もともと、差異が少なければいいというものではない。
ストリーミングの音を底上げするにはどうしたらいいか、というところから始まった話だ。
しかしここに来て、設定による音の違いは無視できないような気がしている。ノイズ対策が落ち着いたら、どのような設定でどのような音になるのか、ゆっくり時間がある時に、確認したいと思うが、設定の要素が多いので、比較すると言っても単純な話ではない。
大仕事になる。あんまり突っ込んだことはしないかもしれない。

最後にちょっと、温度の比較（CPUだと思うんだけど、はっきりしない）。
テスト用サーバーでコマンドを打って確認してみた。

tc@box:~$ cat /sys/class/thermal/thermal_zone0/temp
44000

こんな感じ。
ただ、今回確認してみて、音を出している時の温度は、かなり変動することが分かった。負荷が多いときは上がるのだろう。

データ取得のために下記コマンドを使用。
5分間のデータを取得する。

tc@box:~$ watch -t -n 3 cat /sys/class/thermal/thermal_zone0/temp > temp.txt

数値だけ得られるならよかったんだけど、行頭に余計な文字列が付くのが残念。
このファイルを、普段使いのノートPCに移して、エディタで要らない文字列を削除して、下記のコマンドで数値を合計して、電卓で平均を計算する(小数点以下は四捨五入した)。
せっかくLinux使ってるんだから、もう少しスマートにやれそうだけど、スキルがない。

[ab@fedora1 Documents]$ awk '{sum+=$1}END{print sum}' temp.txt

44000

Fastest、192kHz
47267 (min:47000 max:48000)

Fastest、768kHz
53019 (min:47000 max:58000)

Medium、768kHz
59670 (min:51000 max:65000)

一番上は音を出していないとき、続いて、それぞれの設定で音を出したときの温度だ。
アップサンプリングの設定、負荷の違いで大きく温度が違うのが分かる。
驚いたのは、音を出していないときの温度は、ずっと44000で5分間一定だったこと。そういうものなんだろうか。あと、負荷が少ないと温度の変動も小さい。

メイン用サーバーは、Best、384kHzの設定で固定している。こっちも少し測ってみた。
データは載せないが、テスト用よりも若干温度が高いようだ。

早々に追記だけど、テスト用サーバー下記設定でデータを取ってみた。
アップサンプリングの周波数が低いと、温度の変動が少ないのかな。負荷の大きさとの関連は小さいのか。どうなんだろう。

Best、192kHz
58452 (min:57000 max:62000)

現在のpiCoreの状況がどうなってるのかと思って、確認したことを記録しておく。

なんで突然、piCoreなのかというと、ハードの違いで音が変わるということを思ううちに、そういえば以前はRaspberry Piで鳴らしていたっけと思い、そこから、今はどうなってるんだろうということになったということだ。
piCoreの最新は13になっている。
http://tinycorelinux.net/13.x/armv6/releases/RPi/

nmap.tczは、piCore9まで用意されていて、10はpiCore自体が欠番。11、12ではnmap.tczがリポジトリに用意されていなかった。
しかし現在、piCore13ではnmap.tczがリポジトリに用意されている。ということは、piCore9以前か13だったら簡単にPPAP Back Endを作れるということだ。
http://tinycorelinux.net/13.x/armv6/tcz/

ちなみに、mpd.tczが用意されているのはpiCore7まで。
libmpdclient.tczはpiCore9までだ。
一方、Tiny Coreはというと、Tiny Core x86（32bit版OS）のリポジトリにはmpd-minimal.tcz、libmpdclient.tczが昔から今までずっと用意されている。つまり、実は手軽にmpdを扱うにはこれが一番簡単だ。nmap.tczもあるが、mpd-minimalでpipeが使えるかは確認していない。
http://tinycorelinux.net/13.x/x86/

64bit OSであるx86_64のリポジトリには、mpdが無い。
ソースをダウンロードしてインストールする必要がある。

一方、alsaはというと、piCore11からversion 1.2.2になって、音源のサンプリング周波数が768kHzまで通るようになっている。
piCore9だと、alsaはversion 1.1.1。音源が198kHzまでで良ければ、piCore9以前のバージョンでよくて、300kHz以上なら11以降が必要ということになる。
参考：
Changelog between 1.1.9 and 1.2.1 releases / Alsa Project News
https://www.alsa-project.org/wiki/Changes_v1.1.9_v1.2.1

現在、うちでは768kHz/32bitでPPAP方式を使っていて、Back Endで使っているのはTiny Core Pure 64 v11.0。ハードはapu2だ。
piCore13ならば、768kHzが使えるPPAP Back Endに出来る筈、、、
しかし問題は、Raspberry PiはUSBとLANが同じチップで処理されているんだったかな。Ras Pi4とか、新しいハードだと改善されたらしい？けど、うちに残っているB+とか2とかだと、大量のデータを送るのは、うまくいかない可能性がある。というか、B+とか2とか非力なハードで、768kHz/32bitなんて重い音声データを扱えるんだろうか。

しかしRaspberry Pi とpiCoreでPPAP Back End、apu2と比較できるならしてみたいかな。

せっかくなので、まずはRaspberry Pi B+で試してみる。
以下、工程と設定のメモ。

download
http://tinycorelinux.net/13.x/armv6/releases/RPi/piCore-13.1.0.zip

cmdline.txt add
host=pC131bp

config.txt rewrite
dtparam=audio=off

login
ssh tc@192.168.1.xxx

sudo fdisk -u /dev/mmcblk0
p
d
2
n
p
2
(write number - /dev/mmcblk0p2 / start)
+100M
w

filetool.sh -b
sudo reboot

login
ssh tc@192.168.1.xxx

sudo resize2fs /dev/mmcblk0p2

tce-load -wi nmap.tcz alsa-modules-5.10.77-piCore.tcz alsa.tcz alsa-utils.tcz

vi /opt/bootlocal.sh
/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=16384 -t raw -f S32_LE -r768000 -c2"

vi /opt/eth0.sh
#!/bin/sh
pkill udhcpc
ifconfig eth0 192.168.10.10 netmask 255.255.255.0 broadcast 192.168.10.255 up
route add default gw 192.168.10.1
# echo nameserver 192.168.10.1 > /etc/resolv.conf

chmod +x /opt/eth0.sh

sudo vi /opt/bootsync.sh
/opt/eth0.sh &

filetool.sh -b
sudo reboot

工程終了。
PPAP Middle Endにつないで起動。
Middle Endからsshでログインして、下記コマンドにてUSB DACの認識を確認する。

cat /proc/asound/card0/stream0

音を出してみる。
音は出た。しかし、ノイズだらけで、音楽を聴くというわけにはいかなかった。

Ras Pi2ではどうなのか。

download
http://tinycorelinux.net/13.x/armv7/releases/RPi/piCore-13.1.0.zip

cmdline.txt add
host=pC131b2

tce-load -wi nmap.tcz alsa-modules-5.10.77-piCore-v7.tcz alsa.tcz alsa-utils.tcz

上記以外の工程は同じ。
音は出た。やはりノイズだらけだが、音楽は聞き取れる。音程は正しいのに再生速度が遅い。これでは使えない。

PPAP Front Endでのアップサンプリングを止める。
Back Endの設定も合わせる。

/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=64 --buffer-size=512 -t raw -f cd"

これでどうか。
まともな音が出る、けど、、、操作へのレスポンスが遅い。
こんなに遅かったっけ、そういえば遅かったかな、、と思うぐらい遅い。
普段、Daphileとmpdで768kHzにアップして聴いてるのと比べても、なんだか遅い気がする。普段使っているシステムは、再生開始の操作をして音が出るまで数秒かかるけど、ボリューム調整への反応は遅くない。それが、Ras Piだと両方とも遅く感じる。 apu2よりもRas Piのほうが遅いハードだからだろうか。
しかし、DaphileとpiCorePlayerの組み合わせだと、そんなに遅く感じない。
もしかしたらLMSやUPnPは、ユーザーがレスポンスが遅いと感じないように作られているのかもしれない。

あれこれ弄るうちに、Daphileシステムの方も不調になってきた。原因不明、、、全システムをリブート。
システム全体の不調が影響したせいかどうか分からないが、音質も敢えてRas Piで聴きたいと思わせるものがない。

今回はここらで撤退することにした。
残念だが致し方なし。

LANの直結を今まで試みていなかったのは、利便性が低下することと、色々やりかたを調べるのが面倒だったからだ、、、
しかし、やり残していることなのでやることにした。

さて、、、先立っての試験運用を何を使ってやるか。
LAN端子を2つ以上持っている機械は、うちにはapu2以外にない。メインシステムで試すしかないということだ。
トラブルがあっては面倒なので、apu2のSDカードをバックアップしておく必要があるかな、、、
普段からバックアップを取ってないのかといわれたら、どれがバックアップなのか分からなくなっているのだ。何をやってるのかまったく分からない。

そんなことを考えていたら、そういえば暫く前にBack EndのイメージをGoogleにアップしてたっけ、と思い出した。
あれを落としてきて試せばいいんじゃないの。
tc64-11-1-base1z-2020-04-05-PPAP-BE.img
https://drive.google.com/file/d/1kHhCtR4WCWs3_8i32JrVgGFin-YK9KIZ/view?usp=sharing
そういうわけで、ダウンロード。
カードに焼く。

物理的に遠くに離してあったMIddle EndをBack Endの近くに戻す。
まず状況。

   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)           www.tinycorelinux.net

tc@box:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:40  
          inet addr:192.168.1.33  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42922414 errors:0 dropped:2894 overruns:0 frame:0
          TX packets:43024988 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:62288871488 (58.0 GiB)  TX bytes:62314222899 (58.0 GiB)
          Memory:fe600000-fe61ffff 

eth1      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:41  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe700000-fe71ffff 

eth2      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:42  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe800000-fe81ffff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$ 

現在、IP固定の設定はしていない。DHCPサーバーからeth0にアドレスを取得している。
今回はeth1のIPを固定してみる。

ところで、どれが0でどれが2だったかいつも分からなくなるので写真を貼っておく。
シリアルケーブル端子に近い方が0である。

IP固定は昔、piCoreを使っていた頃はよく設定していた。
だけど、最近はしていないのですっかり忘れている。というか、Tiny CoreでのIP固定はしたことがない。
複数のイーサネットポートを扱うのも初めてだ。
どうなんだろ、piCoreみたく/optにeth1.shを作って置いといたらいいのかな、、、

Middle End の電源を落として、ケースの蓋を開ける。
SDカードを入れ替えて、起動する。
以下、sshでログインしてからの経過。

vi /opt/eth1.sh

#!/bin/sh
pkill udhcpc
ifconfig eth1 192.168.10.2 netmask 255.255.255.0 broadcast 192.168.10.255 up
route add default gw 192.168.10.1
# echo nameserver 192.168.10.1 > /etc/resolv.conf

chmod +x /opt/eth1.sh

sudo vi /opt/bootsync.sh

#!/bin/sh
# put other system startup commands here, the boot process will wait until they complete.
# Use bootlocal.sh for system startup commands that can run in the background
# and therefore not slow down the boot process.
/usr/bin/sethostname box
/opt/bootlocal.sh &
/opt/eth1.sh &

filetool.sh -b
sudo reboot

viでeth1の設定ファイル「eth1.sh」を作成。IPを192.168.10.2で固定する。nameserverの記述は要らないのではないかと思ったのでコメント化した。
chmodで実行権限を与える。
bootsync.shファイルに「/opt/eth1.sh &」を書き加える。
filetool.sh -bで保存し、リブート。

リブート後、sshでログイン。

tc@box:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:40  
          inet addr:192.168.1.33  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:562 errors:0 dropped:28 overruns:0 frame:0
          TX packets:246 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:52631 (51.3 KiB)  TX bytes:35785 (34.9 KiB)
          Memory:fe600000-fe61ffff 

eth1      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:41  
          inet addr:192.168.10.2  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe700000-fe71ffff 

eth2      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:42  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe800000-fe81ffff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$ 

eth1に「192.168.10.2」が振られている。
次はこれをMiddle Endにしていく。
過去エントリーを参考。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20210824a.htm
PPAP Back-Endをタンデム化

sudo vi /opt/bootlocal.sh

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

filetool.sh -b
sudo reboot

bootlocal.shファイルに上記のようにコマンド記載。Back EndのIPを「192.168.10.10」とする。
これで動くのかな、、、
合わせて、Back Endのほうも設定し直していくということになる。

Back Endのほうは、イメージを焼くのは飛ばしてsshにログインして設定した。
Middle Endでの試行でIP固定の設定ぐらいまでは出来そうな目星は付いたので。
（6月8日、下記の書き間違いを修正した）

vi /opt/eth1.sh

#!/bin/sh
pkill udhcpc
ifconfig eth1 192.168.10.10 netmask 255.255.255.0 broadcast 192.168.10.255 up
route add default gw 192.168.10.1
# echo nameserver 192.168.10.1 > /etc/resolv.conf

chmod +x /opt/eth1.sh

sudo vi /opt/bootsync.sh

#!/bin/sh
# put other system startup commands here, the boot process will wait until they complete.
# Use bootlocal.sh for system startup commands that can run in the background
# and therefore not slow down the boot process.
/usr/bin/sethostname box
/opt/bootlocal.sh &
/opt/eth1.sh &

filetool.sh -b
sudo reboot

Middle Endと同じ手法で、eth1の設定を行っていく。
filetool.sh -bで保存し、リブート。

リブート後、sshでログイン。

tc@box:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0D:B9:50:86:58  
          inet addr:192.168.1.89  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:44 errors:0 dropped:0 overruns:0 frame:0
          TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6283 (6.1 KiB)  TX bytes:5919 (5.7 KiB)
          Memory:fe600000-fe61ffff 

eth1      Link encap:Ethernet  HWaddr 00:0D:B9:50:86:59  
          inet addr:192.168.10.10  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe700000-fe71ffff 

eth2      Link encap:Ethernet  HWaddr 00:0D:B9:50:86:5A  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe800000-fe81ffff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$ 

eth1に「192.168.10.10」が振られている。

さて、直結で機能するかどうか。
Back Endのeth0からLANケーブルを抜く。
MiddleとBackのeth1端子をLANケーブルでつなぎ、Midlle EndからsshでBack Endにログインしてみる。

tc@box:~$ ssh tc@192.168.10.10
The authenticity of host '192.168.10.10 (192.168.10.10)' can't be established.
ECDSA key fingerprint is SHA256:eICMkwr/u6JIomP1WNI9YocJTnDxmI8M7ICHoj/oeEY.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.10.10' (ECDSA) to the list of known hosts.
tc@192.168.10.10's password: 
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)           www.tinycorelinux.net

tc@box:~$ 

いけました、、、
次、ncmpcppからFrontのmpdに音楽再生の指示を出してみる、、、音は出ました！

はあ、、やってみたら簡単なものである。
もとのつなぎ方と直結、両者の違いを図にしてみた。

音質はどうか。
例えばベールが1枚はがれたようなとか、、薄皮1枚のベール？、、
前とあんまり変わらないような。
正直、違いが分からない、、、どうなんだろう。
まあ、耳が悪いということなのかもしれない、、、

まあ、でも、せっかく設定したのだし、暫くはこれで使っていこうと思う。
暫く使った後で戻したら、こんなに違うんだっけ！ということもあるかもしれないし。

pkill udhcpc
sudo ifconfig eth0 down

pkill udhcpc
sudo ifconfig eth2 down

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

• 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を何処に設置するのがいいかの検討が残っている。追々やる。

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

先日アップしたイメージを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

前回に引き続き、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じゃないと出ない音が出ている。
運用しながら調整していきたい。

まずはちょっとしたメモから。

前回エントリーで出て来たコマンド「cat /proc/asound/card0/stream0」なんだけど。
ふだんpiCore7とi2s DACでusbメモリの音源を鳴らしているシステムで、試しに打ってみた結果が以下。

tc@box:~$ cat /proc/asound/card0/stream0
cat: can't open '/proc/asound/card0/stream0': No such file or directory
tc@box:~$

No such file or directory、、、
usb出力だとusb DACのデータが表示されたけど、i2s出力だとそれがない。考えてみたら、i2sだと出力先デバイスを特定するデータを扱う必要がないのだろう。
出力自体のデータは、下記のように確認できる。.mpdconfの設定は24/96だ。

tc@box:~$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 12000
buffer_size: 48000
tc@box:~$

2年前のエントリーで、USB出力は48kHzにリサンプリングされるがi2s出力はされずに設定どおりに出力されるようだ、という記載がある。出力先が何なのかを気にしないのだから、48kHzにリサンプリングする理由がない。
つまり今更だけど、i2s出力とUSB出力はalsaの動き方が違うということだ。

ここで、.mpdconfのaudio_output_format設定を変えて、出力のファイルフォーマットがどうなるかを確認してみた。
「96000:24:2」のとき出力はS24_LE、「44100:16:2」のときS16_LE、「192:32:2」のときS32_LEになった。
audio_output_formatをコメントアウトしたら、出力は44100でS24_LE。あれ？っと思ったけど、よく考えたら、このシステムではmp3を再生していたんだった。CDリッピングのflacデータを再生したら、S16_LEになった。
mp3って、S24_LEになるのかね、、、いろいろ謎がある。

前回エントリーの話では、「-D hw:0,0」を設定したらファイルフォーマットを厳密に設定しないといけないけど、「-D plughw:0,0」は緩いのではないか？ということだった。
今回は、実際のところどうなのか、やってみようということだ。
うちでは珍しくもないけど、長々だらだらとしたエントリーになった。

テスト用環境として、Raspberry Piを2台使って、usb出力のPPAP環境を作る。
Frontに、Ras pi2、mpd 0.19.19、libsamplerateを使用。
Back-endに、Ras piB+。
OSはともにpiCore7。
USB DACはいくつか手持ちがあるけど、何を使うか、、、ちょっと古いが、取り敢えずRATOCのRAL-2496ut1を使うことにした。
これにオーディオテクニカのAT-SP150 bkというデスクトップ用のパワードスピーカーをつないで出力した。
ファイルフォーマットやBack-Endのコマンドを変えながら、音が出るかどうかのデータをとってみる。

Back-endのRas piB+にsshでログインし確認すると以下の通り。

tc@box:~$ cat /proc/asound/card0/stream0
RATOC Systems,Inc. RAL-2496UT1 USB-Transport at usb-20980000.usb-1.4, full spee : USB Audio

Playback:
  Status: Stop
  Interface 1
    Altset 1
    Format: S16_LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000
  Interface 1
    Altset 2
    Format: S24_3LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000
tc@box:~$

ほほう、、、面白い。
ADI-2 DACなんかS32_LEしか出ないのに。S16_LEとS24_3LEが表示されている。

Frontの.mpdconfはこんな感じ。

samplerate_converter "Fastest Sinc Interpolator"
audio_buffer_size "8192"
buffer_before_play "20%"
audio_output_format "192000:32:2"

audio_output {
type "pipe"
name "ppappipe"
always_on "yes"
command "/usr/local/bin/ncat 192.168.1.18 4444"
}

2496ut1は24/96までのDACなので、192/32はオーバースペックだ。
しかし、ここでBack-endのコマンドを下記のように設定。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=512 --buffer-size=4096 -t raw -f S24_LE -r192000 -c2"

音を出してみる。
Back-endの出力はこんな感じに。

tc@box:~$ cat /proc/asound/card*/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 256
buffer_size: 2048
tc@box:~$

音はちゃんと出ている。
Frontの設定「192/32」が、「24/96」にリサンプリングされている。Back-endの「-f S24_LE -r192000」という設定も、どこにいったのかという感じ。 ちなみにBack-endの構成はこんな感じ。

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   391.1M      9.4M    381.6M   2% /
tmpfs                   217.3M         0    217.3M   0% /dev/shm
/dev/mmcblk0p2           43.7M     13.1M     28.2M  32% /mnt/mmcblk0p2
/dev/loop0                1.1M      1.1M         0 100% /tmp/tcloop/mc
/dev/loop1                1.9M      1.9M         0 100% /tmp/tcloop/openssh
/dev/loop2                4.9M      4.9M         0 100% /tmp/tcloop/nmap
/dev/loop3              768.0K    768.0K         0 100% /tmp/tcloop/alsa-modules-4.1.13-piCore+
/dev/loop4              256.0K    256.0K         0 100% /tmp/tcloop/alsa
/dev/loop5                1.1M      1.1M         0 100% /tmp/tcloop/glib2
/dev/loop6               68.0K     68.0K         0 100% /tmp/tcloop/libssh2
/dev/loop7              256.0K    256.0K         0 100% /tmp/tcloop/ncurses
/dev/loop8                1.5M      1.5M         0 100% /tmp/tcloop/openssl
/dev/loop9              292.0K    292.0K         0 100% /tmp/tcloop/libnl
/dev/loop10             128.0K    128.0K         0 100% /tmp/tcloop/libpcap
/dev/loop11             128.0K    128.0K         0 100% /tmp/tcloop/lua-lib
/dev/loop12             384.0K    384.0K         0 100% /tmp/tcloop/libasound
/dev/loop13              28.0K     28.0K         0 100% /tmp/tcloop/gamin
/dev/loop14              36.0K     36.0K         0 100% /tmp/tcloop/libelf
/dev/loop15             256.0K    256.0K         0 100% /tmp/tcloop/pcre
/dev/loop16             384.0K    384.0K         0 100% /tmp/tcloop/libgcrypt
/dev/loop17             128.0K    128.0K         0 100% /tmp/tcloop/libusb
/dev/loop18              36.0K     36.0K         0 100% /tmp/tcloop/bzip2-lib
/dev/loop19             128.0K    128.0K         0 100% /tmp/tcloop/libgpg-error
/dev/loop20             128.0K    128.0K         0 100% /tmp/tcloop/libudev
tc@box:~$

alsa.tcz、alsa-modules-4.1.13-piCore+.tcz、libasound.tczだけで、リサンプリングしてるんだろうか？
まあ、ダウンサンプリングに関してはひとつ飛ばしするだけでいいっちゃいいもんなあ、、、
フォーマットはS32_LEだった？のが、S24_3LEに変換されているけど、これってRas piB+的に簡単なのだろうか、、、

設定を変えてみる。
Back-endのコマンドのオプション設定が「-D plughw:0,0」だったのを「-D hw:0,0」に。
さらに「-f S24_3LE -r96000」、つまり2496ut1で使えるはずの設定記載にする。

Back-end :
/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=512 --buffer-size=4096 -t raw -f S24_3LE -r96000 -c2"

Front :
samplerate_converter "Fastest Sinc Interpolator"
audio_buffer_size "8192"
buffer_before_play "20%"
audio_output_format "96000:24:2"

audio_output {
type "pipe"
name "ppappipe"
always_on "yes"
command "/usr/local/bin/ncat 192.168.1.18 4444"
}

音は出た、、、盛大なホワイトノイズが。はっきりしないけど、S24_3LEがいけないのではと思う。
S24_3LEをS24_LEにしたら、「Paused」で音が出ない。
そういうことなんだね。
じゃあ、もうひとつの使えるはずの設定「S16_LE」にしてみる。

Back-end :
/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=512 --buffer-size=4096 -t raw -f S16_LE -r96000 -c2"

Front :
samplerate_converter "Fastest Sinc Interpolator"
audio_buffer_size "8192"
buffer_before_play "20%"
audio_output_format "96000:16:2"

audio_output {
type "pipe"
name "ppappipe"
always_on "yes"
command "/usr/local/bin/ncat 192.168.1.18 4444"
}

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

mpdは動いている。Back-endも信号を受け入れているようだ、、、でも、音が出ない。、、、
じゃあ、、、ここで「-D hw:0,0」だったのを「-D plughw:0,0」に変えてみるか、、、同じ、、、いや、、、出てる？音量が小さい、、、
設定を「-D hw:0,0」に戻す。
ボリュームを上げると、普通に音が出ていたのが分かった。音量が大きく違ったのだ。
S16_LEだと音量が下がるのか？、いや、、、むしろこっちのほうが適正な音量だ。先刻、鳴っていた音量が大き過ぎたのだ。

これは、一筋縄には行かないな、、、

こんな感じでだらだらやってても大変だ。データを取るのに変数は、、、

1) Front : .mpdconf / audio_output_format (44100, 48000, 88200, 96000, 19200 : 16, 24, 32)
2) Back-end : aplay -D (hw:0,0 or plughw:0,0)
3) Back-end : aplay -f (S16_LE, S24_3LE, S24_LE, S32_LE)
4) Back-end : aplay -r (44100, 48000, 88200, 96000, 19200)

変数が4つもある、、、
1)は、44100, 96000, 19200 : 16, 24, 32、ぐらい？
2)aplay -Dオプションは、hwとplughw。
3)はS16_LE、S24_3LE、S24_LE、4)は44100, 96000, 19200ぐらいに絞ろうか、、、
総当たりでやったら、162とおりの組み合わせ。、、、やって出来ないこともないけど、なかなか終わりそうにないな。

さらに絞る。
1)は、44100, 96000 : 16, 24。
2)aplay -Dオプションは、hwとplughw。
3)はS16_LE、S24_LE、4)は44100, 96000。1)の設定に数値を合わせる。
これで、8とおり。
削り過ぎか？、もうちょっと、他の設定もしてみようか、、、以下、結果。

こんなところかなあ、、、、
やはり、aplay -Dオプションで「hw:0,0」を設定すると、ファイルフォーマットをきちんと合わせないと音が出ない。
2496ut1の場合、24bitのフォーマットの扱いが難しい。
Back-endで「S24_3LE」と設定したら、正確な設定のはずなのに、ノイズで音声が聞けなくなる。むしろ「S24_LE」に設定した方が、「plughw」で問題なく音声を鳴らせる分、随分ましだということになる。これは10年ほど前にも問題視されていた事らしくて、alsaはS24_3LEを扱えないという話がネット上に残っているようだ。最近の機械はS32_LEをサポートしている機種がほとんどのようで、こうした問題はなくなったらしい。

入力が176.4kHzや192kHzのフォーマットでも、plughwで設定したら音を出すことができるのには、正直驚いた。
ただ、ダウンサンプリングされてしまうけど。
といっても、dmixがインストールされていないからだと思うけど、48kHzにはならない。
176.4kHzは2分の1の88.2kHzになるのかと思ったら、96kHzにダウンサンプリングされた。そのせいかどうか分からないけど、高音がきつくうるさい感じに聴こえた。同じダウンサンプリングされるのでも、192kHzからのほうが聴きやすく自然な感触に感じた。192/32で音が大きくなるのは、理由がわからない。

本当は、S32_LEをサポートしている新しいDACだとどうなのか、確認したほうがいいんだろうけど、息切れ気味。
このぐらいにしておこうと思う。

768kHzのPPAPで聴き始めて1ヶ月程。
前回のエントリーで戻れないだろうと書いて、やはりその通りになっている。
音源の音楽的な情報を今まで以上に引き出していると思う。より生々しく、色彩、陰影豊かにという感じ。

ただ、この聴き方だとうまくいかない音源が散見される。
クラシック系や録音が良いとされている音源はたいてい問題なく、768kHzでより良く鳴ることが多い。
しかし、ポップミュージック系は録音の良し悪しの幅が大きく、良くないものは一層の違和感を生じるようになった。

以前にエントリーに上げていたボーカルの違和感というのではない。それはむしろ減っている。
それよりも、作品の音質全体がなんだか上手くいっていないというか、粗が目立つというか、聴き続けるのが苦痛になる。高域がきついとかノイズっぽいとか聴き疲れするとか、そういうのではなく、ただただ録音が悪いというのがはっきり分かっていやになる感じ。
そこまでひどいのは、そんなに多くはないのだけど。

精緻なオーディオ再生はもとから考えていないだろうなという音源の一部は、768kHzで聴かないほうがいい。
いっそのことと思って、そういう音源は768kHz以下の周波数、例えば192kHzでの再生を試みている。
そのぐらいに落としたら、違和感なく聴ける音源も増えてくる。

方法は、下図の通り。
うちのシステムの上流は最近はこんな感じだ。

上にBack-endのapu2d4。
中央に2つのFront。1つはapu2c4、もう1つは新たに入手したHP Elitebook 2570p。
下に、mpdクライアントncmpcppを動かすHP compaq 6730b。

Back-endのapu2d4には2組のncat/aplayeraplayが動いていて、異なるサンプリング周波数、ビット深度を担当している。
異なるポートをあてがうことで、こういうことが可能になる。
ともに出力はusbで1つのDACに継いでいるので、同時に音出ししたらどうなるのかということはあるのだけど、怖くて試していない。
その点で注意は必要だが、Back-endの設定変更の手間をかける必要なく入出力を変更できるのは便利だし、スピーディに変更できるので音質の比較も容易になる。
コマンドが1つか2つかで音質の変化があるかどうかは、僕には聴き分けられなかった。

Front 1は以前から使っているapu2c4。
ずっと705.6kHzへのアップサンプリングで使ってきたんだけど（768kHzは限界を超える）、より高スペックのPCから出力する768kHzのほうが1割方、音がいい。そこで、低めのサンプリング周波数でのPPAPに対応してもらうことにした。今のところ192kHz/24bitだが、どのあたりが塩梅がいいか、追々検討していくつもり。

apu2c4の使用法を変更するにあたって、mpd.confの設定に多少戸惑った。
というのは、192kHzや96kHzで音を出すと、なぜか音が途切れるのだ。
アップサンプリングの負担は少ないはずなのに、、、以前使っていた時、どうだったっけ？
あれこれ試行錯誤したところ、どうもPPAP Frontには「buffer_before_play」を奢ってやる必要がある事が分かってきた。
この数値が足りないと、音切れが起きやすかったりクライアントからの操作への追随が遅れたりと、問題が起きる。
しかし、以前は気付かなかった。
もしかしたら、使用するハードによって何か違ってくるのかもしれない。分からないけど。

Front 2のHP Elitebook 2570pは中古で新規購入した。
HP ProBook 650 G1を使っていたんだけど、サイズが大きめなのと、将来的に子供がwindows10で使う役割が急にできてしまった。
どうしたものかと迷ったんだけど、結局、HPのノートにした。
まずモニターが付いていて折りたためること。1ボードPCで必要に応じて外部モニターやシリアル接続というのもあるけど、bios確認するのにいちいちモニターとか面倒だ。最終的にノートにすることにした。音質への影響は、多分それでも十分だろうと割り切った。
650 G1よりもう少し小型で、メモリの速度が十分で、というわけで、中古で1万3千円強だった2570pにした。たぶんwindows7でHDDにリカバリ領域がないから安かったのではないか。usb起動で使うのでHDDは外してしまった。こういう対応がしやすいのもこの機種を選んだ理由。
usbメモリにtiny core pure64 11.1で起動して、mpd 0.20.20をインストールしてFront化した。
768kHz/32bitを問題なく再生出来ている。
しかし、少し音が硬いんだな、、、
サイズが小さい割に3kgもあって、それで凝集した感じの音になってるのか？と思ったけど、徐々にほぐれつつある気がする。
あと、メモリが4GBと650 G1よりも少ない。これは追々、増やしてみようと思う。

tc@box:~$ 768
Playing raw data 'stdin' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo
Playing raw data 'stdin' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo
underrun!!! (at least 6168.253 ms long)
Playing raw data 'stdin' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo
Playing raw data 'stdin' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo
^C

クライアントは普段使いのHP Compaq 6730bで、ncmpcppでFrontのmpdにアクセスし操作している。
図の通りなんだけど、アカウントを複数使うことで、設定が異なる複数のncmpcppを同時に運用できる。ターミナルソフトのウインドウが多くなると紛らわしいので、ワークスペースの切り替えで対応している（ワークスペースというのはlinuxの機能で、切り替えが効くデスクトップみたいなものだ）。

将来的には、2つのFrontを1つにまとめていくことも考えている。
つまり、Frontにアカウントを追加して、個々のアカウントでmpdを動かせば、1つのPCで複数のmpdを動かす事ができるということだ。
クライアントへのポートは6600がデフォルトだけど、他の使われていない数字を充てることもできるので、1つのPCで、複数のクライアント、複数のmpdを動かすことができるのではないか(つまり、過去のエントリー http://blown-lei.net/endive/blosxom.cgi/audio_diary/20161231a.htm に記載したようなことをやる)。
まあ、先の話だけど。

新型コロナウイルスが、日本中、世界中で僕達の生活を脅かしている。こんなことはSF小説で読んだ事があるばかりで、現代社会で実際に起きるという気構えは全くしていなかった。そして、ここまで政府が無能だということも、、、いや、無能というよりも怠惰で非情ということだ。予想してなかったとは言わないが、もう少しマシであって欲しかった。
それでも、この現実に向き合い、対処しないといけない。
協力できる人と協力し、できることを行い、1人でも多くの無事を祈るばかりだ。

とにかく、みなさま、御自愛の程を。

piCore7でppap (piped pcm audio play)を試みる
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180301a.htm

上記のエントリーをあげたのがほぼ2年前。
当時のハードはraspberry pi2。aplayの仕様で192kHzまでが限界だった。
その後、PPAPはやめて、384kHz、更にapu2による700kHz台でのアップサンプリング再生に移行していた。

新しいバージョンのalsaを使える環境なら700kHz台でのPPAPは可能だろうと思っていたんだけど、手頃な環境がなかなか無かったので、機が熟すのを待っていた。
最近、tiny core pure64 11.0で、aplay: version 1.2.1、nmap.tczも用意されたので、やってみた。
簡単にPPAP back-endとして機能した。
でも700kHz台になると、安定して鳴らすには設定に気を使う感じだ。

まず、普段からmpd + libsamplerateで700kHzへのアップサンプリング再生に使っていたapu2c4のtiny core pure64 7.2の設定。というか、これは以前にnmap、ncatをインストールしてそのままなんだけど、そのときは動くことを確認しただけで、その後は使っていなかった。mpdも、そのときにpipe出力を使える形でインストールしていた。
今回、いよいよ本格的に使うことになる。

mpd.confに「pipe」出力の設定を書き込み、alsaの設定はコメントアウト。
これでmpdを再起動したら、PPAP Frontとして機能する。
OSのバージョンが古くて7.2、mpdは0.19.19のままなんだけど、それでも十分使える。というか、それ以外のバージョンは新しいのも含めて試していない。

audio_output {
type "pipe"
name "ppappipe"
always_on "yes"
command "/usr/local/bin/ncat 192.168.1.89 4444"
}

# audio_output_format             "768000:32:2"
audio_output_format             "705600:32:2"

audio_buffer_size "65536"
buffer_before_play "50%"

多少試した結果、現状は上記の設定。
「command」の行には、PPAP back-endのipアドレスが書いてある。
最初は、apu1台でNASマウントアップサンプリング再生するよりもalsaが働かない分、負担が少ないのかと思った。聴きやすいスムーズな音が出てきたので、そんなふうに思ったのだ。しかし、再生時間が長くなってくると音切れ、ノイズが生じ始めた。こうなるとスムーズじゃない感じ。
結局、以前の設定、1台のapu2で音切れなく700kHz台の再生ができていたときと同じに戻して様子を見ている。これが安定しているのかなあ、、、

次に、back-end。
まず、tiny core pure64 11.0をSDカードに書き込む。
基本的に以前のエントリー（apu2で、Tiny CorePure64-10.1にmpd（0.20、0.21）をインストールする（その1：準備） http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027a.htm）に書いた通りにやればいいんだけど、CorePlus-current.isoのバージョンによっては、opensshをインストールしただけじゃsshを起動できないんだね。sshd_config.origをコピー複製してsshd_configを作る操作が必要。

SDカードにOSの書き込みができたらapuに差し込む。うちではapu2d4を使っている。
起動したらsshクライアントpcからログイン。
「tce」で、alsa-tcz、alsa-modules-5.4.3-tinycore64.tcz、nmap.tczをインストール。
usbケーブルで、テスト用に使っているSMSL m100をつなぐと、すんなり認識する。

**** List of PLAYBACK Hardware Devices ****
card 0: v10 [SMSL M100 v1.0], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
tc@box:~$ 

back-end化できるかどうかテストするために下記のコマンドを打った後、Frontのmpdで音楽を鳴らしてみる。

tc@box:~$ /usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=4096 --buffer-size=32768 -t raw -f S32_LE -r768000 -c2"
Playing raw data 'stdin' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo

768kHz/32bitで再生している。
実際にはいきなり768kHzではなく、192kHzから試して、段々サンプリング周波数などを上げていった。
period-size=1024だと、聴感上ははっきりしないけど「underrun!!! (at least 895.331 ms long)」といったようなエラーが出ていた。
2048、4096との設定だと、見られなくなった、かな。

さて、sshクライアントpcを、起動しっぱなしにして放置しておくわけにもいかないだろう。
sshでログインしているターミナルのウインドウを閉じたら、PPAP再生が止まってしまう。ターミナルからコマンドを打っているので、ターミナルを閉じたらコマンドも閉じる、ということかな。
これでは不便なので、apu2の電源投入、OS起動時に自動的にコマンドを読み込むようにする。
「bootlocal.sh」に、「/usr/local/bin/ncat -kl 4444 -e （以下略）」のコマンドを追記。filetool.sh -bで設定を保存。
これでOSを再起動したら、back-endとして機能する。

sudo vi /opt/bootlocal.sh

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=2048 --buffer-size=32768 -t raw -f S32_LE -r705600 -c2"

filetool.sh -b
sudo reboot

あれこれ試して、今はこんな感じの設定。
どうも768kHzだと音切れがある。apu2を1台で鳴らしていた時よりも音切れしやすい？
はっきりしないけど、ハード的なボトルネックがあるような気がするんだけど、気がするだけで特定できていない。

音質は、、、まだ微妙。
まだ、安定した再生ができているか十分に確認できているわけでもない。
しかし、そこを差し引いても音色の色彩、表情は以前より向上している。実在感、安定感も増している。

96kHzや192kHzで聴いていた頃は、PPAP方式で大きな音質向上があった。そのときと比べたら大きな向上とは言えない。明らかに激変する！という感じじゃないのだ。
しかし、なんというか、戻れないのではないかという感触はある。
微細な表情はPPAPのほうが確かに上で、慣れてしまったら、意外に大きな差異に感じるのではないかと思える。

しかし、音質の向上というのは、どこまで行くのだろうか。限界はないのだろうか。
つい先日アップしたばかりだけど、現状のシステム構成図をアップしておく

前回のエントリーから早2ヶ月になる。
ケーブルインシュレーターは、前回以降、電源タップの電源ケーブルの接続部位と、アンプの電源ケーブルの接続部位にも使用している。心持ち緩かったのが、かなり頑丈に保持されるようになって、音もしっかりした。
思った以上に効いている。

最近は、apu2c4、tiny CorePure64-7.2、mpd + libsamlerateで、705.6kHzへのアップサンプリングで聴いている。

課題はないこともない。700kHz台でのPPAPだ。
しかし、これがなかなか、試すというとこまでいかない。
aplayのバージョンが1.1.7以上である必要がある。
というか、そういう条件を満たせば出来るんじゃないかと思っているんだけど。

https://www.alsa-project.org/wiki/Changes_v1.1.5_v1.1.6

aplay/arecord
aplay: Fix wav file not being split on 32 bit platforms
aplay: Adjust sample rate limits to support newer hardware

https://alsa-project.org/wiki/Detailed_changes_v1.1.6_v1.1.7

aplay/arecord
- aplay: add missing block brackets
- aplay: Fix invalid file size check for non-regular files
aplay tries to check the file size via fstat() at parsing the format headers and avoids parsing when the size is shorter than the given size. This works fine for regular files, but when a special file like pipe is passed, it fails, eventually leading to the fallback mode wrongly.
A proper fix is to do this sanity check only for a regular file.

最新のTiny Core 10.1はなぜかapu2で動かない。というか、動かせていない。
しかも動く環境で確認したら、aplayのバージョンが若干古いので使えない。
じゃあ他のOSでとなるとfedora、arch linux、、、fedora30のaplayは1.1.9だけど、どうやってapuで動かすんだ？とか。
なかなか現状、そこまで手が回らない。まとまった時間がとれない。

Ras piはどうか。
今年の6月からリリースされている「Raspbian Buster」のalsa-utilsのバージョンは1.1.8-2だ。
これが使えないかということなんだけど。

以前、beagle kickのSummer Vibeという曲の768kHz WAV音源をNASに置いてapu2c4で鳴らしてみたことがあるんだけど、LANの途中に100BASE-Tのハブが挟まっていて鳴らなかった。それを外すと問題なく音が出た。つまり768kHzのハイレゾデータ転送は100BASE-Tでは速度が足りない。ras pi2のLanは100BASE-Tなので、バックエンドにできないということだ。
しかし3B+なら「maximum throughput 300Mbps」なので使えるかもしれない。

Raspbian Busterで、ras pi3B+を動かしてみる。
ダウンロードしたイメージファイルの時点で、既にnmapはインストールされている。しかし特殊な仕様？みたいで、netcatの-e オプションが「invalid option」とされて跳ねられるのだ。代替で-c オプションの使用も試みたが同様。
そんなわけで、使えない。

piCoreを使う？
3b+以降には、未だpiCoreは正式対応していない。
しかしベータ版の10beta12以上で動くらしい。piCore-10.1beta1aを落としてきて動かしてみる。

aplay: version 1.1.7 by Jaroslav Kysela 

これは使えるかもと思ったけど、nmapがlibpcapがないとかでインストールできない。
ソースからインストールは手に余る。

そんなこんなで、あんまり焦らず現状維持を主体で当面はやっていくかな、と思っている。
果報は寝て待てだ。

しかし実際のところ、700kHz台でPPAPで、どの程度の変化があるのか、やってみないと分からないといえばそうなんだけど、ここまできたら大きな変化は望めないんじゃないかと思っている。
根拠は薄弱だが。

https://www.itmedia.co.jp/lifestyle/articles/1710/31/news092_4.html
MQAの音が良い理由　ニューロサイエンスが解き明かした聴覚の“真実” (4/5)

2012年に神経科学研究者のMichael S. Lewicki准教授、翌年にJacob N. Oppenheim氏などが相次いて論文を発表しました。これによると、人間は時間に対して“超”敏感なのだそうです。音響心理学的な視点の従来論では、人間の時間的な分析力は50μsとされていましたが、そこで見過ごされてきたものをニューロサイエンスの視点で分析した結果、従来の5倍、つまり10μsで反応を示したとのことです。音楽家はさらに上回り5μs、指揮者はもっと上で3μs。それだけ人間の感度というのは繊細だということを、ニューロサイエンスは示唆しました。

ここで簡単な計算をしてみる。
1 (sec) / 368000 (kHz) = 0.00000271739...(sec)
つまり、300kHz台のハイレゾで、指揮者の分析力（3μs）に追いつくということ。
素人は10μsということだけど、オーディオファイルは音を分析的に聴くという毎日を繰り返しているわけだ。スピーカーを数mm動かしたらボーカルが5cm横にずれたとか、そんなことばっかり日常的に気にしているわけで、そうした日々の訓練の結果、たぶん、時間的な分析力は指揮者と同等だ。こんなこと言っていいのかどうか知らんけど。
300kHz台のハイレゾで世界が変わるって、たぶんそういうことだ。

1 (sec) / 705600 (kHz) = 0.00000141723...(sec)
うちでは、300kHz台と700kHz台の比較で聴感上の違いがある。ということは、たぶん、指揮者で3μsというのも最短ではないのだと思う。どういう測定をしたのか分からないけど、測定法がもっと繊細な神経反応の変化を抽出できるようになったら、もう少し限界が短くなるのではないかと思っている。

どうなんだろうね、こういう説明。
本来は、サンプリング周波数＝再生音の時間分解能になるわけではない。
サンプリング定理に則れば、サンプリング周波数がいくらだろうが、再生音は正確にもとの波形を再現するはず。
理想的に再現されれば、時間的な遅延は「0」となる筈だ（実際のデジタル再生では理想とのズレが問題となる）。
CDの場合、1 (sec) / 44100 (kHz) = 22.67573...(μs) だから、人間の時間的な分析力10μsを44.1kHzでサンプリングされたCD音源の音ではカバーしきれない、過去には50μsとされていたのでカバーできると思われていたのだ、、、とか、まことしやかに説明されたりしたら、ちょっと信じられないと思ったりするので、本当は、300kHz台のハイレゾ、700kHz台のハイレゾで指揮者がどうこうという上記の説明は適当ではない。

なんでこんな説明したかというと、700kHz台の再生だと1.4μsより短い時間分解能が保証される、という意味合いだ。
1.4μsの間隔でデータが送られるのをPCトラポとDACは処理しなければならない。たぶん、2μsとか遅延したら音が途切れるようなことになるだろう。そうならないためには、1.4μsでデータを処理できる精度をシステムが維持しないといけない。
そうなると再生音自体が遅延が少ない音になる。
700kHz台のデータを再生するというのは、そういう意味の保証なのだ。

PPAPで伝送したところで、1.4μsの伝送精度は大きくは変わらない。
その数値は既に人間の時間的分析力の限界を超えている？と思われ、NASマウントでのmpd再生とPPAPによるaplay再生で、大きな差は生じないのではないか、と。
我乍ら、随分と大雑把な推測だ。

これは個人的仮説というか、想像（むしろ妄想というか）なんだけど、例えばCD音源の場合、デジタルデータが送られる間隔は片チャンネル1/44100=22.67573μsで、つまり700kHzで1.4μsしか待てない状況よりも、ずっと余裕がある。
余裕があるといえばいいように聞こえるけど、これって、もしかして、数μs程度の遅延が生じても音が途切れずに再生処理できてしまう、という事があるのではないか。そうした遅延が一定ならまだいいけど、変動するようなら再生音の変化とノイズになる。
これってジッターなわけだけど。
クロックジッターとは数値のレベルが全く違う話で、いくらクロックが高精度でも、システムが迅速に追随できなかったら再生音に影響するジッターが生じる。実際のところ、どこまでシステムがクロックの精度に追随してるのだろうかという話。部品によって違うのか、とか。例えばDACへの負荷が増えると音が悪化するとか、そういうことの原因はこういうところにあるんじゃないか、とか。

こういうことって、どの程度のレベルで生じていて、どう影響があるんだろうか。
勉強不足で、読んだことがない。
そんなことは無視できるんだよ、ということならいいんだけど。