abk1's scratched blog 3

今回は、最近のオーディオシステムの音の変化について。
最近のエントリーに、デジタル信号の違いに鋭敏になってきている気がすると書いた。もうちょっと見えてきた内実を記録しておく。

mpdのデジタルボリュームに因る音の劣化に敏感になったみたいだというのは、前回に書いた。
アンプのボリュームを使うほうが良いというだけではなく、どうも、M500（DAC）でもDAC本体のデジタルボリュームを使うほうが良いようだ。以前はmpdのボリュームと差異が感じられなかったが、今はM500のボリュームを使うほうが良い気がする。
どういうことだろうね。

昨今の一般的なネットワークオーディオは、タブレットからWiFi経由でコントロールするのが主流だと思う。
うちはそうではない。LMSのコントローラーとしてウェブブラウザや、mpdクライアントのncmpcppを日常使用に使っているノートPC上で動かしている。
これが、音を出しているときにはウィンドウを閉じたりバックグラウンドに回したりして、カーソルやマウス、キーボードの操作に影響されないようにしたほうが、音が良く安定感があり音色が澄んで聴こえるようになった。
同時に有線LANを外して、WiFi接続にしたほうが良いような気がする。これはおそらく、ノートPCの電圧の変動が有線LANケーブルを通じてLANネットワークに影響するのを防ぐことが出来るからだと思う。
以前から、こういったことが多少は音に影響しているのかな、と思うことはあったが、明らかではなかった。
それがどうやら、配慮したほうが良さそうだということになってきている。
わずかで微妙な差異なのだけど、放任できなくなってきている。
更に、以前なら普段使いのPCでYoutube動画を流したりしていても、そう影響ないなと思っていたのだけど、最近はどうも少し音が曇る。いろいろ日常的なPCの使用に影響が出てきている、というか、そういうセッティングになってるということなのだろうけど。

実際のところ、オーディオのコントローラーと普段使うPCは、分けたくない。
タブレットの操作は嫌いだし、PCを増やすとなると置き場の問題がある。如何にノイズを抑えるかを考えないといけない。

NASとストリーミング（LMS）の比較だと、現在はNASの方が優れた音が出ている。
LMSサーバーのWiFi接続を止めて、以前の場所に有線接続するのも考えるのだけど、置き場の工面が難しい。それに、LMSサーバーの場所を戻したら、NASの音質への影響もあると思われるので、良いかどうかはやってみないと分からない。

かなり大きな変化がある。libsamplerateで384/32にアップサンプリングした音と、44.1/32でCDとビットパーフェクトの音、以前は明らかにアップサンプリングしたほうが良かった。
それが今は、どちらがいい音なのかと問われたときに、答えに窮するぐらい、44.1/32の音が改善している。
そして逆に、384/32にアップサンプリングした音は、どこか冴えない気がする。以前ほどには良くない気がする。以前はあった美点が薄れて透明度が低い感じ、どこか曇りがある気がする。
細かい比較試聴は出来ていない。
大雑把な印象で整理できていないので、焦らず時間をかけて聴かないといけない。
それに、そもそもmpdサーバーが違うし、Back-Endも違うので、これも考慮して検討、試行しないといけない。あと、44.1系と48系という違いがある。これも比較するなら揃えないといけない。
今の音を比較するには、以前のような単純なやり方では済まないだろうという予感がする。

デジタル信号の変化やノイズに鋭敏に反応するということは、デジタルデータをより正確にDA変換しているということなのかもしれない。だから、44.1/32のほうが384/32よりも改善の恩恵が大きいのかもしれない。44.1の方がデータが粗い分、DA変換の正確性への要求度が高いと思われるからだ。
もう一つの可能性として、アップサンプリングを行うmpdサーバーへの負荷がジッターとして音に作用している可能性がある。以前は大きな影響としては現れなかったのが、今の鋭敏な環境だと明瞭になるのかもしれない。
ほんとかな。

ここまで色々書いてきているけど、音源によって印象が違うこともある。mpdのボリュームでもいいじゃないかと思ったり。
やはり、じっくり時間をとって聴き比べないと、間違える。

