abk1's scratched blog 3

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

まず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)

前回のエントリーでは、TC64-11.1 mpdサーバーをHP Probook 450 G9で動かした。
どこまでやれるか試しているのだが、ここで問題がある。

カタログ上、450 G9のCPUは最高4.9GHzで動く筈だが、3.7GHzまででしか動いてくれない。
インテルのCPUにはターボ・ブースト・テクノロジーというのがあって、負荷がかかると自動的にクロック周波数を上げるのだけど、それが充分に機能してない？ようなのだ。
原因が分からない。

ネット上で調べたところ、原因として考えられるのは、熱の問題、電力の問題、BIOSのバグ、これらは該当しないだろう。
あと、AVX2、AVX-512のような遅いSIMDがクロックを下げるとか。
これはよく分からない。アクティブなコアが増加するとクロック周波数の上昇率が下がるということらしいが、mpdサーバーで動いているプロセスは少ない。
ほとんどのコアは仕事をしてないようにすら見えるので、これも違う気がする。

うちのmpdサーバー EliteBook 820 G2の状況をメモ。

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 2886.755
cpu MHz		: 2831.833
cpu MHz		: 2697.611
cpu MHz		: 2694.282

tc@box:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave

tc@box:~$ grep 'model name' /proc/cpuinfo
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
model name	: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
tc@box:~$ 

powersaveで動いている。
CPUは2.30GHzだが、動くときには2.8GHz以上で動いている。i5-5300Uのターボ・ブースト利用時の最大周波数は2.90 GHzであり、ブーストが機能している。
（powersaveでもブーストは効くんだね）

そういうわけで、Probook 450 G9のi7-1255Uでターボ・ブーストが機能しない？のが残念な状況だ。
正直、買って試してみないと分からないな、というのはあったので想定内といえばそうなんだけど、820 G2で動いてるんだから多分いけるだろう、と甘い判断をしたわけだ。、、

Probook 450 G9をmpdサーバーとして動かしてみたときの状況。

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 2608.375
cpu MHz		: 2643.276
cpu MHz		: 3700.000
cpu MHz		: 3700.000
cpu MHz		: 820.543
cpu MHz		: 1357.115
cpu MHz		: 2889.705
cpu MHz		: 1141.198
cpu MHz		: 2205.000
cpu MHz		: 2569.790
cpu MHz		: 1859.254
cpu MHz		: 888.040

tc@box:~$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
*snip*

tc@box:~$ grep 'model name' /proc/cpuinfo
model name	: 12th Gen Intel(R) Core(TM) i7-1255U
*snip*

tc@box:~$ 

こんな感じで3.7GHzが上限になっている様だ。なんでかねえ、、、

https://www.intel.co.jp/content/www/jp/ja/products/sku/226259/intel-core-i71255u-processor-12m-cache-up-to-4-70-ghz/specifications.html
インテル® Core™ i7-1255U プロセッサー

上記のインテルのサイトによると、
Performance-coresの数　2、Efficient-coresの数　8
Performance-core最大ターボ・フリークエンシー　4.70 GHz
Efficient-core のターボ・ブースト利用時の最大フリークエンシー　3.50 GHz
とある。

https://xtech.nikkei.com/atcl/nxt/column/18/02268/111800001/
最新のインテルCPU、第12世代Coreシリーズは何が違うのか
日経クロステック 2022.12.12

上記記事によると第12世代のインテルCPU、つまりi7-1255Uは、PコアとEコア、2種類のコアを積んでいると。
高い性能が必要な処理はPコア、負荷は低いが常時実行するような処理はEコアが向いているそうだ。
性能を重視した従来のCPUコアがPコアであり、性能よりも電力効率を重視したのがEコアで物理的サイズはPコアの4分の1と。
そんな構造なので、スレッドごとの処理を適切なコアに割り振る「スレッド・ディレクター」というのがCPUに組み込まれていて、負荷が高い処理はPコアに振り分けされるらしい。

実際、topでの挙動を見ると、mpdの処理は専ら「CPU0」と「CPU2」、２つのスレッドが代りばんこに受け持っているようだ。CPU0～3がPコアのスレッドなのかな。
これは、４つのスレッド全てでリレーする、820 G2のi5-5300Uの挙動とは異なる。
しかしそれなら、4GHz以上で動いてもいいと思うのだが、、、

ネット上を調べていたら、CPUの動作クロックを設定する「cpufreq」というツールがあり、Tiny Core 11では「cpupower.tcz」という形でリポジトリ上にあるらしいということが分かった。
インストール。

tc@box:~$ cpupower
Usage:	cpupower [-c|--cpu cpulist ]  []
Supported commands are:
	frequency-info
	frequency-set
	idle-info
	idle-set
	set
	info
	monitor
	help

Not all commands can make use of the -c cpulist option.

Use 'cpupower help ' for getting help for above commands.

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 405 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
tc@box:~$ 

tc@box:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7
Setting cpu: 8
Setting cpu: 9
Setting cpu: 10
Setting cpu: 11

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 657 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
tc@box:~$ 

tc@box:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

「powersave」を「performance」に変更。
これで、CPUがパフォーマンス優先にセットされた。

これでどうかというと、やはり、3.7GHzまで。
どうしたものかな、と思いながら使っていたら、ときに3.7GHzより少し上が出る。コンスタントには出ない。しかし、どうやら出せないわけじゃないんだろうなと。

そこで、BIOS関係で節電に関する設定を調整してみることにした。

ネット上に公開されているHPのマニュアルから引用。
HP PC Commercial BIOS (UEFI) Setup
Administration Guide
For Commercial Platforms using HP BIOSphere Gen 7-9 2020 -2022

しかし設定できる項目が少ない。こんなもんなのかなあ。
ネット上の日本語マニュアルは古いので英語の方を読む。日本語版には書いてないようなことが書いてある。

とりあえず、下記のように設定してみた。

設定変えたら、ほとんど動いていなかったEコアたちが一斉に動きだし、音が途切れるように。
Pコアに重要な仕事を降るということをしなくなったようだ。
変更した設定を戻していく。
Power Controlを「on」に。

Pコアに仕事を降るようになった？ようだが、それでも音が途切れる。

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  CPUs which run at the same hardware frequency: Not Available
  CPUs which need to have their frequency coordinated by software: Not Available
  maximum transition latency:  Cannot determine or is not supported.
Not Available
  available cpufreq governors: Not Available
  Unable to determine current policy
  current CPU frequency: Unable to call hardware
  current CPU frequency:  Unable to call to kernel
  boost state support:
    Supported: no
    Active: no
tc@box:~$ 

tc@box:~$ grep MHz /proc/cpuinfo
cpu MHz		: 841.518
cpu MHz		: 1462.869
cpu MHz		: 1700.000
cpu MHz		: 1703.346
cpu MHz		: 634.992
cpu MHz		: 1034.485
cpu MHz		: 1013.223
cpu MHz		: 1197.852
cpu MHz		: 1119.194
cpu MHz		: 977.032
cpu MHz		: 1196.461
cpu MHz		: 1198.542
tc@box:~$ 

なんか、すごく上手くいってないっぽい。IntelのCPUだという認識が出来ていない。
クロック周波数も上がっていない。

Runtime Power Managementを「on」に戻す。
Power Controlを「off」に。
これで、まともに音が出るようになった。

tc@box:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 4.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 4.70 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 966 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

tc@box:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
*snip*

tc@box:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
tc@box:~$ 

これで700kHz台を出そうとしたが、やはり10秒ほどでぶちぶち途切れる。
300kHz台だと問題なく音が出る。
音が出ているときのCPUのクロック周波数の上限は3.7GHz付近で変わらない。
まともに音が出ていないときは、クロック周波数も上がっていない、ということがある。ここの辺り挙動が謎だ。

ちょっと気になったのが、BIOSの説明書に出てきた「IPM+」というもの。
電源管理を行うソフトらしい。
Windowsで起動したら設定できるらしいので、セキュリティブートを有効にしてWindowsを起動し確認してみたら、インストールされていないようだったので、ほっとくことにする。

結局、BIOSの電源関係はあまり関係ないように思われた。

もしかして、Tiny Core OSの問題？とも思ったりもするが、調べてもはっきりしないし、確信もない。

この件は、当面、保留である。

そういうわけで、HP Probook 450 G9 mpdサーバーは、libsamplerateの設定を「Best Sinc Interpolator」、アップサンプリング設定を384kHzで動かしている。

そこそこ余裕を持って動いているように見える。
というのは、topで見るとmpdを担当するCPU0、CPU2、2つのスレッドがともに休んでいる時間がそこそこ見えるからだ。
比較したら、820 G2でMedium、768kHzで動かす方がもっと余裕がある挙動で動く。
Bestの設定は、やはり相当、重いのだと思う。

音はそれに見合うものがあると思うのだけど、音質の確認は流し聴きだけで、十分にはしていない。
音源によってはリアリティがMedium、768kHzより高いと思う。
Medium、768kHzと、Best、192kHzだと、どっちがいいかは好みにもよるかも、みたいな感じだった。これらも真剣に比較しないまま今に至ってるんだけど、Best、384kHzは、それらの水準を超えると思う。

今後、余裕がある時に確認していこうと思う。
課題はいろいろ残っているけど、無理せず、焦らず、という感じ。

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

UPnPでデータを飛ばしてレンダラーに組み込んだlibsamplerateでアップサンプリングするプランだけど、いくらか試みた中で、めぼしいところを書いておこうと思う。
途中経過報告だ。

実は、Daphileでアップサンプリングが出来る（いきなり逆走してるが、時系列上仕方ない）。
アップサンプリングして、Daphileがオーディオデバイスとして認識しているUSB DACに出力することは可能だ。
設定項目の表記からの推定だけど、使われるライブラリはSoXらしい。
piCorePlayerに送るLMSからの出力は、アップサンプリングできない。

この際なので、Daphileのアップサンプリングも試してみようと思ってやってみた。だけど、どうも思わしくない。
44.1/16を整数倍していって、88.2kHzから352.8kHzまで試してみた。しかし音が滲んだ感じになり、締りがなくなりぼんやりしている。アップサンプリングなどしない方がいい。
加えてアップサンプリングさせたらギャップレス再生が出来なくなった。こちらも大きな問題で、Daphileを使う意味がなくなる。

Daphileを動かしているのはCompaq 6730bでハードとして古いので強化したらどうだろうかとか、64-bit x86か、32-bit x86を使ったらどうだろうとか、思うところもあるんだけど、取り敢えず直ぐに使えるハードがないし、想像以上に上手くいかなかったので最早あんまり期待していない、、、
しかし手持ちの古いハードで遣り繰りしていくのにも、そろそろ限界を感じている。上を目指す気があるなら、新しいハードがもう少しあった方が余裕があるよね、、、ということでアップサンプリングサーバーとして使っているHP EliteBook 2570pを、もう1台、入手することにした。

それにしても、新しくすると言っても2012年頃の製品だ。6730bは2008年頃の製品だから、4年ぐらい新しくなる。
4年新しくするって、意味ないかな、、、
そんなこと思いながらも、安いのがあったので注文してしまった。

さて、次の作戦はUPnP、Volumioだ。Volumioといっても、懐かしのv1.55を使う。構造がシンプルで扱いやすいし、UPnPクライアントとしての機能も内蔵している。
しかもリサンプラーはデフォルトでlibsamplerate派生と思われるlibresampleだ。
考えてみたら、これは使ってみない手はない。

下記サイトからSourceForgeのダウンロードへのリンクが貼ってある。
Volumio 1.55 for Raspberry Pi & Raspberry Pi 2
https://community.volumio.org/t/volumio-1-55-for-raspberry-pi-raspberry-pi-2/2393

ディスクイメージを焼いて、Raspberry pi2に刺して起動、ipアドレスを確認しウェブブラウザからアクセスすると操作画面が表示される。
右上の「MENU」から「Playback」、MPD Configuration の「Audio Output」からDACへの出力を設定する。
どうも、繋ぐDACによって表示がまちまちな様子なので、適宜その時の状況で合わせる。

UPnPレンダラーの設定は4年前にしたことがある。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20170102a.htm

右上の「MENU」から「System」に入る。
Services managementの「UPNP Control」と「UPNP\DLNA Indexing」をON。「APPLY」。
再起動が必要だけど、volumio 1.55はブラウザからの操作で上手く再起動しないことがよくあるので、シャットダウンして電源を入れ直した方が確実だと思う。

Daphileのほうは、下記サイトに操作画面のキャプチャ付きで詳しい説明がある。多謝。
PCで音楽: Daphileのメディアサーバー化
http://asoyaji.blogspot.com/2019/07/daphile.html

Settings、Advanced Media Server Settings から「plugins」の中の「UPnP/DLNA bridge」「UPnP/DLNA Media Interface」を有効にする。
「3rd party Plugins」のプラグインリストから選んでチェックボックスにチェックを入れ、右下のapplyをクリック、再起動。選択したプラグインが「Active Plugins」のリストに移動する。
「UPnP/DLNA bridge」の「settings」をクリックし、「Start the Bridge」にチェックを入れ、「Restart」をクリック。
こんな感じで「Audio Player」の画面に戻ると、UPnPレンダラーがプレーヤーとして表示されるようになる。
うちでの「Audio Player」画面のキャプチャ。
この画面から操作したら音が出る。

そんな感じで、DaphileとVolimioを繋いでみた。
まず、アップサンプリングなし。問題なく音楽が再生できる。
アップサンプリングを設定。
まずDACの状況を確認する。
sshでVolumio 1.55にログイン、ユーザーはpi、パスワードはraspberry。
コマンド「cat /proc/asound/card0/stream0」でUSB DACの入力対応を確認。s32leなので32bitで周波数を上げていくことにする。

以下、ウェブブラウザの画面から設定。
右上の「MENU」から「Playback」、MPD Configurationの項目。
Audio buffer sizeはアップサンプリングするなら増量していく必要がある。
Audio output formatで、サンプリング周波数とビット深度を設定。
Sample rate converterは「Fastest Sinc Interpolator」で固定。Best、Mediumの設定も出来るが、Raspberry Pi2には負担が大きすぎて、まともに再生できないこともあるので使わない。Fastestがもともとmpdではデフォルトだし、それで十分にアップサンプリングによる音質向上効果が得られる。