そういうわけで、とりあえず、mpdサーバーとBack-Endを統一して聴き比べてみた。
mpdサーバーはメインシステムのProBook 450G9。libsamplerateのBestの設定で384kHzへのアップサンプリングが出来る機械ということだと、これに決まってしまう。
Back-Endもメインシステムで、apu2d4。
Back-Endに384、44.1、どちらの信号も受けることが出来るよう設定して、USB出力をRME ADI-2 DACに送る。
mpdサーバーの.mpdconfを切り替えることで、伝送するデジタルデータを変えて比較する。

ここで問題が生じる。
PPAPというオーディオ伝送方式は、ハードウェアに依存する部分が大きい。どう依存するかというと、44.1は100Base-Tが必要で、384は1000Base-Tのほうが良さそうという、そういう感じなのだ。

450G9のLAN経路をスイッチングハブで100Base-Tに設定し、apu2のLANにDMJ-100BTを介在させることで、44.1はなんとかギリギリ安定して伝送する。
これで384が通るか？と思ったけど、なんとか鳴った。昔は100Base-Tだと鳴らなかった。LANのノイズが少なくなると伝送が安定するのかもしれない。
そういう状況で音を出すと、どうも384も44.1も、ともに本領発揮しない感じ。
44.1は機体自体が100Base-Tで動くRas Pi2Bと、古い機械である820G2の組み合わせのほうが生き生きと鳴るような気がする。
384はやはり、1000Base-Tで流したほうが、余裕があるような気がする。100Base-Tだと音が硬くて窮屈な気がする。
Ras Pi2Bと450G9で組ませてみると、これもどうもなんだかしっくりこない。伝送もいまいち安定しないし、雑味が強くなる。

そういうわけで、単純に機械を固定して比較することは、あんまり意味が無さそうなのだ。
普段の使用に際しては、アップサンプリングは850G9とapu2、44.1は820G2とRas Pi2Bで鳴らすことにした。本領発揮できる音で使い分けるほうがいい。
そうした音を聴いて比べると、以前よりもずっと僅差になった。
情報量だけ比べたら384のほうが優位なのだけど、44.1のほうが明瞭で歌心が感じられ、こちらのほうが良いという人も少なくないだろう。

しかし、1年前に試聴したときは、明らかにアップサンプリングのほうが良いという結論だった。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20240830a.htm

上記の過去エントリーによると、Ras Pi2Bと820G2の組み合わせで44.1から384まで音が出ていたようだ。
当時はLANの伝送速度について意識していない。
当時のシステムは多分、下記エントリーの配置。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20240715a.htm
なんで問題なく44.1が鳴ったのか考えてみたら、当時はRas pi2BへのLANの経路に100Base-TのスイッチングハブであるFX-08miniを使っていた。恐らくはこれが、44.1を伝送するのにうまく働いてくれたのだろう。

このときは簡単なテストのようなつもりで、主力機の方は使っていない。たまたま偶然、当時は問題なく鳴ったので試聴ができたようなんだけど、820G2ではmpdを最良の設定で動かすことができない。たしか、Bestの設定で鳴らせるのは192までだったと思う。Mediumならたしか、768kHzでも使えた気がする。
この際なので、このときの機械で比較試聴してみる。
同時に、384kHzと、352.8kHzの比較もする。以前は44.1と300台に明確な差があったので、384と352.8を比べることに大きな意味を感じなかったんだけど、今は聴いてみないと分からない。44.1と352.8の音は近いかもしれない。

ちょっと問題がある。
Ras Pi2B（piCore 14.1）ではncatコマンドを2つ同時に走らせることができない。理由は不明。だからサンプリング周波数を変えるたびに、Back-Endの設定を書き変えて再起動しないといけない。試聴の環境としては良くないが、仕方ない。
そういうわけで、設定を切り替え再起動しながらの試聴だ。
なお、mpdサーバーから44.1は100Base-Tで出力し300台は1000Base-Tで出力している。現在のLANでは、そうしないと安定しないからだ。
音源はDeezerのflac音源を使用した。

352.8kHzは、ときどきプチッとノイズが入る。音自体は、悪くはないのだけど何かすっきりしない。384kHzは、352.8よりも、たおやかな感じの音色。やはりプチノイズがたまにある。あまりアップサンプリング再生の環境が良いとは言えないのだろう。
44.1kHz、しっかりした音色で鳴る。意外にも352.8よりもいいような気がする。情報量はやや少ないけど補って余りある安定感がある。安定感というのは音の実体感だ。音のニュアンスに説得力がある。44.1はやや音量が大きいかのように聞こえる。
この結果は何だろう。
384と352.8のギャップは説明しにくい。使いたいと思えるのは、384と44.1ということになる。なぜ352.8がいまひとつ良くないのか分からない。もしかしたら、mpdサーバーである820G2のクロックの性格に因るのだろうか。アップサンプリングに際して、384のほうに何かが有利に働くのだろうか。想像、雑感の域を出ない。
384も44.1より優れていると言いにくい。音数は多いようだけど、それがオーディオ的な心地よさに結び付いていない感じがする。

しかしこれが、850G9とapu2で384を鳴らすと、音色に説得力が宿る。44.1よりも優位性があるように思えるのだけど、前述したが、44.1のほうが好みだという人がいてもおかしくないと思う。384はどこか素っ気ない感じがする。
352.8も聴いてみた。ブラインドでは聴き分けにくいと思うが、384よりメリハリがあるような気がする。しかし384の方が階調が深い。352.8は、820G2の時ほどではないけど、何故か粗さを感じる。なんとなくジッターの影響を思わせる感触だ。根拠は薄弱で理由は不明だ。
384の陰影の深さと44.1の実体感、両方が得られたら良いのだろうけど。

ともあれ、以前のように明確にアップサンプリングしたほうが良いとは、言えなくなった。
それぐらいロスレス音源の再生音は良くなっている。

僕は昔から、ノイズやジッターが多い環境では、良質なアップサンプリングで処理した音源のほうが有利ではないかと言っていた。
今回の結果と、昨年の結果を比較検討すれば、それはそれで、正しいのだと思う。
正しいのだとしても、では良質な環境ではハイレゾに意味がないということに、なるだろうか。それは後日に譲るとして、アップサンプリングデータの再生環境について、考えたほうが良いかもしれない。本領発揮は出来ていないのではないかという気がする。

ここで、突然だが、そもそもは上流サーバーをUPSにつないだことが現在の懸案の要因だということに立ち返る。
NASをUPSにつなぐのは致し方ない。
しかし、mpdサーバー（Tiny Core OSで電源ラインでオフ可）やスイッチングハブをつなぐ必要性はない。

ということで、UPSからそれらを外し、電源経路を分ける。
複数の音源や設定を変えての音質評価はこれからだけど、明らかに音がスッキリした。384、かなり本領を発揮している。
NASは、このままでいいのかな、仕方ないかな。
下流サーバーはUPSを外したら音が悪くなるのが、やはりこうなると謎だ。
44.1との比較。
384は音楽の色が増して、44.1のほうが地味になった。これも意外。まさか逆転するとは。
44.1は、静かになった。前のほうが派手で良かったという人もいるかもしれない。しかし、落ち着いたかな。音が大きく聴こえていたのが、なくなった。細かいニュアンスが出るようになった気がする。
情報量は、かなり僅差。しかし音の間の空間の情報に差が出る。そういうデリケートな表現に384の優位性が出る。そう、こういうところが聴こえるようでないと、384にする意味はない。

それにしても、384と44.1、両方とも良くなった感じ。
そして、ブラインドでは、かなり区別が難しいレベルになったと思う。

LANmuteだけど、抜け防止ピンをカットしてみた。
うちではやはり、切ったほうがいい感じだ。僅かだが荒れみが減る。
LANポートによっては、抜け防止ピンをカットしたらコネクタがポートから抜けて留まらなくなることがあるので、いらないLANケーブルのピンを切って挿しても抜けずに使えるかをポートごとに確かめないといけない。これは要注意なので記載しておく。

あと、アップサンプリングしないハイレゾ音源を聴いて比較する必要がある。まだできてない。

こうなってくると、以前はなんでノイズの影響が少なかったのかということも気になる。
ノイズが多い環境では、相対的にノイズの影響を受けにくいということはあるかもしれない。1年前のノイズが多かったであろう環境でも、そこそこの音が鳴っていたのは不思議だ。いや、アップサンプリングしかいい音に聞こえなかったという意味でも、それはいい音ではなかった、足りなかったのだろうかなあ。
それは今の音を聴いて思う。
簡単にそういうこと言っては誤るんだけど。
1年前の記憶との比較だから、曖昧になるのも仕方がないところがある。

去年のエントリーで、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のほうが確かに上で、慣れてしまったら、意外に大きな差異に感じるのではないかと思える。

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