話が逸れるが、個人的にはlibsamplerateのFastestの方が、SoXのVery Highよりも正確な処理をしているのではないかと思う。
正確というのは、もとのデジタル信号から理想的なDA変換をして得られるアナログ波形から、異なるサンプリング周波数とビット深度で理想的なAD変換を行ったときに得られるデジタルデータに、より近いデータに変換される、という意味だ。ややこしいけど。

過去に、ハイレゾ音源の音と、その音源から作られたCD相当の音源をlibsamplerateでアップサンプリングした音を、聴き比べたことがあるのだけど、殆ど差異がないという印象だった。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20170625a.htm
以前のエントリーの文面としては「結果はというと、44.1のアップサンプリングよりハイレゾ音源の方が繊細で耳あたりがいい鳴り方をする。アンプのボリュームが上がっていきやすい。ある意味、順当な結果になって良かった、という感じ。」と書いているが、、、
実は、差を「盛って」書いている。
今更こんなこと言うのはあれだけど「ここまで差が無いなら、アップサンプリングでいいじゃん」と思ったのが本音だった、、、
しかし当時は、それを弩ストレートに書く気になれなかったので、5mmを5cmぐらいに読み取る感じで書いた（ちょっと追記。普段、聴いているときよりもアンプのボリュームを上げたときに若干だが聴きやすいのはハイレゾ音源の方だった。通常の音量では聴き分けは難しいと思ったので、音量を上げて聴いたという経緯だ）。
その後のうちのオーディオのやり方は、やっぱりハイレゾ音源の方がいい、ではなく、CD音源でlibsamplerateによるアップサンプリング一辺倒で768kHzに至っている。結局、そういうことしか、うちではしていない。多分、4年前に聴いた300kHz台ハイレゾ音源の音は、700kHz台へのアップサンプリングになった時点で越えている。聴き比べしたわけじゃないので、多分だけど。

あと、SoXとlibsamplerateの音の違いを確認したこともあった。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180318a.htm
SoXはソースのサンプリング周波数の整数倍へのリサンプリングと、非整数倍へのリサンプリングで、再生音の定位が違う。libsamplerateは大きくは違わない。多分、libsamplerateの方が正確なのだ。正確さは音質にも影響している。
僕が700kHz台までやってみようと思えたのは、音質が確実に良くなったからだ。SoXしか弄ってなかったら、そんなことはしていないだろう。

話を戻す。
192kHzまでは安定して再生。
しかし300kHz台では途切れて音楽にならない。
これは、想定内、、、過去の経験からも、300kHz台以上はRaspberry Pi2にはきつい。それでapu2に移行した経緯がある。

ここで、EliteBook 2570pが届いた。
USBメモリでDaphileを動かしているCompaq 6730bをシャットダウンし、2570pに刺し替えて起動。
トラブル発生。一応、ipアドレスが振られている？のにDaphileの起動画面にアクセスできない。
そしてpingすら通らない。
あれこれと試した末、有線LAN端子の接点がひとつ折れているのを発見する。
なるほど、有線は使えないってことね、、、1万4千円だからな、、、返品は面倒だな、、、

Compaq 6730bで起動し直し、Wifi接続に設定し直して、再度、2570pで起動。
今度は、LANにつながった、、、
無線でも速度は確保出来ているようだ。
これだったら384kHzはいけるだろうか。6730bに比べたらましな感じだが、、、
結果からいえば無理だった。クロックアップしてみたり、sshでVolumioにログインして/etc/mpd.confを書き換えて352.8kHzを設定もしてみたけど、どうしても音が途切れ不安定になる。

192kHzで使用継続する意味があるかどうか。
web player、pulseaudio、libsamplerateで384kHzにアップサンプリングするほうが音はいい。実在感といえばいいか、音色の深み、輝きに差が出る。どうしても192kHzでは見劣りしてしまう。 しかしそれでも、Volumioを使って192kHzに上げた方が、Daphileに直接、USB DACを繋ぐよりはいいようだ。
当面、使ってみることにした。
使用上の問題で、何故かVolumioの音量が勝手に変わるということがある。音が出ないな、と思ったらボリュームが０とかになっている。何か理由があるんだろうけど確認できていない。

今回いくつか、普段使わないディストリビューションを使ったけど、うちでは何だか不具合が出て上手くいかなかった。
そういうわけで、いずれはTiny Coreベースでなんとかしたい。Tiny Coreはうちでは比較的安定している。少々荒っぽいことをしても動くタフなディストリビューションだという印象がある。
直ぐには出来ないだろうが、当面はWeb Player-Pulseaudio-384kHz、Daphile-Volumio 1.55-192kHzで凌ぐつもり。

ストリーミング音源利用に際して懸案だった、CDレベル音源のlibsamplerateによるアップサンプリングが、一応出来たので、備忘録にしておく。

そこそこ梃子摺ったけど、出来てみればそんなに複雑でもない。
ただ、作業行程で何が足りないのか推測し繰り返し試みないといけなかったので時間がかかった。まあ、僕の手際が悪いんだけど。
なにしろ、ログを読んでも何が足りないとかいけないとか、簡単に分からない。基本的なlinuxの知識が少ないので、初歩的なことを書いているのに気付かず、躓いたまま苦心惨憺の後に気付いたり、ということが多々ある。気付くまでログのあっち読んだりこっち読んだり、あれやったりこれやったりになるのだ。はっきりエラーと明言されていない記述も注意する必要があって、気付いたらそんなことだったのかなんだけど。
そういうときは、もしかして、この記述が怪しいのかな、ポイントなのかな？という、感が頼りになってくる。例えばログの中に「capability」という言葉があって、capability？、、cap?、、libcapというのが要るのかな？、、という感じで追い込む。
コンピューターをいじってるのにそんなんでいいのかという感じだ。

最初はpiCore 9で試みたが上手くいかず、tiny core 64 11.1で作っている。
そもそも、本気でアップサンプリングするならraspberry pi2とかだと限界がある。
ともあれ、以下、手順の要約。

tiny core pure 64 11.1のインストール行程を最初からなぞるのは面倒だったので、PPAP Frontを作る際のベースに使って、バックアップを保存していたディスクイメージを使うことにした。これをSDカードに書込み、Compaq 6730bに刺して起動、sshでログインしbulseaudioサーバーの環境を作っていく。

まず、tceコマンドで足りないライブラリ等をインストール。
alsa関連を足りないことがないように拡充、libcap関連、dbus関連を追加。
あと、以下に経過を記録。

wget http://freedesktop.org/software/pulseaudio/releases/pulseaudio-13.0.tar.xz
tar -xf pulse*xz
cd pulseaudio-13.0

./configure --disable-x11 --enable-alsa --enable-samplerate
make
mkdir ../pulseaudio
sudo make DESTDIR=/home/tc/pulseaudio install

cd

mksquashfs pulseaudio pulseaudio-13.0.tcz
md5sum pulseaudio-13.0.tcz > pulseaudio-13.0.tcz.md5.txt

sudo cp *tcz* /mnt/*2/tce/optional
sudo vi /mnt/*2/tce/onboot.lst
(pulseaudio-13.0.tcz)

wgetでpulseaudio-13.0をダウンロード。
展開しディレクトリに入る。alsaとsamplerate（libsamplerate）は使えるように、x11は使わない設定で、インストール。
tczファイルなど作成し、optionalディレクトリにコピー、onboot.lstにOS起動時読み込みの設定を書き込み。

これで、pulseaudio-13.0をインストール終了。
この時点でのインストール済みのtcz一覧は、下記アドレスのファイルに記載。ずいぶん沢山入っている。本来なら要らないものも多く入っていると思う。
http://blown-lei.net/blog/pulseaudio-optional-tcz.txt
onboot.lstは下記のとおり。

less /mnt/*2/tce/onboot.lst

openssh.tcz
i2c-5.4.3-tinycore64.tcz
nfs-utils.tcz
alsa-modules-5.4.3-tinycore64.tcz
alsa.tcz
nmap.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
alsa-plugins-dev.tcz
alsa-config.tcz
alsa-dev.tcz
libcap.tcz
libcap-dev.tcz
dbus-dev.tcz
pulseaudio-13.0.tcz

こんな環境に出来上がった。
pulseaudioサーバーを設定していく。

mkdir .pulse
cp pulseaudio/usr/local/etc/pulse/default.pa .pulse
cp pulseaudio/usr/local/etc/pulse/daemon.conf .pulse

rm -rf pulseaudio*

ホームtcディレクトリに「.pulse」ディレクトリを作成。
設定ファイル「default.pa」と「daemon.conf」をソースからコピー複製し「.pulse」に設置。
インストールに使った残骸は「rm -rf」で削除。
設定ファイルの内容を、使用環境などに合わせて下記の通り変更。

vi .pulse/default.pa

#load-module module-native-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24

vi .pulse/daemon.conf

; resample-method = speex-float-1
resample-method = src-sinc-fastest

; default-sample-rate = 44100
; alternate-sample-rate = 48000
default-sample-rate = 192000
alternate-sample-rate = 192000

; default-sample-format = s16le
default-sample-format = s32le

以前のエントリーに書いたけど、module-native-protocol-tcpを設定することで、クライアントからの信号を受ける事ができるようになる。 src-sinc-fastestはlibsamplerateの設定。USB-DACの状況に合わせて記載。

filetool.sh -b
sudo reboot

設定を保存。リブート。

再度、sshでログインし、試用を開始。使えるリサンプラーを確認する。

tc@box:~$ pulseaudio --dump-resample-methods
src-sinc-best-quality
src-sinc-medium-quality
src-sinc-fastest
src-zero-order-hold
src-linear
trivial
speex-float-0
speex-float-1
speex-float-2
speex-float-3
speex-float-4
speex-float-5
speex-float-6
speex-float-7
speex-float-8
speex-float-9
speex-float-10
speex-fixed-0
speex-fixed-1
speex-fixed-2
speex-fixed-3
speex-fixed-4
speex-fixed-5
speex-fixed-6
speex-fixed-7
speex-fixed-8
speex-fixed-9
speex-fixed-10
ffmpeg
auto
copy
peaks
tc@box:~$ 

src-sinc-best-quality、src-sinc-medium-quality、src-sinc-fastest、と表示がある。
libsamplerateは使えるはずだ。

さて、鳴らしてみましょうか、、、「pulseaudio -D」で起動し、クライアントのfirefoxから音声信号を伝送する。
さっそく、音がでない。「top」を打つと、pulseaudioは仕事をしている様子。
状況は？

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

tc@box:~$ pactl list sinks
Sink #0
    State: RUNNING
    Name: auto_null
    Description: Dummy Output
    Driver: module-null-sink.c
    Sample Specification: s32le 2ch 192000Hz
    Channel Map: front-left,front-right
    Owner Module: 13
    Mute: no
    Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB
            balance 0.00
    Base Volume: 65536 / 100% / 0.00 dB
    Monitor Source: auto_null.monitor
    Latency: 206 usec, configured 500 usec
    Flags: DECIBEL_VOLUME LATENCY
    Properties:
        device.description = "Dummy Output"
        device.class = "abstract"
        device.icon_name = "audio-card"
    Formats:
        pcm
tc@box:~$

Name: auto_null、Description: Dummy Output、って、何？。
alsaはdacを認識しているが、pulseaudioは認識していない。
というか、クライアントから送られてきた信号が何処かに消えていくように設定されてるらしい。

原因は不明。多分何処かでミスってるのだろう。普通は自動的に読み込まれるのでハードの設定はpulseaudioではしなくていいものらしい。
しかしそんなことは言ってられないので、下記のように設定する。

vi .pulse/default.pa

#load-module module-alsa-sink
load-module module-alsa-sink device=hw:0,0

aplay -lで、「card 0: IncRAL2496UT1 [//], device 0: USB Audio」なので、hw:0,0だ。
これでどうか。

tc@box:~$ pactl list sinks
Sink #0
	State: RUNNING
	Name: alsa_output.hw_0_0
	Description: RATOC Systems, Inc.RAL-2496UT1_
	Driver: module-alsa-sink.c
（... 以下略 ）

一応、認識した、、、
pulseaudioを再起動して、信号伝送すると、、、音が出た。
ようやく一息、これで、なんとかなるのかな？

取り敢えず現状、音質は後回しで、ちゃんと運用できる事が優先なんだけど、いくつか問題が。

まず、192kHzだとブツブツ途切れるようなノイズが入って使えなかった。96kHzだと問題ないんだけど。
DACを変えたら、、、問題なくなったのかな？、、、
一応、384kHzで音は出るが700kHz台だと「Invalid sample rate '768000'.」とかエラー表示される。どうも微妙だ。
しかし、300kHz台が使える。
音は、、、
さすがに768kHzの深淵には及ばないけど、そこそこ良いんじゃないかな。
月にCD1枚程度の金額で、この音で聴けるなら、、、相当安いんじゃないかな。いや、、、使えますよこれ。

次に、ギャップレス再生ができない問題。これは、、、どうなんだろうね。
自宅NASの音源をmpdで聴いてきた限りでは、この問題は全く気にしなくても良かった。まあ、、、仕方がないのかな、、、

もうひとつは、クライアントPCにキャッシュが積み重なるようで、どんどんメモリが消費されていく。つまり、鳴らし始めのうちはいいけど数時間鳴らすとクライアントPCが不安定になるのだ。不可逆圧縮音源を使っていた時には、消費される容量が少なかったので、気付かなかったのだろうか。
しかし、8GB積んでるんだよ？
それが気付けば100%近く使用になりswapまで消費し始める。何にそんなに使ってるんだろう、、、firefoxを閉じると忽ち使用メモリ量は低下する。
一方、、、pulseaudioサーバー側は、ほとんどメモリを使っていない。

tc@box:~$ free
              total        used        free      shared  buff/cache   available
Mem:        3946904      239024     3592700       20636      115180     3440612
Swap:        959968           0      959968
tc@box:~$ 

何がどうなっているのやら。
素直にNode2iあたり導入するほうが楽なのかもしれない、、、（でもあれ、Linux用の操作アプリはないんじゃないかな、、、）
まあ、もうちょっと弄ってみましょうか、、、

弄れるかな、、、
弄れるかどうかはともかくとして、メインソースとして充分に使えそうなのが非常にありがたい。CD購入も減らせそうだ。

vi .pulse/default.pa

#load-module module-alsa-sink
load-module module-alsa-sink device=hw:0,0


### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
# load-module module-udev-detect
load-module module-udev-detect tsched=0
.else
### Use the static hardware detection module (for systems that lack udev support)
# load-module module-detect
load-module module-detect tsched=0
.endif

#load-module module-native-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24

vi .pulse/daemon.conf

; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB
# shm-size-bytes = 131072
# shm-size-bytes = 65536
shm-size-bytes = 32768

; resample-method = speex-float-1
resample-method = src-sinc-fastest

default-sample-format = s32le
default-sample-rate = 352800
alternate-sample-rate = 352800


; default-fragments = 4
; default-fragment-size-msec = 25

default-fragments = 2
# default-fragment-size-msec = 500
default-fragment-size-msec = 200
# default-fragment-size-msec = 100
# default-fragment-size-msec = 25

最近はサンプリングパラメータ関係で右往左往していたんだけど、一息ついて考えた。
そういえばMQAって最近はどうなってるんだっけ。
今迄、768kHz再生に取り組む方を優先していたのと、MQAを鳴らすなら700kHz台も鳴らせるDACじゃないと試す気になれなかったので、後回しになっていた。要はつまり、比較試聴ができないといけないと。
768kHz MQA DACで検索したら引っかかったDACが、S.M.S.L M500だ。
4万円強、と値段も手頃感があって入手した。MQAとアップサンプリングPCMを比較するためだけに5万以上は出せない。

しかし、考えてみたらMQAとPCM、どちらが上手く鳴るかはDACによっても違うかもしれないし、入力の種類によっても違う可能性がある。今回はうちで鳴らしてみたらどうだったか、という記録で、他のDACだと違う結果になる可能性がある。

さて、M500が届いた。
メガネケーブルでAC100Vに継ぐ。usbからの電力供給では動かない。
うちのPCトラポ（apu2c4/tiny core pure64 / mpd）のusbから入力してみる。
音が出ない？
リモコンのセレクターで入力選択する必要があるのか？
単4電池2本をリモコンに入れて操作。最初に「C」ボタンを押せというトラップがある（よく見たら説明書に書いている）。
usb入力で合ってるようだ。音量は40でMAXらしい。
ここで、下げていたアンプのボリュームを上げたら音が出た。いつから出ていたんだ？
どうもおかしい。音がすごく小さいのだ。
説明書は英語と中国語で書かれているのだけど、小さくて内容は最低限で今回の件では参考にはならない。
小さいとこに小さい字でファームウェアのアドレスが書いてあるんだけど、アクセスしたら「404 not found」。
新品なのに中古感があるとは味な奴である。

この時点で一応、MQA音源を認識するか確認。
所謂「ハイレゾCD」のサンプラーからEACでリッピングしたflacファイル。mpdで再生してMQAと認識。
ちょっと驚いたのは、CD1枚分flac+cue sheetの形式でも認識できる。
しかし、細かいことは後回しだ。

ネット検索したら音が小さいとか出ないとかノイズとかトラブルはあるようで、ファームのアップデートで解消されるらしい。

コンポにつなぎなおして試聴再開。 apu2c4 / tiny core pure64 7.2 / mpd+libsamplerate からusb出力。

音源に使ったのは、ハイレゾCDのサンプラー。MQA-CDと通常CDの2枚組。
これがハイレゾCDだ！ クラシックで聴き比べる体験サンプラー [MQA/UHQCD] / universal
https://www.universal-music.co.jp/p/uccg-40079/
クラシックだけじゃなくてジャズやロックのも用意したんだけど、実際に試聴に使ったのは殆どクラシックだ。

MQA-CD、通常CD両方を、EACでリッピングした。
MQA-CDは、トラック毎にflacファイルにしたものと、CD1枚のflac+cue sheet形式にしたものを作った。EACでリッピングしたものはMQAとして読み込めないという情報がネット上にあったので、トラック毎のflacはmqa.flacに変換したものも用意した。
つまり、1曲につき4種類のファイルを作っている。

mqa.flacというのは「MQA TagRestorer」というソフトで作られるファイル。flacファイルのタグにMQAの情報を書き込む。
MQA Tag Renaming Application / MQA
https://www.mqa.co.uk/tag435sdf43te
一見、英語サイトだが、下にスクロールしたら日本語が現れる。WindowsとMacに対応している。

しかしM500の場合は、mqa.flacでなくてもMQAとして読み込んでくれた。
つまり普通にEACでflacとしてリッピングしておけば、MQAファイルとして再生してくれる。flac+cue sheetでも問題ないようだ。cue sheetからアルバム1枚分の曲目リストを取り込み、3曲目を再生、というような操作をしても、ちゃんとMQAとして認識、再生する。

試聴の感想。

MQAは、なにしろ音の立ち上がり、減衰の感触が綺麗。個々の音が混濁せずに立ち上がり程よく主張する良い音だと思った。352.8/24のハイレゾ相当を圧縮解凍しているのだから良くて当たり前かもしれない。
サンプラーの説明書に、当初は176.4kHzの予定だったが音質の観点から352.8kHzにしたと書いてあった。僕自身の経験では、PCM音源は300kHz台以上から明確な音質改善があると感じていて、そういう意味でもサンプラー製作者の判断は正しいと思う。

しかし、曲の開始時にMQAだと認識するのに時間がかかり音が途切れる。
MQAの曲から次のMQAの曲につながる時は問題ないんだけど。
どんな条件で途切れるのか、しばらくはっきりしなかった。
いろんなファイルを繰り返し再生するうちに、何かバッファーの問題？と目星を付け、意外だったんだけど、もしやと思い、mpd.confの「audio_buffer_size」を小さくしたら、すっかり改善してしまった。
こんな影響があるんだね。
mpd以外の再生ソフトでどうなるかは確認していない。

通常CDからリッピングした44.1/16 PCMはどうか。
そんなに悪くない。
これだけ聴いてたら多分、こんなものかと思うんじゃないかな。
しかしMQAと比較したら音が刺々しく音色の分離も劣る。というか、音質を比較するとかするまでもなく、音が鳴りだした瞬間に全く違うということが分かる。

アップサンプリングしたらどうか。
今回の試聴で、mpdによる352.8/24アップサンプリングはMQAに引けを取らないことが確認できた。
情報量は全く同等で互角。
音色の比較も非常に僅差。
だけどアップサンプリングのほうが、大音量のオーケストラなどDACにとって難しそうなところが、本当に少しだけ、混濁せず綺麗に鳴る。ブラインドで区別する自信は全くないけれど。
4万円のDACだからMQAで余力の無さが出るのかも。つまりDACにデコードの負担がかかるだけ不利ということだ。これは機種によって現われ方が違うかもしれない。
僕は、もしかしたらMQAのほうが、PCMアップサンプリングに勝るかもしれないと考えていた。デコードの負担が少ない機種なら、時間軸への対処に優位性があるMQAの音のほうがよくなる可能性があるのではないか。

CD音源705.6kHzへのアップサンプリングだと更に良くなる。情報量が多くてクリアな再生音。
でも、比べたらADI-2 DACで鳴らすほうが音がいい。若干だが音色のグラデーションが細やかで深みがある。M500はやや薄いというか、イメージとしては山麓の清流で、ADIは珊瑚礁の海というイメージだ。
あと問題は、700kHz台はどうも安定して鳴らせない。
なぜかノイズまみれの再生になることがあったり、もとに戻ったり。頻度がどうなのかとか原因とかは確認してない。300kHz台までで使う方が無難な気がする。個体差なのかどうか、どうなんだろう。

今回の比較では、44.1/16 ＜ 192/24 ＜ MQA(352.8/24) ≒ 352.8/24 ＜ 705.6/32、という感じだった。
これは順当といっていいのかな、どうなのだろう。

しかし今回の試聴で、うちでは通常CD同等の44.1/16の音源があればソースには困らないということが、ある程度明らかになった。
MQAはストリーミング音源とかに適するとか。
PCM音源のストリーミングをリアルタイムで768kHzにアップサンプリングして聴けるようにしたらどうなんだろうと考える。しかし現実的には、CDレベルのPCMを768kHzにアップサンプリングするより、MQAデコードのほうが機械の負担としては軽くて済むのかもしれない。それ自体でMQAフルデコードできるDACチップも作られたと聞く。そういうのを使った製品を買う方が、ユーザーは簡単に高音質が得られるだろう。
そういうのに比べたら、CD音源を768kHzになどというのは、ほぼそれ専用に特化したPCトランスポートがあるから出来るのだ。DACという機械にそれも含めて組み込むのは、まだ難しいのかもしれない。

あと今回、今更当たり前のことに気付いた。
PCMアップサンプリングだとmpdのソフトウェアボリュームでリスニングポイントのクライアントPCから音量調整が自由自在だけど、MQAだとその手は使えないんだね。mpdで少しでもボリューム絞ったらMQAでは無くなっちゃう。ただのPCMになる。それこそビットパーフェクトじゃなくなって折り畳まれたデータが使えなくなるのだろう。
つまりアンプまでボリューム調整のため歩かないといけない。
歩けよって事だけど、、、
うちではPCMでいいってことになるかな、、、

M500はフィルターを変更する機能があるんだけど、今回の試聴でそれは使っていない。
デフォルトの「fast linear」のままで、変えたら違うかどうかまでは試していない。
あとバランス出力の方がいいのかな。これはアンプがどうなのかにも依るんだろうけど。

前回、サンプリングパラメータによるジッターの影響の差異についてという、大仰なタイトルのエントリーを上げたんだけど、ない頭でいろいろ考えている。
繰り返し色々考えているので、今回のタイトルは再々考ということだ。アベノマスクもまだ届かないのに我ながら暇なことだ。

前回のエントリーで僕は「PCトラポによるアップサンプリングもジッター対策だと考えて使ってきている。そもそもハイレゾ音源で音が良くなるのは、それ自体がジッター対策になるからだ」と書いた。
ずっと、そう考えてやってきていた。

それが、どうも違うんじゃないかと考え始めている。
違うというか、考えが足りないと。
今回は、その不足分を追加する試みだ。
でも思いつくままの書き散らかしでとっちらかって、例によって科学的な正確さとは縁がない文章なので、世の中では意味がない内容かもしれない。そういう意味では、アベノマスクのいいかげんさを笑えないエントリーだ。

前回エントリーの試聴では、アップサンプリングと、仮想アースによるFGの安定によって、音がどう変わるかを確認したのだけど。
色々と、考えを改めることになった。
うちのデジタルオーディオに纏わる「仮説」についての話だ。

まず、PCトラポでアップサンプリングすることの意味について。
ジッター対策というよりも「アナログ音声の情報量」への貢献のほうが大きいのではないかと思うようになった。
情報量って、アップサンプリングでデジタルなデータ量が増えるのは当たり前（44.1/16から768/32だと30倍以上）なんだけど、データ量＝情報量とかいう、そういう話ではない。

以前は、アップサンプリングに伴って情報量が増える理由について、ジッターの影響が少なくなり、DA変換の正確性が向上することによるものだろう、と考えていた。
最近、考えるようになったのは、デジタル信号から変換されるアナログ音声信号の「振幅」の正確性への影響だ。
DA変換後のアナログ信号の振幅が、より正確に再生されるようになることで、音声の情報量が増加するのではないか、ということ。

わけがわからんね。
もう少し整理していく。

録音に際してアナログ音声は、サンプリング周波数で決められた時間間隔でサンプルされ、デジタルデータにAD変換されている。
サンプルされたデータがアナログ出力にDA変換された信号電圧の数値は、サンプルされた時点の数値はデジタルデータ自体から正確に数値化して変換すればいいのだけど、サンプリングされていない、サンプル間のアナログ出力電圧の数値は、DACチップによる補間で決定される。
補間というか、要するにサンプリング定理に則ってDA変換される過程で、サンプル間をつなぐアナログの電圧の値（振幅）がDA変換によって決定される。

NOS DACだとアップサンプリングなし、補間されて得られる数値は、たしかローパスフィルターの品質に影響されるのかな（違っていたら御免なさいだ）。
通常のDACだと、DACチップによるアップサンプリングを行うので、その品質にも影響される。もしもZOH、Linearなど低品質なアップサンプリングを行うDACチップがあったとしたら、十分に正確な振幅値の抽出が難しく、正確なアナログ波形再現が望めないのではないか。
低品質なアップサンプリングでも理論上は音質上の問題は全くないという説明を何処かで何回か読んだのだけど、僕には難しくてよく分からなかった。

ZOH、Linearなど低品質なアップサンプリングを行った場合、下図のようになる。

本来、DACチップが理論通りに働くなら、アップサンプリングに伴う音質の改善を考慮する必要はなくて、NOS-DACの音質はどうとかいう話もないはずなのだ。理論通りにいかないから、どうしようDACチップでアップサンプリングしようというような話に現実のチップがなっている。
そういう現状なのに、ZOH、Linearみたいなアップサンプリングでも音質に影響しないとは、個人的には中々信じられない。実際、PCトランスポートでZOH、Linearといった設定にしてアップサンプリングした場合、DACがADI-2 DACだと明らかに音質低下がある。むしろそんなことはしないほうがいい。

どのような方法にせよ、サンプル間が補間されて電圧が生じないと問題がある筈。
各々のDACチップなりの手法で電圧出力しているのだろうと思う。

そもそも、その補間自体が正確ではなくて、電圧に時間軸の変動があったり電圧自体の誤差があったりしたら、どうだろう。
そうした変動は、たぶんジッターとして再生音に作用する。
つまり、時間の流れのままに変動しているアナログ再生波形として考えた場合、時間軸の変動も電圧の誤差も、結果として出てくるのは「アナログ波形の乱れ」にしかならないので、区別すること自体ができないのではないか、だったら「ジッターの影響」で括られるのではないか、と思うからだ。

ちょっと、DACチップの気持ちになって、アナログ波形を出力してみた図。

我乍らひどい。
あんまり人に見せられないな、怒る人いるんじゃないかな。
実際には、このようなことにはなってないだろうとは思うのだけど。

それはともかく、PCトランスポートで良質なアップサンプリングをしておけば、DACチップによる補間の影響は小さくなる。
元のアナログ波形をPCでシミュレートし、その波形シミュレーションの振幅変動の数値から、新たなデジタル信号をサンプル数を増やして作り出し（そういうアップサンプリングをするということだけど）、そのデジタル信号をDACに伝える。
再生されるアナログ信号がよりAD変換前の信号に近い正確なものとなる。

アップサンプリングしてやらないとサンプル間の電圧が正確に再現されない（断言してるけど仮説だ）。
再生波形の歪みは20kHZとか聴取可能限界以上で生じるんだろうけど、再生音全てに影響すると思う。

正確なサンプルが増えることで、正確な音声信号の「振幅」の再現が可能になる。
より正確なアナログ波形の再現は、音楽の情報量を増やすことにつながる。
これはハイレゾ音源を使用する場合にも当てはまるだろう。

ここまで書いて、ひっくり返すような話だけど、ふつうに44.1/16の信号をDACチップ通したら、オシロスコープでは問題ないアナログ波形が表示される、というのを過去に何回か何処かしらで読んだことがある。つまり、アップサンプリングしたら正常なアナログ波形が得られるというのは、違うのだという。

しかし、じゃあオシロで正常な波形が出ていれば音質に問題がないかといえば、たぶんそうじゃないんだよね。ジッター対策なんか何もしなくたって、オシロの波形は正常でDACから音は普通に出るのだ。
そしてそういう音にオーディオファイルは満足できない。
僕は何を聴いているのだろう、ということになるのだけど。何が一体、どうなってるんだろうね、、、
DACチップに上記のような問題があるというのも仮説で、ジッターがどのようにDACチップに作用するのかもよく分からないのだけど。

次に、仮想アースによるジッター改善に伴い、再生音の音楽性改善がみられることについて。
驚いたのは、アップサンプリングによるよりも、PCトランスポートの仮想アースによるジッター低減のほうが音楽性の改善効果が大きかったことだ。まあ、驚くことじゃないと言われたらそうなんだけど、想定以上の音の変化があった。

ここでいう「音楽性」とは、音色の鮮度、色彩感、生命感といった感触。音色の自然さ、リアリティも含めたいところだが、前回の試聴では逆に不自然に感じられたケースがあり、ことは単純ではないみたい。改善するのが「音楽性」という漠然とした表現しかできないのも難しいところ。
サンプリング周波数には関係なく、ジッター改善に伴い再生音の音楽性の改善がみられる。

さらに今回、新たに気付いた。
サンプリング周波数が一定なら、ジッター改善に伴う音質向上に際して、基本的には情報量の向上は伴わない。

本当に？
いや、でも、なんだかそんな感じだよね？
ちょっとこれは僕にとっては意外なことだった。

僕は今まで、ジッターが改善され音質が良くなれば情報量も増えると、勝手に思い込んでいた。
考えてみたら、うちのオーディオの音質改善は、かなりの場面でアップサンプリングと足並み揃えていたので、「ジッター改善」に伴う情報量の増加について、ちゃんと意識し比較したこと自体がなかった。あるいは、音色が綺麗になって聴き取り易くなったのを「情報量が増えた」というように表現した事も、もしかしたらあったかもしれない。

今回の試聴で、情報量と音楽性、パラメータが2つになって、ちょっと、今まで何してたの？、という気持ちにもなったりしてるんだけど、、、ともかく、ジッター改善に伴う音質改善が、音声の情報量増加につながらないらしい？のは、僕にとってはかなり意外で困惑した。音楽性の向上は情報量の向上によるものと、ずっと考えていたんだからね。

そもそも、アップサンプリングの有無によってDA変換後の情報量が変わるということ自体が、理論的には有り得ないことだ。
デジタルデータはサンプリング定理に沿って再生されれば正確に再現される、理論的には。
現実にはそうはいかない。
ならばジッターを低減さえすれば理想的な再生に近づくに違いない、と考えていた。アップサンプリングで音声の情報量が増えるのは、アップサンプリングによってジッターの影響が減ることで理論的なDA変換に近づくから情報量が増えるのだ、と思っていた。
だけど今回、どうも、ことはそう単純ではない？という考えに至った、ということだ。

ジッターが改善したら「音楽性」が改善するが、音声の情報量は増えない。
正確なアップサンプリングを行うことで、CD音源に含まれている本当の情報量を引き出すことが出来る。

逆に言えば、情報量の向上がなくてもジッターの低減によって再生音の「音楽性」の向上を目指すことは出来る。
また、アップサンプリング自体にジッターの悪影響を減らす作用がある、という以前からの考えは、今でも妥当ではないかと思っている。アップサンプリングで情報量の向上だけではなく、音楽性の改善も得られるからだ（仮想アース程ではないけれど）。

しかし、どんな挙動がどのように作用しているかは分からない。
過去に僕の考えをアップしたことはあったが、当時から科学的な根拠がある論考ではなかったし、当時の考えだけでは足りなかったと思ってこんなエントリーを上げてはいるが、科学技術的根拠がないという意味では相変わらず机上の空論のままなのだ。

今回、更に、もしかしたらと思ったのは、データのサンプリングパラメータによって、ジッターの影響の現れ方が違い、音質劣化の聴こえ方も違うのではないか、ということ。だけど、なんだか手に負えない感があるし、そろそろ息切れ気味なので、今回はここまで。

GW以降、久しぶりに政治的なエントリーをあげたいと思ってたんだけど、まとまらない。
表現者とかアーティスト職の人たちが、政治的発言をすることの難しさと日本の現状についてといった内容。
しかし、どうにもまとめきれない。そうこうするうちに、SNSのツイッター上で「#検察庁法改正案に抗議します」というのがあって。黒川氏が辞任らしい。
なんだかもう、整理がつかん。

そういうのに比べたら、オーディオに関するエントリーは書きやすい。
書きやすいと言いながら、今回のエントリーは、読むのも大変だと思う。
なにしろだらだら長いのだ。
闇雲に何かしてるだけで収拾も付いていないし結論もない。大仰なタイトルだが内容は薄い。

CDが登場した頃、デジタルっぽい音という言葉が生まれた。
音が良くないと多くの人が感じたのだ。
実際、僕が最初にCDを聴いた当時のコンポはひどい代物だったけど、アナログのほうがいい音だと思った。
CDは、くぐもってるというか、生命感がないというか、灰色のベールを被ったような感触で、ひどいコンポでもそれなりに生き生きと鳴るアナログレコードよりCDのほうが音がいいとは思えなかった。10年ぐらいはそんな感じで過ごしていたように思う。

世間でもアナログ優位ということはずっと言われていて、デジタル同等というのは最近だ。
最近、デジタル音源の音は良くなったのだ。

CDも昔より音が良くなった。
録音が良くなった？いや、意外に、昔のCDも今の環境で鳴らすといいことも多い。
つまり、再生環境が良くなった。
再生環境のどこが良くなったんだろうか。
DACチップが変わったとか、いろいろあるんだろうけど、要するにジッターへの対策が昔よりも進んだのだろう。ノイズ対策や電源の強化が、デジタル音源の再生には必須な事も分かってきた。ある程度の対策は、うちでも行っている。

僕は、PCトラポによるアップサンプリングもジッター対策だと考えて使ってきている。
そもそもハイレゾ音源で音が良くなるのは、それ自体がジッター対策になるからだ。

PCM300kHz台でかなりの音質向上があり、700kHz台で更に改善があった。
その700kHz台で聴き始めた、今から1年前に、ボーカル録音への違和感についてエントリーを挙げた事がある。

アップサンプリングについて色々
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20190222a.htm
歌声の録音について自分なりに考えた
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20190320a.htm

先日、これらに訂正の追記を入れているのだけど。
今回のエントリーはそれに関連している。

当時、あらゆる楽音がリアリティを増したように聴こえる中、ポップミュージックのボーカルだけが違和感を増した。
音としての情報量は増えているようなのに、何か聴きづらい。しかも当初はJPop音源しか気付かなかった。
当時の僕は、録音の質に解を求めた。
その後、ボーカルの違和感を感じる音源はJPopだけではなく、欧米の音源にもあることが分かってきた。それも意外な、優秀録音とされていて300kHz台で素晴らしい声を聞かせてくれた音源ですらも。

自分なりに考えたりするうちに、多少は違和感は減っていた。
自分が慣れたのか、とも思っていたんだけど、インシュレーターを新たに追加したりリピーターハブを使ったり仮想アースを足したり、いろいろやっていたのが影響した？というのもあったのかもしれない。

銅板仮想アースをapu2c4、705.6kHz NAS mountで使い始めた時点で、この音質改善はどういうことだ？という気持ちが芽生え始めた。
ここで起きている音の変化は何に伴うものなのか。
アンプに使っていた時のアナログな変化とは違う。
PCトラポのGNDを銅板で拡張することで、GND電位が安定しクロックジッター低減につながっているとしたら、これはジッター低減に伴う音質改善を聴いているということだ、、、

今年の春から、Elitebook 2570pとapu2d4によるPPAP方式に移行した。
PPAPは更にジッターを減らす再生方式だ。
PPAP 768kHzで、いよいよ全く、1年前に感じていた違和感がなくなった。
なくなったのだ。
違和感を感じていたはずの声が、違和感を感じ始める前よりもっと自然に、オーディオ的な驚き、、、いや、音楽自体の美しさそのものをもって耳に届く。

ここに至って、ようやく気がついた。
あの違和感は、残存していたジッターによるものだ。録音のせいなどではない。

そんな断言していいのかね。
最低限の検証は、しないといけない。検証って何って、、、聴くだけなんだけどね。
システムから外していたapu2c4を戻して比較することにした。

apu2c4で、705.6kHz NAS mount再生を試みた。
LANの状況が違う。当時の100Base-Tではなく、1000Base-Tだ。1年前の100Base-Tに戻してもいいんだけど、、、既にFX08-miniは他所で使ってるんだよね。

比較試聴に使った音源は以下。

• 赤い鳥 - heritage from '70s CD選書 ベスト / 翼をください
• 矢野顕子 - Soft Landing / Bye Bye
• 井筒香奈江 - Laidback 2018 / Little Wing
• Joni Mitchell - Blue / A Case of You
• The Rolling Stones - Let It Bleed / Love in Vain ~ Country Honk

こんな感じ。
しかし、、、こんなに違ったっけ？ FX08-miniを戻してみるべきか？あと、当時は仮想アースを使っていなかったので、今回のapu2c4にも使っていない。その差異もあるのかもしれないが、、、
PPAP 768kHzのほうが、ずっと音楽的だ。
比べると705.6kHz NAS mountの音は、ノイズっぽい。

ただ、楽器の音は差異が小さいと感じる。違和感が少ない。これに対してボーカルは聴き分けやすい。差が大きいのだ。
改めて聴き直すと、ボーカル以外の楽器音や環境音も違いがあるのがわかる。しかし、やはり違和感とまでは感じられない。人の声は、わずかな差異でも気付きやすいのだと思う。音源によっては全く違うという印象を受ける。逆に差が少ない音源もあるということだ。

ここで、サンプリング周波数によって、どのような聴こえ方の変化があるのか聴き較べてみよう、という気になった。

ハードの条件は同じ、apu2c4、NAS mountだ。
音源は、705.6kHzで聴いたのと同じものを聴く。

試聴経過は、取り敢えず以上だ。しかし、どう考えたらいいんだろう。いろんな要素が混在して評価しにくい。

まずボーカル。
PPAP 768kHzを基準として、サンプリングパラメータを下げていくにつれて、砂っぽく、ノイズっぽくなっていくのは共通。
384kHzではまだ高評価だ。
192kHzあたりから評価がぼやけてくる。なんというか、ゼネラルオーディオと差別化する意義を見出せなくなってくるというか。
考えてみたら、これってRME ADI-2 DACにとっては、かなり辛口の評価なんだけど、実際、僕の耳にはそう聞こえたんだからしょうがない。i2s-opticalから良質なデジタル信号を入力した時の音は96/24でもかなり良いので、それだけ今回の試聴に使ったusbデジタル信号には問題があるのかも、、、

仮想アース追加後、随分、音色の表情が変わった。
44.1kHz/16bitでの評価は、どう考えたものか難しい。
96kHz以上では、順当に音質改善があるように思う。384kHz以上で何故か洋楽アーティストの声に違和感があるような。これもどう考えるべきか分からない。768kHz PPAPでは違和感ないのだけど、、、

楽器のほうも、サンプリングパラメータを下げていくにつれてノイズっぽくなっていく。
ピアノについての評価が辛い。192kHzでオモチャと評価している。
井筒のベースも評価が辛い、というかパラメータによって随分変わる。

ボーカル同様、仮想アース追加後の方が評価が上がる。
192kHzで、ピアノがピアノになったと評価している。
楽器によって傾向が出ないかとか思ってたけど、録音も違えば音楽ジャンルも違うのでまとまった結論が出せない。当たり前か。

とりあえず、PCトラポに仮想アースは效く効くということではある。GNDの安定によってジッター低減につながっているのだろうか。
ここまでで、つかれた。。。限界を感じるのでこのくらいにする。

最近はCDリッピング音源を705.6kHz32bitにアップサンプリングして聴いている。
以前は768kHzで聴いていたんだけど、ごくごく稀にクリックノイズが聞こえるような気がして（あくまで気がしてなんだけど）、精神衛生上の判断でそうしている。明らかにノイズが入るというのではないんだけど、、、
だから時々、768kHzに戻したりもする。
なんだか、768kHzのほうが705.6kHzより1割増し繊細な気がする。どうなんだろうね。

先日、mpdの設定を見ていて、libsamplerateはmpd 0.19.19のデフォルトリサンプラーであることを思い出した。libsamplerateがインストールされていれば、ビット深度とサンプリング周波数の設定をするだけで、libsamplerateで「SRC_SINC_FASTEST」の設定でアップサンプリングされるようだ。
そうだったんだなあ、、と見てるうちに、libsamplerateは「ZOH」「linear」といった設定も可能だったことに思い至った。正直、低品質ということで眼中になかったので、じっくり聴いたことがない。しかし、実際にはどんな音になるのか、確認しておくことには意味があると思ったので、ちょっと聴いてみた。

まあ、やっぱり良くないんだけど。
アップサンプリングなし（つまり44.1/16をそのままRME adi-2 DACで鳴らすということ）とZOH、Linear設定の700kHz台アップサンプリングを比べても、アップサンプリングなしの方がいいような気がする。ZOHよりは、linearの方が音がいい。というか、ZOHは刺々しいな。
試聴音源で詳細に比較してエントリーにしようかと思ってたんだけど、、なんか、めんどいな。

今回のエントリーはちょっともう、だらだらしている。
うちのやり方で十分、不満はないし、細かいこと言わなくていいじゃないかという感じ。

最近なんだか、アップサンプリングして聴くという手法が市民権を得つつあるような気がする。以前は、どちらかというと外道な手法というイメージで、正統なオーディオ再生ではないと一般的には認識されている、というふうに感じていた。それでも僕などは音がいいと思って、その手法を選択した。スーパーツィーターの接続に、世間では効果がないとされていたチャージカップルドネットワークを採用して使い続けているような人間だから仕方ないのである。
それが、風向きが変わってきている。

例えば、CHORDのCDトランスポート「Blu MkII」はアップサンプリングしてDACにつなぐ仕様になっている。
https://av.watch.impress.co.jp/docs/news/1041113.html
この機種が発売になったのが2017年、もう2年前のことだ。アップサンプリングしてDACに送るということは、バイナリ一致かどうかなんてもう気にしない、ということだ。僕は何でか、うっかりしたのか、もとからトロいのか、この機械がオーディオ界に及ぼす影響について気が付いていなかった。この頃から、たぶん、デジタルオーディオというものへの認識は変わって来たんじゃないかな。
バイナリ一致が金科玉条では無くなってきている。
MQAというフォーマットも、そうした認識の変化が受け入れられる土壌となっているのかな。

そもそもDACチップ自体がアップサンプリングして鳴らしているということも広く知られるようになってきていて、最近はこんなDACが売られている。
https://www.phileweb.com/interview/article/201902/12/634.html
CDの44.1kHzであっても、DSD1024まで引き上げて最高の音質で聴くというのがPro iDSDのコンセプトだという。Blu MkIIがやってることをトラポでやるかDACでやるかの違いというわけだ。

https://av.watch.impress.co.jp/docs/news/1167703.html
最近、「だれでもわかるハイレゾオーディオ」という本が出版されていて、電子出版で買ってちまちま斜め読みしているのだけど、ここではDACチップが行っているアップサンプリングをPCで代替しても構わないと書かれている。この本は「ハイレゾ」というより「DA変換そのもの」に関する数式苦手なオーディオファイル向け解説書なんだけど、かなり踏み込んだ記述がなされていて非常に面白い。というか、僕の興味の中心を射抜いている。すごく勉強になるし分かりやすい。「ZOH」「linear」についても書かれている。

アップサンプリングに日の目が当たること自体は別にいいのだけど、オーディオファイルの間だけではなく、世間一般でもアップサンプリングへの興味が高まっているようで、「アップサンプリング」でググるといろんなサイトがヒットする。ディープラーニングでアップサンプリングするというサイトがあったりして、それってもしかしてジョーク？とか思うんだけど、世間では案外、そういう感覚なんかもなあ、と複雑な心境になったりしている。

アップサンプリングと名が付くものなら何でもいいということになったら、将来的に僕自身が不利益を被るような気がする。例えば、libsamplerateはPCへの負担が大きいし上質なアップサンプリングだと言っても他と変わらないんなら、いらないね、ということになりはしないか。
もしも、libsamplerateがmpdで使えなくなったら。
SoXでいいじゃんと言われたら、うちはSoXで十分な音質を引き出すスキルがないんだよと言わざるをえない。libsamplerateならインストールさえしておけば後はmpdが勝手に良質なアップサンプリングをしてくれるので非常に助かるのだ。
PCトラポによるアップサンプリングは諦めて、Pro iDSDみたいなDACを買えばいいということになるのかもしれないけど、それはDACによるアップサンプリングの精度が重視されて今後は性能が上がっていくという事が前提になる。ZOHやlinearと同等のアップサンプリングでもいいということになれば、そういう安価で低い性能のDACチップが主流になるに決まっている。そうじゃない高性能DACは僕にとっては高嶺の花となるのだ。しゃれにならない。

そんなこと考えたりしてたら、MQAに否定的な話がアップされている。
記述を一部だけど引用してみる。

さよなら、MQA | | 言の葉の穴
https://kotonohanoana.com/archives/23587

まず、MQAはロッシー／非可逆圧縮である。

MQA音源はMQA化された時点で「大元のデータ」から変質しており、二度と元に戻らない。

MQA音源はMQA Limitedの掌の上でしか真価を発揮できない。

なるほど、、、僕は過去のエントリーでMQAへの期待を書いている。
非可逆圧縮ということについて、まず、データの同一性という意味では、アップサンプリング自体がDACチップがするにせよPCトラポでやるにせよ、バイナリ一致の音ではなくなるということだ。一般的なDACで音を聞くことは、バイナリ不一致な音を聞いているということに等しい。そういう意味で、僕みたいなCDデータを700kHz台なんかにアップサンプリングして聞いてるような者にとっては意味が無い、ということがある。非可逆であっても解凍されたデータに充分な情報量があれば問題にならないんじゃないかと思う。
次に、非可逆圧縮の「PCMであれば本来あったはずのデータが削られる」というイメージについては、MQAはAD変換からDA変換まで一連の情報処理であり、録音からPCMデータが作られる段階で、AD変換などで生じる歪みを排除する処理が行われる、と僕は理解している。つまり可逆か非可逆かと分けられるものではない。言ってみれば最初からMQAなわけだから。そういう理解。

しかし、音質がどうなのかという一点。
引用。

Roon 1.6によって「TIDAL Masters/MQAとQobuz/ハイレゾFLACを聴き比べる」ことが可能になり、比較の結果として「MQA音源は同スペックのハイレゾ音源と比較すると音質が劣る」という私自身の結論を得た。

もしその比較が妥当なら、僕もMQAには期待できない、ということになるのかな、、、
うちではmpd + libsamplerateで700kHz台へのアップサンプリングがデフォルトだ。その音は、一般的に流通しているハイレゾ音源そのまま（つまり96kHzや192kHzをDACチップでアップサンプリング）の再生音を凌駕する。ということは、MQAの再生音も越えていると予想される。
実際には聴けていないというのが歯痒いけど、、、

比較の経過は下記アドレスのエントリーに書かれている。読んでみて思うのは、、、判断は実際に聴くまでは保留かな。
https://kotonohanoana.com/archives/23505

なんというか、うちでやってるmpdで700kHz台に上げるというのは、どうなんだろう。一般的な音質比較の対象としていいものかどうか。
MQAは176.4kHzとか96kHzで、MQA対応DACは、そこからどういうフィルタリングをするのだろうか。
上位の周波数にアップサンプリングするのかいな？
しないのなら、700kHzのほうが有利に決まっていると思うし、時間軸の正確性はどうなるのか、、、
使うDACによっても違うだろう。CHORDのDACとかPCM再生が得意なはずだけど、どうなんだろうね（僕はCHORDのDACは聴いたことがないのだ）、、、

最近、うちでオーディオを聴いていて気になるのは「録音」だ。
日本のポップミュージック、特にボーカルの多くに、僕は違和感を覚えるようになった。生の人の声に聞こえないのだ。洋楽だったらロックとかでも、まだ生の人の声に聞こえるのが多い。
とはいっても、そんなにたくさん聴いて確認したわけじゃないので、現時点での印象にすぎないのだけど。

これは何なんだろうと考えるうちに、日本のポップミュージックの録音は、生の声ではなく、コンサート会場のPAを通した歌声を再生しようとしてるんじゃないか、と思い付いた。いくらなんでもそんなことはないだろう、とは思うのだけど、、、でも、コンサート会場やカラオケルームでマイクを通した声が、リビングルームのコンポから鳴るように録音されているのだとしたら、「そうそう、そういう感じの音だよ」と納得がいくというか。
歌声が生の声として再生されるような録音になっていないと感じるのだ。若い人のJポップに限らない。ベテラン歌手の作品でもそういう音がするのが少なくない。必要ないエコー成分が多すぎたり、人の声はこんなガサ付き方しないだろという感じに聞こえたり。
日本のポップミュージックの特徴じゃないのか、と思う。そうした音が似合う音楽が作られているし、たぶん、そうした音楽を再生するのに適したコンポが作られている。

これは、一種の文化的なフィルターとして機能していると思う。
リアルな生の人の声が生きるポップミュージックは、日本ではほとんど作られていない。

僕は最近、リアルな人の声を聴きたいと感じる事が多くて、その結果、はまっているのがアメリカのフォークミュージックだ。ジョーンバエズとかピートシーガーとか、あのあたり。日本の音源で何かないかとなると、再生音に何か違和感を感じる。たぶん録音の、音の問題だと思うのだ。本当はこんな不自然な声じゃないはずだ、と感じることが多い。

現在流通してるハイレゾ、96kHz、192kHzといったレベルだと、そこまで気にならない、というか、気付かない。ラジオやテレビの人の声に違和感を感じないようなものかな。おそらくフォーマットによって違ってくるんだと思う。案外、アナログレコードがうけてるのは、この辺りに理由があるんじゃないかと思っている。受け皿に乗ってるデータが、相対的に上質なのだ。
PCMで700kHzまで上げると、何かしら、圧倒的な差が生じてしまう。まともな録音じゃないと、きびしいのだ。受け皿が大きい分、質の悪さも目立つというのかな。拡大鏡みたいなものなのかもしれない。良質な録音だと素晴らしいのだけど。

MQAは録音段階にも踏み込んだ処理を行う。そういう意味で、MQAには期待する部分があった。
しかし録音のクオリティは、MQAかどうかみたいなフォーマットの差異だけではカバーしきれない部分がむしろ大きいだろうと感じている。実際、昔から録音の善し悪しは千差万別だからね。

良質な録音にMQAの処理が加わると、さらなる音質向上が見込めないかと考えたり、MQAで700kHz台にとか将来的にはどうなのかと思ったりする。
しかし700kHz台のPCMは相当のクオリティで、上流再生レベルの受け皿としては、これでもう十分じゃないかと思わせるものがあるのだ。個人的感覚的な物言いで、実際どうなのか分からないけど。
受け皿が大きい分、録音自体がよいかどうか、丁寧に録られているかどうかがこれまで以上に重要になってくると思う。
録音に合わせた再生をどうするかも重要ということになるのかな、と思っている。

うちにはhp社のCompaq 6730bが4台ある。先日までは3台だったが、増えて4台だ。
windows7が1台、Fedora27が2台。Tiny coreでアップサンプリングを試してるのが1台。同じ機種ばかり何台もあるのは、その方が機種固有の知識が少なくて済むということと、どれかが故障した時に簡単に代替が効くからだ。
今回、数が増えたのは故障のせいで、中古パソコン屋から新しいのが来るまでの間、思惑通りに他の機体で代替できたので、大きく困ることはなかった。

そんな6730bなんだけど、Fedora28をインストールしようとしたら上手くいかずに諦めたことがある。それ以降、どうもその機体が不調つづきで、今回、29をインストールしようとしても出来ず、というか、インストールしても起動せず「TPM Error 2」と表示されて、先に進まない。ついにはエラー表示もまともに出来なくなった。
諦めて、27に戻そうとしたら、内蔵HDDからは起動できなくなっていた。usbからの起動は可能なんだけど。
こんなことってあるのか？と調べたら、OSインストールでBIOSが壊れることがあるんだな。

Ubuntu 17.10にBIOSを「破壊」するバグが発覚！原因は？対応策はあるのか？問題の詳細と現状まとめ | Linux Fan
https://linuxfan.info/ubuntu-17-10-corrupting-bios

Insyde Software社のUEFIはHPでも採用してるようだけど、6730bがそうなのかはよく分からない。
fedoraをバージョンアップ出来ないのは、うちだけじゃないらしい。

Can't install F28 on my laptop, F27 installation works
https://forums.fedoraforum.org/showthread.php?318093-Can-t-install-F28-on-my-laptop-F27-installation-works

Bug 1582810 - F28 Workstation, GRUB loader bug : After booting in Windows, then Linux, there is a "TPM Error 2"
https://bugzilla.redhat.com/show_bug.cgi?id=1582810

そんなわけで、普通には使えない6730bが1台できたというわけだ。

内蔵HDDから起動できないというのは、BIOSをインストールしたら治るのかね？、、、
usbから起動できるならTiny Core Linuxは使える。日常的な使用に組み込み向きのTiny Coreはきついかな、、、
でも、音楽サーバーにはなるんじゃね？
apu2c4（今はもう売ってないんだね。apu2d4になっている）は安定して運用継続中なんだけど、他の機械でどうなのか試してみるのは面白そうだ。apuと同じCorePure64-7.2とmpd-0.19.19をインストールして、768kHzへのアップサンプリングを較べてみた。

スペックだけど、
apu2c4は、AMD GX-412TC（1GHzクアッドコア）に、メモリはDDR3-1333、4GBで固定。
6730bは、Intel Core 2Duo P8600 (2.40GHzデュアルコア）に、メモリは800MHz DDR2、1〜8GBで変えることができる。
メモリはapu2c4のほうが速い。
CPUの差は知識もないので分からない。6730bのほうが上等と思っていいんだろうか。
今回、6730bのメモリを1、2、4、6GBと変えて音楽連続再生してみた。最大の8GBは手持ちのメモリ基板が足りなくて試していない。

まず1GBで始めてみた。
音は悪くない。意外と行けるか、と思ったらじきにjitteringというのかな？、鈴を振るような雑音が聞こえ始める。さすがにCPUが速くてもメモリ1GBは足りないかな。ちなみにras pi2のメモリはLPDDR2で単純比較はできないけど、同じ1GBでも6730bのほうが余裕があるようだ。
2GBだと、もう少し持つけど、やっぱり雑音が。
4GBだとかなり行ける。やはりメモリは4GB必要なのかと思っていたら、1時間ほど鳴らすうちにjitteringが。
6GBでどうか。、、1時間ぐらいで時にプチノイズが出て、その後は落ち着いたかと思ったけど、1時間半でjittering、、、
ということは、DDR3なら4GBあれば十分と思われ（減らせるかどうかは試せない）、DDR2なら6GBでも足りない、ということかな。jitteringが乗ったら、一時停止して再生再開したら正常に戻る。何かの処理が滞ってそんなノイズを生じるのだろう。

CPUの違いによる差異はというと、端末画面でsshからtopを打つと%CPUは25%強でそんなに変わらなかった。
それ以上の事はよくわからない。
実際のところ、機械によって必要なメモリとかスペックは違うだろうし、今回はこんな結果でした、という以上の結論は出ないと思う。

ちなみにapu2c4と6730bで、音質比較は難しかった。
ブラインドでは絶対わからないし、そうでなくても明確な指摘はできない。
やや6730bのほうが落ち着いた音色に聞こえるような気がするが、気のせいだと思う。そもそも1時間過ぎたらノイズが乗る。

768kHzアップサンプリングの音質について書いておく。

うちの女房は僕よりも音質に厳しかったりするんだけど、子供の頃のかなり厳しいピアノ教育の賜物で、音楽が鳴っていたら頭の中で勝手に音符に返還されるんだそうだ。何かしたいこと（例えばメールの文面を考えるとか）をしてる時でも、音楽が鳴っていると本人の意思とは関係なく脳が採譜を始めてしまうので、非常に困るのだという。最近は子供がピーナツにハマってて、いつも「Linus & Lucy」とか「Skating」を聞きたがるんだけど、繰り返し聞かされてウンザリだと言っていたのだ。
その女房が、768kHzになったら「これならいつでも鳴らしていい」と言ったのだ。
ちょっと信じられない。
いったい、なにが今までと違うというのだろう、、、
まあ、その後、実際にいつ鳴らしてよくなったかといえば、そうでもないんだけどさ。

以前、初めて384kHzで鳴らした時は、明らかに192Hz以下とは違うステージの音だと感じた。
これ以上に上がるのかと思っていたんだけど、実際、768kHzにしてみたら上がってしまった。
使用するDACによって違うだろうとは思う。
ブラインドで分かるかと言われたら微妙なところ。分かる人には分かるんじゃないだろうか。

高音域はより肌理細かくリアルに。それは想定内だったんだけど、中低域の見通しが良くなったのは意外だった。
いや、スーパーツィーターで低域が改善するのをずっと昔に体験してるので、高域を改善すると低域も改善するというのは当然有りだとは思うんだけど、今回の改善の仕方はそれとは何となく違うのだ。
上流の段階で改善してるのが分かるという感じ。
低音の質感、リアリティが上がり、かなり聴き取りやすくなった。低域のhi-fi再生のリアリティってこういう感じで良くなるものなんだ、と初めて知った気がする。たぶん、スピーカーの低域再生能力が高かったら明確に表現されるんじゃないかと思う。4425mk2はサイズの割に下まで伸びてるとはいえ、キャスターを使ったセッティングは最低域を支えるには限界があるだろうと思う。

なんというのか、、、
384kHzまでは、音が良くなる度に、これ以上の音があり得るのか？と感じていたんだけど、768kHzを聞くと逆に、ああ、これ以上の音ってありだ、と感じた。更なるオーディオ再生の高みがあると確信したというのか。まあ、うちのシステムレベルでは上があって当たり前なんだけど、そういう話ではなく、オーディオ技術的に目指すべき場所的な感覚で。
技術者ではない自分がそういう感覚を持ってしまったのが意外なところ。
だから、そういうレベルを目指すのかと言われたら、最早どうだか分からないという感じ。そういう心境になるのもよく分からないところだ。

Raspberry Pi2をPCトラポとして運用しているんだけど、やってみての感触から受ける印象だけなんだけど、384kHz以上へのアップサンプリングはRas Pi2初期型ではハードウェア的にいっぱいかな、という気がしている。
つまり384kHzが限界なのだ。
768kHzへのアップサンプリングは頑張っても出力できないだろうと思う。
DACを新しくしたのは700kHzの音がどうなのか確認する意味もあったので、ちょっと残念な状況。
そこでどうしたらいいか、ということを考えてみた。

まず、ハードの限界と考えるのでハードを変える。
選択枝として、まず「Raspberry Pi 3b+」が考えられる。
CPUのスペックが900MHzから1.4GHzに5割増し。うちのPi2は初期型なので、ARMv7からARMv8(64bit)にもアップすることになる。つまり64bit化が可能になる。メモリは1GBで変わらない。

課題がいくつか。
900MHzから1.4GHzへのアップで、どの程度の改善が見込めるのかという点がまず１つ。
64bit OSで使えたら処理能力アップが見込めるけど、使えるのかという点が２つめだ。

どんなOSが使えるのか。
今使っているpiCoreは、3b+への対応待ちで使えない。そして64bitへの対応はいつになるかも分からない。
raspbianは3b+で使えるけど64bitには対応していない。32bitだ。
この際なので64bitで使いたい。
ということだと、実はUbuntu、Fedora、Arch Linux、openSUSE、、と、いろいろ3b+に対応したOSがあったりする。どれか選んで、mpdをインストールして使うということになる。

ハードの選択枝はRas pi 3b+だけではない。
実は以前に、PCEngines社の「apu2c4」を入手していた。4GBのメモリを積んでるのでRAMメモリ再生機として使うつもりで入手したんだけど、結局、Ras Pi2で運用継続してしまったので、しまい込んだままになっていたのだ。
CPUはAMD 1GHzクアッドコアでほぼRas Pi2と同等だが、OSにRas Pi2で使い慣れたpiCoreの同系「Tiny Core Linux」のCore Pure 64か、dCore x86_64が使えるのではないかと思う。Tiny CoreはRAM上で動くというのも優位性と考えられる。
問題は、このハードは触らないまま今まで来てるということ。
つまり勝手が分からないのだ。
しかし勝手が分からないのは3b+でFedoraとかでも同じだ。

そんなわけで、まずapu2c4をTiny Core 64bit OSで動かしてみることにした。
参考にさせていただいたのは下記のサイト。

Tiny Core 6.1 64bit版のインストールと、dockerを動かそうとしたメモ
https://qiita.com/tukiyo3/items/d61b2054560451c47fdc

メモリ再生（8）~64bit版 Tiny Coreを使ってみる。~その1(イメージファイル配布)
http://flac.aki.gs/bony/?p=3535

インストールしたのは、CorePure64-7.2.iso。
CorePure64-9.0.isoは、SDカードへのインストールまでは出来たけどapu2c4で動かそうとしたら上手くいかなかった。
CorePure64-8.2.1.isoは試していない。

難儀したのは、なにしろ取り掛かって実際に触ってみないと、何をしたらいいのかよく分らなかったこと。何回か繰り返すうちに、だいぶ慣れた。
あと、OSインストールのベース機に使った64bitノートパソコンは日本語キーボードだったので、sshd_config.origのコピーに際して"_"の入力方法が分からなかったこと。Tiny Core OSには日本語キーボードのキー配列設定が入ってないのだ。
ネットで英語キーボードの配列を調べてなんとかした。「shiftキー」+「-キー」で"_"が打てた。
sshで接続したら、あとは概ね大丈夫だった。

tc@box:~$ uname -a
Linux box 4.2.9-tinycore64 #1999 SMP Mon Jan 18 19:59:34 UTC 2016 x86_64 GNU/Linux

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

これで、768kHz/32bitへのアップサンプリングを問題なく再生できるようになったかな、、、
今のところ、1時間以上連続再生してもノイズはない。
Tiny Coreの32bit OSだったらどうなのかは試していない。 音質評価はまだしていない。
でもとりあえず、シンディローパーのタイムアフタータイムが素晴らしく生々しい感じ。

以下、インストールのコマンドや記載内容など流れを羅列。
実際に触ったことがない人が見ても良く分からないと思うけど、自分用の備忘録だ。

##################    (boot 64bit PC CorePlus-current.iso CD-ROM No X/GUI : install openssh)
sudo passwd tc
tce
s
ssh
7 : 7. openssh.tcz
q
i
q
sudo /usr/local/etc/init.d/openssh start

##################    (change machine : ssh login 64bit PC : install tiny core OS to SD card)
ssh tc@192.168.1.64

tce-load -wi tc-install.tcz
wget http://tinycorelinux.net/7.x/x86_64/release/CorePure64-7.2.iso

cp `which tc-install.sh` .
sed -e 's/vmlinuz/vmlinuz64/g' -e 's/core/corepure64/g' tc-install.sh > tc-install64.sh

### (insert SD card) ###
fdisk -l
sudo sh ./tc-install64.sh

i :iso-file
/home/tc/CorePure64-7.2.iso
f :frugal
2 :partition
4 : 4. sdb1
y : Would you like to install a bootloader?
Press Enter key : (Install Extensions from this TCE/CDE Directory)
4 : 4. ext4
y : Mark sdb1 active bootable? y/n
vga=normal syslog showapps waitusb=5 : Enter space separated boot options
y : Last chance to exit before destroying all data on sdb1

Installation has completed
Press Enter key to continue.

sudo poweroff

##################    (change machine : boot 64bit PC SD card : install openssh, nfs)
uname -a
sudo passwd tc
tce
s
ssh
6 : 6. openssh.tcz
q
i

s
nfs
3 : 3. nfs-utils.tcz
q
i
q

cd /usr/local/etc/ssh
ls
sudo cp sshd_config.orig sshd_config
sudo /usr/local/etc/init.d/openssh start

##################    (change machine : ssh login 64bit PC : basic setting SD card)
vi .ssh/k*
ssh tc@192.168.1.64

vi /opt/bootlocal.sh

/usr/local/etc/init.d/openssh start
/usr/local/etc/init.d/nfs-client start
mkdir /mnt/music
mkdir /mnt/music/ariel
mkdir /mnt/music/titan
chmod -R 777 /mnt/music

vi /opt/.filetool.lst

etc/shadow
etc/passwd
usr/local/etc/ssh/sshd_config
usr/local/etc/
etc/fstab
etc/securetty
etc/inittab
sbin/autologin
/opt/bootlocal.sh

vi .ashrc

alias titan="sudo mount -t nfs 192.168.1.80:/titan /mnt/music/titan"
alias ariel="sudo mount -t nfs 192.168.1.120:/ariel /mnt/music/ariel"

filetool.sh -b
sudo poweroff


##################    (change machine : boot apu2c4 SD card)

##################    (change machine : ssh login apu2c4 : mpd install, setting)
ssh tc@192.168.1.90

tce-load -wi \
ncurses-dev.tcz ncurses.tcz make.tcz gcc.tcz compiletc.tcz squashfs-tools.tcz \
perl5.tcz bash.tcz automake.tcz bc.tcz glib2-dev.tcz boost-dev.tcz icu-dev.tcz \
pkg-config.tcz glib2-python.tcz dbus.tcz dbus-dev.tcz flex-dev.tcz gdbm-dev.tcz \
bison.tcz binutils.tcz autoconf.tcz libtool-dev.tcz bc.tcz cmake.tcz

tce-load -wi \
libsamplerate.tcz libsamplerate-dev.tcz \
alsa-config.tcz alsa-plugins.tcz alsa-modules-4.2.9-tinycore64.tcz alsa-dev.tcz alsa.tcz \
lame.tcz lame-dev.tcz libmad.tcz libmad-dev.tcz flac.tcz flac-dev.tcz curl.tcz

wget https://www.musicpd.org/download/mpd/0.19/mpd-0.19.19.tar.xz
xz -dv mpd-0.19*
tar -xf mpd-0.19*
cd mpd-0.19*
./configure
make
mkdir ../mpd
sudo make DESTDIR=../mpd install
cd
mksquashfs mpd mpd-0.19.19.tcz
md5sum mpd-0.19.19.tcz > mpd-0.19.19.tcz.md5.txt

ls /mnt
ls /mnt/*1
ls /mnt/*1/tce

sudo mv *tcz* /mnt/*1/tce/optional
sudo vi /mnt/*1/tce/onboot.lst

vi .mpdconf

sudo rm -rf mpd*
cp /mnt/*1/tce/onboot.lst onbootlst.txt
sudo vi /mnt/*1/tce/onboot.lst
filetool.sh -b

ほとんど.ash_historyファイルとかからのコピーとか。
ipアドレスとかパーティションやディレクトリのNo.とか、環境が違ったら他の数値になったりすることがあると思う。

最近、ADI-2 DACがメインのDACになった。
導入した目的には384khz以上にアップサンプリングして聴くというのがあって、なんとか出来たので、顛末を書いておく。

ADI-2 DACを導入して以降、ras pi 2/ppap/192khzで聴いていた。
普通に384khzで継ぐと、リーン、、、と、薄い金属が震えるような雑音が再生音に乗るのだ。jitteringっていうのかな。多少、プチプチいうノイズもある。ネット上にはADI-2 Proとras pi 2のケースで報告がある。以下引用。

https://www.forum.rme-audio.de/viewtopic.php?id=25703
RME User Forum

Volumio installation was straight-forward but I am getting some jittering (clicks) during the playback.

ADI-2 DACにはWindows用とMac OSX用のドライバが付属していて、これでusb接続を最適化していると思うんだけど、Linux用のドライバはないので、こっちが工夫しないといけない。

一時はras pi 3b+を導入して無線LANでNASマウントしてusb出力したらどうだろうか、などと考えていたんだけど、5ちゃんねるに書き込みがあって、3b+の有線lanが微妙ということらしい。それって、3b以前はどうなんだろうか。
無線lanを使う分には問題ないのかな、、、下記は書き込まれていたリンク。

https://volumio.org/raspberry-pi-3-b-plus-audio-review/
THE NEW RASPBERRY PI 3B+ AUDIO-RELATED REVIEW

As usual, I started playing my “Raspberry killer” track: a 32 bit, 678 kHz .wav file from my NAS. And… What a terrible disappointment: loads of crackles and a whole lot of lost packets.
Tried then with DSD, 24/192 flacs, and even 16/44.1 flacs. All sounded just terrible. So, indeed the new USB BUS did change USB Audio performances, unfortunately, it did for the worst.

Luckily though, I then tried to play the same files from a USB drive (and not from a NAS), and magic happened: spotless playback up to 32\768. Seemed that taking ethernet (I was connected on wired connection) out of the equation did the trick. So connected the PI via wifi and restarted without ethernet: same result, HI-Res Music playback was just perfect to my USB DAC.

しかし、他の解決策も5ちゃんねるにあった。下記、引用する。

ethtool -K eth0 tx-tcp-segmentation off tx-tcp6-segmentation off
（イーサネットチップで行っているパケット処理をオフにしてCPUで行うなうようにする）
パケットロスの発生はドライバのできによるものらしいのでベースのOSでドライバ更新されればvolumioにも反映されるようです（直す気があるかどうかは不明）

上記コマンドによる設定変更は記憶されないのでもしうまくいった場合/etc/rc.d/init.d/localにコマンド書き込んで起動時に自動実行させる必要があります
ギガビットイーサの速度が出ないときの対策なので今回の件にあてはまるかは未知数ですけどね

これは実は、piCore、pi 2用の対策ではないのだけど、
書き込みを参考に、ras pi 2/piCore9で、ethtoolを使ってみた。
他の書き込みによると、moode audioではデフォルトで設定されているらしい。
ethtool -s eth0 speed 100 duplex full というコマンドも対策として上がっていて、3b+だと有効な場合があるようだ。

tce-load -wi ethtool-doc.tcz ethtool.tcz
sudo ethtool -K eth0 tx-tcp-segmentation off tx-tcp6-segmentation off

どうも、自分が何をやってたのか、はっきりしないんだけど、、、
インストールして設定のコマンドを打って、nasマウント/384khzでノイズなしで聴けるようになった。768khzでも、設定前には全く音が出なかったのが、数秒だけど音が出る。残念だけどその後は途切れ途切れになる。
volumio2を試した時は768khzでも音が出たんだけど、プチプチノイズが乗るので使用を諦めた。384khzでもときどきある。piCore9で768khzだと途切れ途切れでプチプチノイズどころではない。反面、384khzだと問題なく聴ける。
この辺、何処をどういじったら違ってくるのか、よく分からない。

音を比較したら、nasマウント/384khzのほうがppap/192khzより少しだけ細やかな音がする。ごちゃっと塊のように聴こえていたオーケストラの弦楽が、ほぐれて滑らかに聴こえてくる感じ。少しだけの変化なんだけど、音楽としては案外大きな違いに感じられる。

しかし、この時点ではppapのras pi 2はethtoolによる設定をしていない。同じ設定をしないと単純な比較はできないと思った。

ethtoolをインストール。
ethtool -k eth0、ethtool eth0 で設定前の状態を確認。
sudo ethtool -K eth0 tx-tcp-segmentation off tx-tcp6-segmentation off で設定、、、
ethtool -k eth0、ethtool eth0 で設定後の状態を確認、、、設定表示に変化なし。
なんなんだろうこれは。。。

実は、nasマウント/384khzのほう、コマンドを打つ前と後で設定表示の変化を確認していなかったことに今更気付く。ということは、コマンドが本当に効いたのかどうか、実は分からないということなのか？
5ちゃんねるの書き込みには設定変更は記憶されないとあるが、どうも、picore9だと、記憶されているような。というのは、リブートしても効果が続いているからだ。
いや、それって、コマンドで設定変更されてないという可能性もあるんじゃないのか。

piCore9を1から焼いて試してみる。
結果から言うと、、、どうも、ethtoolは関係ないらしい。インストールしなくても384khzの音が出ている。
現在の.mpdconfの設定は下記のような感じ。

samplerate_converter                "Fastest Sinc Interpolator"
audio_output_format                 "384000:24:2"

audio_buffer_size "32768"
buffer_before_play "20%"

audio_buffer_size を奢るというのが決め手だったらしい。
そうなのか？おっかしいなあ、、、

さて、改めて、音の方はというと、やはり情報量はnasマウント/384kHzのほうが多い。音の勢いは、ppap/192kHzのほうがあるように聴こえる。この辺り微妙で、でもよく聴くと、ppap/192kHzは微かに音が滲んでいるせいで強く聴こえるということが分かる。nasマウント/384kHzのほうが正確だ。

例えばジョージウィンストンのLinus & Lucyとか聴くと、ppap/192kHzだと「この重いピアノの音は何？」って思うんだけど、nasマウント/384kHzだと「ああ、重い音なんだこれは」と納得がいく感じ。楽器の特性によるものか演奏の仕方によるものか僕には判断が付かないけど、ニュアンスが伝わって音色を理解しやすくなる。
アストラッド・ジルベルトのデビューアルバムも、以前は眠たく甘ったるいだけの声で蓼食う虫も好きずきだと思っていたのが、384kHzにアップサンプリングしたら、表情があるリアルな女性の歌声だと分かるようになった。今回、改めてこの音源の音質について調べて、実は初期のアナログプレスで「VAN GELDER」の刻印があるのが音がいいとされている、ということを初めて知った。正直、以前だったらそんなこと調べる気にもならなかったんだけど。

nasマウントでここまで音の表情が出るんだから相当だと思う。
なんだかノウハウの信憑性に疑問があるが、とりあえず音が出て、その音がいいので、今のところはそれでいこう、という感じ。

ついでに、/mnt/mmcblk0p2/tce/onboot.lst を編集してシステムを軽くしておく。

mc.tcz
openssh.tcz
boost-dev.tcz
libsamplerate-dev.tcz
libsamplerate-doc.tcz
flac-doc.tcz
libcue.tcz
libcue-dev.tcz
icu-dev.tcz
libid3tag-dev.tcz
libmad-dev.tcz
mpg123.tcz
mpg123-dev.tcz
mpg123-doc.tcz
lame-dev.tcz
lame-doc.tcz
libmpdclient-dev.tcz
libmpdclient-doc.tcz
alsa-oss-dev.tcz
alsa-oss-doc.tcz
alsa-plugins-dev.tcz
alsa.tcz
alsa-utils-doc.tcz
alsa-utils-locale.tcz
mpd-0.19.19.tcz

音の変化は、どうなんだろうなあ、、、正直、明らかな変化は感じない。悪くなってはいないと思う。
サンプリング周波数が高くなると変化が目立たなくなるんだろうか。

768kHzではどうなのかという課題がある。

前述のpi 3b+のレビューでは、usbメモリの768khzハイレゾファイル再生に問題なしとある。うちはアップサンプリングするので、それよりも負荷は多い。 しかも、pi 2でどうなのか。LANがボトルネックということなら、RAMメモリ再生でどうなのか。

44.1/16ファイルの768khzアップサンプリング再生を試してみる。「audio_buffer_size」を90000まで上げる。音が出始めるまで数十秒かかり、音が出て数十秒間は再生できた。その後は途切れ途切れで音楽にならない。audio_buffer_sizeが小さい値だと、最初から途切れ途切れになる。
どういうんだろ、libsamplerateでアップサンプリングするのが間に合わないのかな。もしかしたら、SoXだったら上手くいくかもしれない。しかしpiCore9でSoXはリポジトリにsoxr.tczがないので使えない。

オーバークロックしてみるという手があるかも。

arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6

こんな設定で鳴らしてみたら、実用にならないのは同じだが、多少マシになった。
ということは、ras pi 3b+のほうが可能性があるということか、、、

さて、piCore7はppap/192kHzが上手くいかなかったから最近は使ってなかったんだけど、オーバークロックしてSoXのアップサンプリングが使える。と思って、やってみたけど、ダメでした。192kHzでもjitteringが乗る。
192khz以上のアップサンプリング音源をADI-2 DACで聴くには、piCore9以降が必要みたいだ。

将来的には、ppapで384kHz以上が使えるようになったら使ってみたいと思う。

あと、Ras pi 3b+を入手して、無線でNASマウントしてみたい。
lanとusbを1チップで処理するras pi 2はusbオーディオでは不利だ。3b+なら無線LANとusbで、入出力の処理を別の経路に振り分けることができる筈だ。前述の3b+のレビューによると無線lanは使えそうだ。
問題は、piCoreがまだ3b+に対応してないこと。対応するのはpiCore10で、現在はベータ版がリリースされている。いろいろ手を入れて使うにはスキルが要る。普段使ってないが、raspbianでいいじゃんという考えもある。piCoreが対応するまでのつなぎには充分かな。余裕ができてからか。

先日、リサプラーによって再生音の定位に違いを生じるかどうか、libsamplerate使用、SoX使用、アップサンプリングなしの音を比較試聴し、違いがあることを確認した。
DACは、nano iDSD LE。

このとき、libsamplerate、44.1/16へのリサンプリング有る無しで聴き比べたが、違いがあった。
libsamplerateを通した音はlibsamplerateの音になる。
同じ44.1/16でも、リサンプラーを通すとリサンプラーの音になるのだ。

SoXと比較して、libsamplerateのほうが音への影響が良くも悪くも大きいと思う。libsamplerateはDA-AD変換をシミュレートするので、言ってみれば元から全てデジタル信号を再構築するわけだから、音が違って当たり前と、言おうと思えば言える。
しかし、デジタル信号自体が違うから音が違う、でいいのか？

前回の記録から試聴結果を引用してみる。順序は変えている。

44.1/16、リサンプリングなし。(NAS original音源)
チェロは右、SoXの時ほどじゃないけど、目の高さより若干高いことに気付いた。
ボーカルは中央、正面やや上に上がった。1分20秒すぎのボーカル、高音の響きが上～左向きに。２分台後半、やや右、後方に揺れる。
バス、ほぼ中央。

44.1/16 (NAS resample音源)
チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。２分台後半、響きが右、後方に向かう傾向が強い。 バス、ほぼ中央右。

44.1/16、リサンプリングなしでCCモード (ppap original音源 DAC:fireface UCX)
チェロは右、目の高さ。nano iDSD LEのときよりやや内側に寄る。
ボーカルは中央、正面やや上。しっかり肌理細やかに鳴る。1分20秒すぎ、高音の響きは上～左右に広がる。２分台前半、定位はしっかりしている。後半、響きが右、後方に向かう。
バス、中央右。

なんというか、定位について書かれている文面だけ見たら、LEでのオリジナル音源再生より、リサンプリングした音源の再生のほうが、UCXによるオリジナル音源再生に近いように見えなくもない。そして実際、聴いた音色の感触はそう感じられた。
リサンプリングすることに優位性があるなら、それは何処から生じるのか。
オリジナルデータのほうが正確なのは当たり前だ。リサンプリングがジッター低下につながる理由を探さないといけないってことだ。

構成図を見ながら考えてみる。

オリジナルデータ再生の場合は、NASからnfs経由で送られるflacデータをmpdがデコードしてalsaに送っている。
リサンプリングする場合は、NASからnfs経由で送られるflacデータをmpdがデコードしてlibsamplerateでDA-AD変換シミュレートし、そのデータをmpdがalsaに送っている。
ここで考えたのは、DA-AD変換シミュレートに際してデータがどこかにバッファされるはずだ、ということ。バッファされたデータを送り出すほうが、ジッターが減るのではないか。もともとmpd.conf上にバッファを設定する項目はある。しかしlibsamplerateのDA-AD変換シミュレートに使われるバッファは、たぶん別に用意されるはずだと思う。
バッファされたデータを送り出すということなら、RAMメモリ再生に近いと言えるかもしれない。

RAMメモリ再生で44.1/16にリサンプリングしたら、どう聴こえるだろうか。
試してみよう、、、と思ってた矢先、、、
、、、
nano iDSD LEが壊れたみたいだ、、、
入力の認識はしているようでインジケーターの色も変わるんだけど、音が出なくなった。

i2s DACでやってみようか、、、
聴こえ方がどうか、最初からしないといけないのか、、、
ppapのUCXと定位に差がなかったら、比較できないってことだな。

そういうわけで、piCore7でi2s DACを鳴らす環境をさっさと構築する。
というか、nano iDSD LEに繋がっていたras pi2からmicroSDを抜いて、config.txtを設定して、i2s DACを刺したras pi2に刺し直し、起動させるだけだ。
USBターミネーターは刺すけど、面倒なのでケースなしだ。

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1862     1 tc       S     133m 14.3   0 15.5 mpd

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1894     1 tc       S     133m 14.3   0  7.5 mpd

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1879     1 tc       S     133m 14.3   0  0.6 mpd

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 1911     1 tc       S     133m 14.3   0  0.6 mpd

これはlibsamplerateによるアップサンプリングを行っている時のtop表示。
上が順に、192/24、96/24、44.1/16、44.1/16リサンプリングなし、だ。
サンプリング周波数が高いほど、CPU使用が多くなる。44.1/16はリサンプリングしようがしまいがCPU使用率が変わらない。それでも先日、聴き比べた時には確かに音は変わって聴こえたわけで、どこかで何かが何かしてるんだろう。

試聴だ。
音源は前回と同じ、幸田浩子「カリヨン」1曲目、カッチーニのアヴェ・マリア。

まず、リサンプラーなしの44.1/16、NAS音源。
チェロは右、目の高さ。、、これはUCXよりも中央寄りか？
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上向きに広がる。２分台前半、定位は比較的安定。後半、響きが上、右、後方に向かうけど、、定位自体は安定感がある。
バス、ほぼ中央右。

次、リサンプリングありの44.1/16、NAS音源。、、柔らかくなる。
チェロは右、目の高さ、、、だけどリサンプラーなしのNAS音源より、さらに内側に聴こえる。右中央？
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは広がるが、、そんな上にいかない。２分台前半、定位は安定。後半、響きが横には向かわない、やや後ろに向かうことあり、、、定位は安定感がある。
バス、ほぼ中央右。

次、リサンプリングありの44.1/16、RAMメモリ音源に替える。
チェロは右、目の高さ。あれ、、NASよりも外に。
ボーカルは中央、正面やや上。NASより少し低め。1分20秒すぎのボーカル、高音の響きは少し上に広がる。２分台前半、定位は安定。後半、響きは横には向かわない、やや後ろに向かうことあり、、、安定感がある。
バス、ほぼ中央右。

リサンプラーなしの44.1/16、RAMメモリ音源。
チェロは右、目の高さ。NASよりも少し外で変わらず。UCXと比べてどうだろう、、、
ボーカルは中央、正面やや上。NASより少し低め。1分20秒すぎのボーカル、高音の響きは少し上に広がる。２分台前半、定位は安定。後半、響きは横には向かわない、やや後ろに向かうことあり、、、やはり安定感がある。
バス、ほぼ中央右。
リサンプリングのあるなしで、ほとんど変わらない。

リサンプラーなしの44.1/16、NAS音源に戻る。RAMと比べると少し硬いかな。
チェロは右、目の高さ。RAM音源のときよりも5度ほど内側にいるみたい。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上向きに広がる。RAMより広がりは大きい。２分台前半、定位は比較的安定。後半、響きが上、右、後方に向かうけど、、定位自体は安定感がある。
バス、ほぼ中央右。

UCXで聴いてみる。リサンプラーなしの44.1/16、ppap方式。
チェロは右、目の高さ。NASよりも少し外。RAMメモリ音源と同じ位置。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは上に広がる。２分台前半、定位は安定。後半、響きは右からやや後ろに向かう。 バス、ほぼ中央右。

さて、、、図にしてみよう。

チェロの位置が変わるけど、どう評価したものやら。
本来は、リサンプルされたNAS音源の位置が正しいんだろうけど、より高性能なはずのDAC、fireface UCXの再生に近いのはRAM音源再生だ。そもそもコントラバスが中央で、本来の位置の右側から大きく外れているので、正確な再生はできていない中での試聴なので仕方ないかも。

ソプラノは、今回は前回よりも安定して鳴った。
定位のぶれが少ないのだ。
i2s DAC、侮れない。
数千円で買えるHATだから高級な音は望むべくもないので、普段はテスト用やサブシステムで使ってるけど、基本を押さえた音がする印象が以前からある。しかし空間を表現する音が少ないという弱点が逆に良い方向に作用したのかもしれない、のかな？

音色は、リサンプラーを通した音はRAMメモリ再生に近づくと言えば近づく。ソプラノの聴こえ方、響きの出方も似ている（試聴記録の文面、全く変えてないのは我ながらどうかと思うね、、）。
しかしチェロの定位が全く違う。これは、前回の結果と逆になったということだ。
そんなわけで、簡単に結論が出るもんじゃないんだろうけど。

今回はこのくらいにしておく。

piCore7をpiped pcm audio playのフロントにしたので、最近はこれで鳴らしていることが多い。mpd出力も使うんだけど随分減った。
いろいろあるんだけど、整理がてら書いていく。

まず、ppapだとsoftwareボリュームが使えない（4月8日、追記。これは間違い。mpd.confで設定したら使える）。
以前なら音が大きすぎるなと思ったら、ncmpcppを操作してサッと音量を下げることができたが、ppapだとアンプまで歩いて行かないといけない。出力がpipeだからデジタルで調節できないのだ。
まあ、歩けばいいんだけどさ。
何か手立てはないかと思ってるんだけど、できていない。
フロントでalsaからncatに送るようにしたら出来るのかしれないけど、まだ十分に試みていないのだ。

そういうわけで現状、RAMメモリ再生だったらsoftwareボリュームで音量調整ができるけど、ppapならフロントにNASをマウントできるので好きな音源をさくさく選べるという、それぞれの優位性がある状況。両者の音質を比較しないといけないんだけど、これもできていない。

昨年の秋にノイズ対策でUSBターミネーター、LANにフィルターなどを追加し、USB-029H2-RPを導入したところ、音の出方がずいぶん変わった。更にppap方式も追加なので、短期間にほんとにあれこれ変わったので、途中経過が分からないんだけど、どうなってるのか簡単にまとめておく。

まず、素の44.1/16flacファイルの再生音がかなり底上げされた。
ppapで聴く44.1/16は、何しろ堅実でまっとうな再生という印象で、今まで聴いたことがなかった安定感がある。
くっきりした鮮度が高い感触は、以前よりも好ましい方向に強まっている。アップサンプリングした音の方が当たりが優しくて聴きやすいというのはあるんだけど、以前と比べたら差が少なくなった。44.1/16の特徴と思っていた若干肌理が荒い感じは減って、アップサンプリングした時の滑らかな感触に近づいている。
考えてみたら、これってRAMメモリ再生では感じなかったことなのだ。
しかし素の44.1/16でRAMメモリ再生をしたのは随分昔のことで、最近はアップサンプリングしてばかりだった。だから、再生方式による違いなのか、ノイズ対策の方が効いているのか、正確を期すなら確認する必要がある。

アップサンプリングのほうは、改善しているようなんだけど、そこまで大きな変化はない。
以前だったら、44.1/16は384kHzにアップサンプリングしたほうが情報量が多いと言えたんだけど、今は軽々しく言い難い。ちゃんとソースを選んで本腰入れて比較しないと、実際のところがどうなのか分からない。
じゃあ両者の再生音は近づいたのかというと、聴いた感触の違いはむしろ今の方が大きい。
オーディオ的にどちらが優位かがはっきりしなくなり、素の44.1/16の安定感とアップサンプリングの感触の良さ、そういう聴こえ方の嗜好のほうがむしろ、選択に影響する度合いが大きくなったのではないか、という感じ。

そういうところで、nano iDSD LEでアップサンプリングの音を確認することに、どれだけの意味があるのかな、と思うようになった。DACによって違うってことは当たり前にあるってことはあるんだろうけど、じゃあ、アップサンプリングの優位性があるかどうかはDACによる、ってことになるのかな。

以前だったら、明らかに384kHzにアップサンプリングしたほうが良くて、リサンプラーによる違いも明白だったので、ここは突き詰める必要があると思っていたんだけど、現在の音は、そこまでやる意味が減っているような。好みの問題に帰着するならするで、いいんじゃないの？という。
以前の音は、ジッターを生じやすい環境だとアップサンプリング（ハイレゾ）が有利というのに当てはまっていたのかとも思うけど。
今はそうじゃなくなった、のかなあ、、、どうなのか？

かたや、fireface UCXのほうはどうかといえば、これもあれこれあってCCモードのUSB入力になった。
SPDIF入力の時は192kHzにアップサンプリングする優位性があるように感じていた。
CCモードは96/24までなんだけど、これはアップサンプリングした方がいいのかどうか、音色はかなり違うけど分からない。どっちもどっちでいいので選択に迷う。これも先々きちんと比較する必要があるんだろうなと思う。

ああ、、、ひょっとしたら音色の感触が違いすぎるので逆に比較が難しくなってるのかな、、、

アップサンプリングについては、下記アドレスのような問題？も指摘されている。まさか定位に影響するとは。

http://community.phileweb.com/mypage/entry/2408/20180123/58315/

Ａ：44.1KHz/16bit、44.1KHz/24bit、88.2KHz/24bit、176.4KHz/24bit
　　ボーカルは中央に安定　チェロは右中央　コントラバスは右

Ｂ：48KHz/24、96KHz/24、192KHz/24bit
　　ボーカルの定位はあいまいで不安定　チェロは中央、コントラバスは中央右

というように２分されます。ＡとＢの中でも微妙な差はあります。例えば、16bitよりも24bitの方が滑らかで耳障りがよく感じる…とか、ボーカルの安定度は48KHzよりも96KHz、192KHzの方がよい…などです。ただし、その差はＡグループとＢグループとの音像定位の差ほどではなく微妙です。

アップサンプリングはトラポですることができる一方で、DACチップでも行われる。このへん、兼ね合いはどうなのか。DACチップ内で行われるアップサンプリング自体で定位が変わるということは、なにしろ製品なのだから有り得ないと、思っていいんだよね？、、、
あと、リサンプラーによって違うんだろうかとか。

そんなこんなで、これからどうしようかと思ってたけど取り敢えず、nano iDSD LEで自分なりにアップサンプリングの位置付けを明確にしよう、というところから始める。つまり、素の44.1/16から384/32までのアップサンプリング、をきちんと聴き比べてみようということ。リサンプラーも変えて。

これはppapではやりにくい。たびたびバックエンドを再起動する必要があるからだ。
あと、前回のエントリーに追記したけど、フロントにRas pi2/piCore7を使った場合、アップサンプリングで使えるのは192kHzまでのようだ。うちのppapでは、300kHz台へのアップサンプリングは聴けない。384kHzまでは確認したいので、そういう意味でも使いにくい。
だからNASマウントのmpdで設定を変えながら聴くことになる。

せっかくなので試聴に使うのは前述アドレスのサイトで話題になっている幸田浩子「カリヨン」1曲目、カッチーニのアヴェ・マリアにする。
まず、44.1/16を聴いてみる、、、
さっそく、前述のサイトで説明されているのとは聴こえ方が違う。
ボーカルは中央に安定　チェロは右中央　コントラバスは右、ということなんだけど、うちではチェロが右でコントラバスが中央あたりに聴こえる。ボーカルは中央なんだけど、歌い始めはこもり気味。数秒で落ち着いたと思ったら、その後は上を向いたり右を向いたりしてるような。録音現場の反射を多く捉えているような聴こえ方。というか、後ろ向いてるの？、、、
そういう録音なの？と思っていたら、聴き込んでる人の解説がアップされていた。

http://community.phileweb.com/mypage/entry/3255/20180127/58351/

一時は右を向いたり左を向いたりしながら歌っているためと、録音のせいにしたりしていたんです。ですが、再生側を追い込んでいくとボーカルは前に出てきて、かつ歌声もぶれなくなりました。

追い込みきれていないということらしい。なんという恐ろしいソフトか、、、
確かにうちの環境は全く反論できない状態にあるが、そうそう追い込む暇はないんだな。
しかたない。
この状況でどう聴こえるかでやってみようか、、、

実際に試聴した時系列に沿って書いていく。

まず、リサンプラーなしの44.1/16。
チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上～左向きに。２分台後半、やや右、後方に揺れる。
バス、ほぼ中央。

ボーカルは1分20秒すぎと２分台後半の定点観測と、他に気付いたことを書いていく。

リサンプラーにSoXを使用。

88.2/24

チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上に向かう。２分台後半、定位がやや右、後方に揺れる傾向あり。
バス、ほぼ中央左。

ソプラノ、口元が正面に向かない感じの時が多い。そんな聴こえ方だ。基本的にそういうソースなんだけど、それでもあれこれやってみた結果、安定して再生出来た時は比較的前を向いて歌っているように聴こえる時間が多かったように思った。

96/24

チェロは右に定位。なんと、目の高さより高くなった。
ボーカルは中央、正面やや上、やや響きが広がりぎみ、かつ響きが固い。1分20秒すぎ、高音の響きが上向き、さらに後方、左にも。２分台後半、やや右、後方に揺れる傾向あり。
バス、ほぼ中央。

176.4/24

チェロは右、目の高さ。
ボーカルは中央、正面やや上。響きが固い印象。1分20秒すぎのボーカル、高音の響きが上向きに。２分台後半、響きが右、後方に揺れるように聴こえる。
バス、ほぼ中央左。

194/24

チェロは右、目の高さよりやや高い。
ボーカルは中央、正面やや上、やや響きが広がりぎみ、やや硬い。1分20秒すぎのボーカル、高音の響きは上向き。２分台後半、響きが後方に揺れる。硬い響き。
バス、ほぼ中央。

352.8/24

チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは上～右向き。２分台後半、響きが右、後方に伸びるように聴こえる。
バス、ほぼ中央左。

384/24

チェロは右、目の高さよりやや高い。
ボーカルは中央、正面やや上、やはり、やや響きが広がりぎみでやや硬い。1分20秒すぎのボーカル、高音の響きは上～右。２分台後半、定位が右に揺れる。硬い響き。
バス、ほぼ中央。

SoXで聴いてきて、どうも44.1xのほうが伸びやかで聞きやすい印象。コントラバスの位置がなぜか44.1xで左に寄る。
48xだとチェロがやや上に上がるのと、ソプラノなど音色の響きが固くて聴き辛い印象。300kHz台となればましになるような気はしたけど、、、あんまり変わらないかな、、、

リサンプラーをlibsamplerateに変更。

一気に音色がやさしくなる！
これは違いすぎる。ここまでちょっと辛い試聴だったことに気付かされた。

88.2/24

チェロは右、目の高さ。
ボーカルは中央、正面（やや下がった）。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上向き。やさしい響き。２分台後半、響きが前にでる。3分前、後方に揺れる傾向あり。
バス、ほぼ中央右。なんとまあ、SoXとは逆になった。

96/24

チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上～左右向き。２分台後半、やや右による傾向。
バス、ほぼ中央右。

176.4/24

チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上～左右向き。２分台後半、響き、定位ともに右による傾向。
バス、ほぼ中央右。

194/24

チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上～左右向き。２分台前半、定位は右に傾きがち。２分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。

352.8/24

チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。２分台前半、定位はやや右に傾く。２分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。

384/24

チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。２分台前半、定位はやや右に傾く。２分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。

libasmplerateの場合は、サンプリング周波数による差異がSoXほど大きくない。
それと、サンプリング周波数を上げていくと順当に音が良くなっていく感触があったので、何となくいい気分で試聴できた。まあ、アルゴリズムの有り様から考えれば、サンプリング周波数での変化は少ないはずだという予測はしていた。
ものは試しと、libsamplerateで44.1/16にリサンプリングしてみた。

44.1/16

384と変わらない？w
チェロは右、目の高さ。
ボーカルは中央、正面（前と同じ）。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。２分台後半、響きが右、後方に向かう傾向が強い。さすがに384よりも硬い響き。
バス、ほぼ中央右。

聴き始めは違いがないのかと思ったが、やはりボーカルなどの響きはアップサンプリングした方がいい。
ここでリサンプラーなしと聴き比べる。

44.1/16、リサンプリングなし。

チェロは右、SoXの時ほどじゃないけど、目の高さより若干高いことに気付いた。
ボーカルは中央、正面やや上に上がった。1分20秒すぎのボーカル、高音の響きが上～左向きに。２分台後半、やや右、後方に揺れる。
バス、ほぼ中央。

一言で言うと響きが硬い。
libsamplerateをアップサンプリングなしで通した音の方がずっと聴きやすくなるようだ。これは化粧した音と考えた方がいいのかな、、、しかし聴きやすいほうがいいよな、、、というか、最近はnano iDSD LEで聴くことは減ってきているので、この結果にあまり神経質になる必要はないのだけど。

そういうわけで、fireface UCXでどんな鳴り方になるか聴いてみる。
44.1/16、リサンプリングなしでCCモード、ppap。
チェロは右、目の高さ。nano iDSD LEのときよりやや内側に寄る。
ボーカルは中央、正面やや上。しっかり肌理細やかに鳴る。1分20秒すぎ、高音の響きは上～左右に広がる。２分台前半、定位はしっかりしている。後半、響きが右、後方に向かう。
バス、中央右。

こんな感じ。
しかし定位がどうとかよりも音色の格が違う。
NASマウントのLEとppapのUCXの比較だから当たり前だ。

UCXでアップサンプリングも聴いてみるべきか、、、と思ったけど、、、もういいか。
うちでは使うならlibsamplerateと決まっているし、UCXとLEの結果が知れたからといって、だからどうなのかということもあるし。
ともかく、リサンプラーによって良くも悪くも音が変るし、リサンプラーの種類やサンプリング周波数によって変わり方が違うのも確認した。多分、DACによっても違うんだし。きりがないっちゃきりがない。

自分の納得がいくように、気持ちよく聴けるようにやれたら、それでいいと思う。
僕は、一種のゲームのような感覚でオーディオをやってるんだと思う。ひとつクリアしたら次の課題に移るという感覚。
そして幸か不幸か課題には事欠かない。