abk1's scratched blog 3::AUDIO DIARY

最近はmpdクライアントが少なくなってきていて、いつだったかiPad用の定番ソフトがアップデートされないというので話題になった。現在もいくつかのソフトが残っているが、昔のようにいろんなソフトから好きなものを選べるという感じではなくなっている。
うちのデジタルオーディオ環境はCDをリッピングした flac + cue sheet が基本なので、mpd + cue sheetに対応したmpd client という手法を捨てられない。数千のアルバム単位のflacファイルを、曲ごとに切り分けるなんて作業は絶対に自分ではしたくない。
そういうわけで、cue sheet対応のncmpcppが使えるのは非常に有難い。開発終了にならないことを祈っている。

今回は、Linux用のクライアントソフトであるncmpcppを、ssh経由でwindowsやmacで使えないかという話だ。
うちでは家族の希望を聞いて、音楽を鳴らすことがある。だから、女房や子供が使うPCからオーディオを操作できたほうがいいんじゃないかという考えは、以前からあるのだ。

ncmpcppはターミナルソフト上でcuiで動くクライアントだ。
cuiと云いながら実際は、ターミナル「画面上」に表現された階層的な空間を、主にショートカットキーと補助的なマウス使用で、移動、選択、決定、指示を打ち込むことで操作するという、下手な文章で書いたらよく分からないけど、かなりgui的な性格を持っている。
個人的には、神憑り的に使いやすいと思っている。
不満といえばライブラリーブラウザが文字表示の一覧表（かなり使いやすいと思っている）で、itunesのようなアートワーク表示ができないことぐらいだ。アートワークを見て聴きたい曲を探すというのができたら、ほんとうに僕にとって完璧なクライアントなんだけど、、、cuiなんだから無理言うなって感じだ。

Fedoraでncmpcppを使っている画面をスクリーンショットしてみた。
これはプレイリスト画面。「1」キーで表示される。

この際なので、いくつかスクショを追記することにした。
以下の画像はFedoraのncmpcppではなく、Fedoraからssh経由で表示したraspbianのncmpcppのスクショだ。

下は、ブラウザ画面。「2」キーで表示。
mpdは、musicディレクトリがそのまま階層化されたライブラリになるんだけど、それがそのままブラウザ表示される。カーソルキーとショートカットキーでディレクトリを移動しスペースキーでプレイリストに追加する。慣れれば快適だ。

次は検索画面。「3」キーで表示。
タグやファイル名から検索する。日本語も検索できる。

最後はヘルプ画面。「f1」キーで表示。非常に細かい。
普段、音楽を聴くだけなら、そんなにたくさんのキーは使わないんだけど、ちょっと目がまわる感じだ。

Keys - Browser

Delete : Delete selected items from disk

Flag "allow_for_physical_item_deletion" needs to be enabled in configuration file

最初は、ncmpcppそのものをwindowsやmacにインストールできないかと考えていた。だけど、ncmpcppはlinuxのソフトなわけで、windowsやmacではインストールする環境を作ることから大変なのだ。
どうしようかと思っていたんだけど、先日ふと、macやwindowsからsshを使って、ncmpcppが動くlinuxにログインしたら、macやwindowsでncmpcppを使えるってことにならないか、と気が付いた。

うちではノートパソコン2台にlinux(Fedora)をインストールしていて、日常の使用とかncmpcppの運用に使っている。試しにこれらのlinux機2台で、sshによるncmpcpp共用を試みたところ、全く問題なく違和感なく使うことができた。
次にうちにあるwindows機、mac機から、sshでFedora機にログイン。ncmpcppを起動。表示に使われるフォントの違いによるものか、受ける印象は多少異なるものの、問題なく使用できた。

これでいいじゃん、と思ったんだけど考えてみると、うちだとこれでいいけど、一般的には簡単にncmpcppを動かせるlinux機が置いてある家庭は少ない。しかし、部屋のすみに転がって埃を被ってるraspberry piを使ったら簡単に出来るんじゃね？というのを思い付いた。
この際、うちでもやってみよう、ということだ。
下図のようなイメージ。

mpdとクライアントを同じサーバー機にインストールするというのはよくあるし、操作端末にクライアントをインストールして使うというのもあるけど、敢えてmpdと操作端末の間にクライアントを設置するというのは、あんまり見ない気がする。

使用したのは、Raspberry pi B+。本当に使わずに放置されていた機体だ。
まず、piCoreで出来ないか試したけど、これが意外にncmpcppのインストール自体が面倒で却下。
ncmpcppのサイトには「Most of the popular Linux/*BSD distributions have ncmpcpp in their repositories, 」と書いてあるんだけど、piCoreのtczには登録されていない。

raspbianでどうか。
これが簡単にncmpcppサーバーになってくれる。
リポジトリにncmpcppがあるので「apt-get install ncmpcpp」とコマンドを打つだけでインストールできて、あとはconfigファイル、bindingsファイルで設定したら使えるようになる。バージョンもncmpcpp 0.7.4なので比較的新しい。
ちなみにFedoraのリポジトリにあるのはncmpcpp 0.8.2で最新だ。Fedoraはラズパイでも動くらしんだけど、これはこれで大変そうなので今回はやめている。Cent OSだと0.5あたりだったか、、、かなり古いバージョンだったと記憶する。それで普段使いをFedoraにしたという経緯がある。

今回、ncmpcpp専用機をraspbianで仕立てたけど、mpdが動いているラズパイにncmpcppをインストールしてしまうという手もある。しかしうちでmpdが動いているのはpiCoreで、ncmpcppのインストールが手軽にとはいかない。それにmpdサーバー機に余計な負担は要らないだろうというので、別にした。

Raspbianでのncmpcppインストール、設定のしかたについて、簡単に記載しておく。

まず、raspbianを設定。
raspbian stretchをダウンロード。microSDに書き込んで、bootディレクトリにsshファイルを作る。
ラズパイに刺して起動。
ipアドレスを確認しsshでログイン。ユーザーは「pi」、パスワードは「raspberry」。
コマンド「sudo raspi-config」で初期設定。
いろいろ設定するけど、ここでは多くは説明しない。ラズパイの解説サイトを参考にして欲しい。

さて、設定ができたら、ncmpcppをインストールする。
「apt-get install ncmpcpp」とコマンドを打ったら、文字がぞろぞろ表示される。
程なくインストール終了。

次に「man ncmpcpp」と打つとncmpcppのマニュアルが表示され、設定をどうしたら良いか書いてある、、、
けど、けっこう読むのは面倒だ。

ユーザーのホームディレクトリ（今回の場合、piディレクトリ）に.ncmpcppディレクトリをつくり、そこにconfigファイルとbindingsファイル、２つの設定ファイルを置く。ファイルの原本がどこにあるかは「man ncmpcpp」と打ったときに表示されるマニュアルに記載されている。一般的には「/usr/share/doc/ncmpcpp」にあるので、これを持ってきて使えばいい。

その設定内容なんだけど、何十項目もあって、ちょっと僕自身が把握しきれていない。画面のカスタマイズをする項目もあって、昔に多少いじったこともあるんだけど、すっかり忘れてしまった。
しかし、絶対に設定しなくてはいけない項目は意外に少ない。それ以外はデフォルトのままでも使えてしまう。

configファイルで設定しておくのは、

mpd_host = "192.168.1.xxx"

mpdサーバーのip アドレス。
これだけは必ず設定しておかないと、mpdとncmpcppがつながらない。
各自の環境に合わせてアドレスを設定する。
あとは、タグエディターを使用したかったら設定しておかないといけない項目とかあるんだけど省略。僕はタグの管理は他のソフトで行っているのでよく知らないのだ。

Bindingsファイルではキーボードショートカットを設定できる。デフォルトのままで気に入らない場合は、ここで設定変更してしまえばいい。
僕の場合、「back space」キーで曲再生がリプレイするのが気に入らなかったので「t」に変更してある。

#
#def_key "backspace"
#  jump_to_parent_directory
#
#def_key "backspace"
#  replay_song
#

デフォルトはこんな感じ。コメントアウトされているけど、ブラウザ画面で上位ディレクトリへの移動、プレイリスト画面でリプレイが設定されている。
この下に、下記の４行を書き加える。

def_key "backspace"
  jump_to_parent_directory
def_key "t"
  replay_song

こんな感じ。これでリプレイを「t」キーに設定できる。
他には「f1」キーでヘルプ表示なんだけど、これがFedoraの端末ソフトのヘルプ表示と競合したので（これもf1キーでヘルプ表示の設定）、ターミナルのほうの設定を変えている。それができないようなら、ncmpcppのほうの設定を変えることになっていたかな。

これで「ncmpcpp」とコマンドを打てば起動する。
設定が正しければ、使いたいmpdの状態が反映された画面が表示されるはずだ。

windows7にsshソフトをインストールしてラズパイにログイン。「ncmpcpp」とコマンドを打った画面が以下。
ちょっとレガシー感あるけど、フォントの設定とか変えたらかっこよくできるんじゃないかな、どうだろう。
見てくれは兎も角、ちゃんと使える。
MacだともっとFedoraの画面に近くなるのだけど、スクショは省略。

def_key "h"
 show_help

mac、windowsで使えるのは確認したが、iPadのような端末でどうなのかは試していない。うちには今どきタブレット端末がないのだ。android携帯にsshソフト(JuiceSSH)をインストールして、使えるかどうか試してみた。
現在は使えているが、最初は下記のようなエラーが表示された。

pi@raspberrypi:~ $ ncmpcpp
Reading configuration from /home/pi/.ncmpcpp/config...      
Terminal doesn't support window title, skipping 'enable_window_title'.

「enable_window_title」というのはncmpcppのconfigファイルに記載されている設定で、デフォルトは「yes」。端末ソフトのウィンドウのタイトルバーに「ncmpcpp 0.7.4」と表示するかどうかの設定だ。androidのsshソフトにウィンドウタイトルがないから、こういうことになったらしい。
設定を「no」にしたら動くかというと、エラー表示されないまま止まってしまう。

繰り返しログイン、ログアウトするうちにncmpcppの操作画面が表示された。
これで使えるかと思ったんだけど、表示されただけでキーボードからの指示を受け付けない。ソフトウェアキーボードだからかどうかは、はっきりしない。
実際のところ、ncmpcppの操作はほとんどキーボードで行う。キーのひとつひとつに役割が振られていて、例えば「p」は一時停止、「r」はリピート、「s」は停止、「y」は1曲のみ再生などなど。ライブラリの階層移動や曲の選択もキーボード操作で行うので、キーボードに反応しないのでは使えない。
あんまり無理はしないほうが良さそうだ。

とか思っていたら、数日後に試みたら使えるようになっていた。
何が良くて何が悪かったのか、分からないままだ。
Android操作画面のスクリーンショットをアップしておく。

問題なく動くのかといったら、ひょっと何かの拍子に画面表示が不安定になる。
他の画面に切り替わった後で、戻したら曲順が正確に表示されていないとか不具合が生じる様子。
上の2つ目の図がそのスクリーンショット。一旦「exit」して、再度「ncmpcpp」を打ったら正常に戻る。扱いには注意がいるようだ。

使えるけど画面が狭いので不便だ。もっと画面が大きいタブレットだったら違うかな、、、
あとソフトキーボードに「delete」キーがない。これはデフォルトではプレイリスト上で選択した曲を削除するキーなので、使えないのは痛い。bindingsファイルで、使えるキーに設定したらいいかな。「d」あたりがいいのかな。

こんなのできるようにしたよ、と女房に言ったら「誰が使うの？」と言われてしまった。
大丈夫、想定内だ。

9月上旬、RME ADI-2 DACを導入した。
ChordのDACにしようか、ADI-2 Proにするかとか、それ以外のメーカーか、、、
ずいぶん悩んだけど、決めるときはあっけない。1万以上のポイントに釣られたわけじゃない。いや、釣られたけどさ。釣られるなりの理由はあるさ。

音の方は、意外にUCXよりもいい感じ。
この程度違うなら買い替えはありだな、と思った。
ただ、UCXは本領を発揮してないんじゃないかという疑いがある。
というのは今までに、spdif入力(CDP、hifiberry-digiなど)と、ラズパイpiCore7のusbでCCモードは使用経験があって、CCモードのほうがいいと思って使ってきているけど、UCXのusbにはmacやwindowsにインストールしたTotalMix FXを使って音を出す方法があるのだ。というか、それこそが本来の使い方だ。最適化されてるんじゃなかったかな。
今までにそういう使い方はしたことがない。
CCモードはあくまでiPadへの最適化で、Linuxは想定外だ。
だから、UCXとADI-2 DACの音質の違いを見極めようと思ったら、それをやってみないといけない、と思っている。
何時になるかわからない。先のことだ。

ADI-2 DACだけど、ネット上に他にレビューがいくつかある。うちでどうなのかだけ書いとこうと思う。

まず電源だけど、プラグ差込口にストッパーがついていて、刺して捻ったらしっかり固定できるようになっている。
というか、捻らなくてもちゃんと固定しているんだけど。UCXのが抜けやすい感じだったのとくらべたら、そうとう安心感がある。
じゃあ、ストッパーがない電源プラグが使えないのかと言ったらそんなこともなく、うちではiPowerをつないで音が出ている。ふつうの5.5mm×2.1mmのプラグでいいようだ。
電源アダプターの違いによる音質比較はまだしていない。付属アダプターでも案外充分というレビューを読んだことがあるが、そうだろうな、とは思う。

マニュアルを読みながらセッティングしていくのだけど、UCXはマニュアルがないとどうにもならない（というか、読んでも難しい）という感じだったが、ADI-2 DACは時々参照するという感じだ。

さて、まずはUCXに刺しているusbケーブルを抜いて、ADI-2 DACに差し替えてみる。PPAPで24/96。簡単に音が出た。
次に、別のラズパイを用意して、新規でpiCore7を焼いたmicroSDで起動、mpdをインストールして、NASマウント再生環境を作る。
問題ないかなと思ったら、、、どうもおかしい。
グールドのピアノにときどき、鈴を細かく鳴らすかのような「リーン、、」というような音が乗るのだ。
こんな音、ソースに入ってないよね？ 他のソースでも同様。
アップサンプリングを設定してたんだった、、、これを止めたら、消えた、かな、、、
しかし、なんか気持ち悪いね。
ADI-2 DACは768kHzまで使えるはずなんだけど、piCore7でアップサンプリングで指定しても音が出ない。384kHzでは前述のノイズで全くだめ。192kHzでも、ときどきノイズが混じるので、使いたくない。
アップサンプリングなしの設定だとCDリッピングファイルは普通に鳴るようだけど、ハイレゾファイルだと高い周波数のはノイズが乗る、、、
どういった塩梅かね、、、

ちょっと思いついて、piCore7をpiCore9にバージョンアップしてみた。使われているalsaのバージョンが違う。
これで、192kHzはノイズなしに使えるようになった。
でも、368kHz384kHzではまだ鈴の音のようなノイズが乗る。

今年の4月、alsaがバージョンアップして、aplayeraplayが192kHzより上のサンプリング周波数にも対応したらしい。aplayeraplay以外がどうなってるのかは、よく調べていない。新しいDACにusb接続する場合、PCトラポにも新しさが求められることがあるのかな。
Macで384kHz以上で動くからLinuxでもいけるかな、じゃダメなのかもしれない。
というか、それだから手を出せなかったんだけどさ。
UCXだって、導入当時はそれで随分迷ったのだった。
usb接続って、そういうところでもハードルがあるんだよね。何か音楽信データ号伝送のデフォルト仕様があればいいんだろうけど。

piCore9に最新バージョンのalsaをインストールしようとしてみたがうまくいかなかった。
そういうわけで、今はpiCoreのバージョンアップ待ちだ。
そのうち768kHzを伝送できるようになるんじゃないかな、たぶん。

現状は、piCor9.03でPPAPで、max192kHzで使用継続中だ。piCore9だったら、192kHzまでの使用なら問題ないんじゃないかな。
もしも問題があるようなら、ここに追記していこうと思っている。

volumio@volumio:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 7/7
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 5: DAC52973504 [ADI-2 DAC (52973504)], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
volumio@volumio:~$
volumio@volumio:~$ cat /proc/asound/card*/pcm0p/sub0/hw_params
closed
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 768000 (768000/1)
period_size: 32768
buffer_size: 131072
volumio@volumio:~$ aplay --version
aplay: version 1.0.28 by Jaroslav Kysela 
volumio@volumio:~$

前回、UCXの電源アダプター出力に自作のフィルターをかませてみたら失敗だったという話を書いた。
今回はその後の状況の話。

まず、UCX用自作フィルター1号の出来があんまりだったので、2号を作成した。
2号と言っても部品は全く同じもので、5.5/2.1mmのプラグ（オス、メス1対）と0.027μFのフィルムコンデンサー。何が違うかというと、配線とか半田付けを若干丁寧にしてみましたというもの。あと、1号で補強のつもりで塗りたくっていたグルーガンの接着剤を使っていない。

使ってみて音はどうかというと、意外に2号は1号のような副作用がない。1号は音がこもり覇気がなくなってしまったけど、そこまでの感じがないのだ。よく聴くと、ちょっとだけ音が丸いかな。継いだままにして1、2日と様子を見ていたら、なんとなく効果が出てきた。丸くなっていた音が出るべきところは出るようになり、逆に音色のニュアンスがフィルターなしの時よりも出るようになった。外して聴いてみたら、なんとなく耳障りな感じがする。少しコントラストが悪くなる感じ。
フィルター2号は使える。
1号とほとんど同じ構造なのに、ずいぶん違うもんだと思った。
しかし考えてみたらケーブルとか被膜で音が変わるんだし、接着剤を塗ったかどうかは意外と大きいのかもしれない。

UCXの電源を改善したら音が良くなるというのはあちこちで言われている。楽器用電源（YAMAHA PA-6の代替品）を入手しようとして果たせなかった顛末は前回書いたけど、PA-6はネットショップで売られていることもある。しかしなんだか割高で、付属品の電源で大きな不満はないし、どうしようかなと思っていた。
しかし、簡単な自作フィルターでも確かに変化がある。
この際だから、最近評判がいいiFI-AudioのiPowerを使ってみることにした。

うちではUCXの電源アダプターはUPS（omron BY50S）のAC出力コンセントにつないでいる。
理由ははっきりしなくて、Ras piとかといっしょに安物の電源タップにつないでノイズが多い環境にするよりUPSのコンセントひとつ充てがうほうが良かろうと思ったんだろうけど、実際に音質に差があるかどうかは確認していない。
今回、とりあえずiPowerは電源タップにつないでみた。
というのは、iPower本体の形状とUPSのコンセント使用状況の関係で刺せなかったのだ。UPSには4つコンセントがあって3つが埋まっている。残っているコンセントにiPowerを刺そうとしたら、既に刺さっているプラグが邪魔で刺せない。刺すには使っているプラグをいくつか抜かないといけない。

書き忘れていたが、前述の電源タップはUPSの出力コンセントに刺している。つまり、壁コンセント→UPS→電源タップ→iPowerと繋がっている。UPSには電源タップが２つと、UCX付属品ACアダプターが刺さってる状況だ。

iPowerと、付属品ACアダプター自作フィルター付を比較、、、
あんまり差がない？
継いだ直後に比較ではiPowerに分が悪い。継いだまま様子を見る、、、あんまり変らんかな？

電源タップに刺したままでどうなのよというのはある。
ホームセンターでACプラグを買ってきて、UPSとの接続用コードを自作した。
この際なので、UPSにつなぐ側はコンセント形状に合わせて接地極付きのプラグにした。そのほうが刺した時に物理的に安定すると思う。購入費は400円ぐらい。iPowerにつなぐ側は100円程のありふれた家庭用ACプラグを使った。長さは30cm程度でコードはこれも家庭用の安価な奴だ。
これでiPowerと付属品ACアダプターの条件が同じになる。

ここで、出てくる音に違いが出て来た。
iPowerを使った方が楽器の分離が良く音色の階調が深くなる。極端に大きな差はないけど、UCXは電源にこだわったほうがいいと思った。
自作フィルターとiPowerを併用したら若干音色が柔らかくなる。ごく僅かに情報量が減るように聴こえないこともないけど、音色が柔らかいので音量は上げやすいので副作用は少ない気がする。意外と好みで使い分けてもいいような。
まさか、もしかして、、こっちのほうがいい？、、、判断は保留しておく。

7月は岡山も水害があり、仕事の同僚が被災したりして、どうにもブログを書くとかいう気分になれなかった。他にもいろいろあった。
でも、なんとなく最近になってぼちぼちでも再開しようかという気持ちになれたので、書いていこうと思う。

タイトルにあるように、USB電源用のノイズフィルターを自作してみた。
自作と言うのは恥ずかしいぐらいのもので、半田付けしたから自作、みたいな。例によってGNDと+をキャパシタで繋いだだけで、何Hzのノイズを狙ってとか考えもなく、あわよくば高周波を減らせたらいいや、手元にある部品を使って様子を見よう、で作ってしまったようなものである。うちにあるのはそんなのばっかりだ。

オスメスのusb端子はウェブ通販で購入。メス端子のほうに基盤がついていて、オス端子を半田付する。キャパシタは地元の部品屋で購入した0.027μF。
半田付の固定だけでは強度が心許無いので、写真の状態の後、ヒートガンで固めている。
うちのras piに使っているusb電源は、いくつか変遷した後、現在はELECOMのAVA-ACU01という小物になっている。白地に顔が付いたバージョンで、ゆるキャラ系だ。1個500円で売られていたものを複数まとめ買いして携帯の充電に使ったりしていたんだけど、試してみたら意外にいいんじゃないかな、ということでオーディオに使うようになったのだ。
いいといったって、オーディオ用の電源などは試してないので、ほんとうはiPowerとかのほうがいいんだろうなあ、などと思ってるんだけど、3つ買ったら2万円になるし、ちょっと手持ちの部品を試してみてから検討してもいいかな、ということで、やってみた。

結果は、意外にいいような。
音が滑らかになり奥行が出て、微かにまとわりついていたギラつきが消えて音色がより分かりやすくなった。
まだ改善の余地があったと比べて気付いた。
以前からときどき試聴に使っているエネスクのルーマニア狂詩曲2番とか、1年前よりもずっと聴きやすく美しく鳴るようになってきているんだけど、さらに気持ちよく鳴るようになった。

ロック音源の関係で驚いたことは、THe Whoの「Live at Leeds」を聴けるようになったということ。
聴けるってどういうことかというと、僕はこのCD音源を学生のころに購入して、あんまりにも音が悪いと思って聴き通せず中古屋に売った（他の物を買う元手にしないといけないので）という経緯があるのだ。ノイズっぽいし籠っていて精彩を欠くという再生音。ただ、当時のオーディオシステムはトータル数万円のシスコンで、スピーカーは16cm？フルレンジ？にプラスチック製で直径1cmのドームツイーターが付いていて、ツイーターの傍に耳を近づけても音が聞こえなかった。マイルスのトランペットとコルトレーンのサックスを聴き分けられないという代物だった。
しかしその後、これを持っていないというのはロックファンとしていかがなものかという気持ちに負けて、再購入したのである。その後、システムが変わっても良い音だと思ったことは全くなかったし、そもそもパッケージにノイズなんかは気にするなという旨のコメントが予め書かれているのである。最後まで聴き通した記憶が無い。

その音源が、あろうことかTAS Super LP Listに載っているのである。
http://www.theabsolutesound.com/articles/2018-tas-super-lp-list/

まあ、リマスターで再発のアナログ盤なので、初期CDとは別物だろうけど。
しかし、どこにか優秀録音の片鱗があるのかもしれない、聴いてみないといけないと思って聴いてみたら、なんと、意外に聴けるのだ。パチパチノイズが入っている（8794年のCDでリマスター前のものだ。リマスター後は消えている）けど、ロック演奏の生々しさは、確かに音源に記録されていて、最初から最後まで感動を持って聴き通せたのである。
リマスターCDはどうなのよと思って入手したらノイズが消えていて、初期CDより聴きやすくなっている。音が明るいというのかな。ただ何というのか、、、Live at Leedsってなんだか、ヘビーな初期CDのほうが自分には馴染む気がする。好みだろう。
しかしなるほど、名盤とされるだけのことはあるんだこれはと、ロック聴きだして35年でようやく理解するに至った。

TAS Super LP Listはアナログ音源なんだけど、CDでもいいかと思って最近は参考にしている。
ポピュラー系にはLive at Leedsのように意外な音源もアップされていて、どう料理するか考えろというリストなのかなこれは、と思うようになった。

そんなこんなで、電源アダプターのDCラインというのは対策しやすいのかな？と思って、fireface UCXのDC入力プラグに、上記のフィルターと似たような構造のアダプターを作って噛ませてみた。どうだったかというと、こっちは全く駄目で、再生音がこもり覇気がなくなってしまった。
ひとつ覚えではやはり無理みたいだ。
こっちのほうこそiPowerを使ったほうがいいのかな、、、

UCXの電源といえば、1年も前になるかもしれないけど、楽器店で電源アダプターを注文しようとしたことがある。楽器用のものを流用して音質アップを図ろうとしたのだ。受付でにこやかにどういったご要件でしょうか、と尋ねてくるお姉さんに、これこれの代替品の電源アダプターが欲しいんですがと切り出したところ、たちまちお姉さんの表情がかき曇った。そして、何を言われたかは全く覚えていないのだけど、対応できない理由について、なんでそんな顔して話す必要があるのかというような、苦虫をかみ潰したような、親の仇を見るかのような表情で話すのである。こちらは平静を装いながら、いや、難しいんならよろしいんです、、、と精一杯の応答を絞り出したのだった。
いったい、何があったんだろう。

オーディオで気になることは他にもいろいろとあるんだけど、まず、alsaがバージョンアップしてaplayで扱えるサンプリング周波数が上がったこと。

http://www.alsa-project.org/main/index.php/Detailed_changes_v1.1.5_v1.1.6

aplay: Adjust sample rate limits to support newer hardware
There are number of devices that support up to 384 kHz sampling rate and some devices up to 768 kHz sampling rate. This patch increases sanity check limit to 768k in order to support testing of such hardware.

しかし、まだpiCoreには移植されてないんだよね。自分でコンパイルも試みたけど難しい、、、
まあ、使えるようになるまで待とうかと。

これが使えるようになれば、384kHzとか768kHzにアップサンプリングしたPCM音源をPPAPで鳴らすことが出来るかもしれない。
768kHzが使えるDACがCHORDとかRMEから発売されている。
こういうのに入力したらどんな音が出るだろうと思うんだけど、、、
これらのDACは、MQAに対応していない。RMEとかサイトでMQAを推してるのに対応してない。
フィルターとかクロックとかで高度な技術を使っている分だけ、対応に時間がかかるというのはあるんだろうか。
どうしようかなと。

MQAは、誰も言わないみたいだけど、僕が勝手に考えてるのは、見当違いかもしれないけど、PCMよりもジッターの影響を受け難いのではないか、ということ。
つまりノイズ管理やクロック精度の重要性が低くなり、デジタルオーディオの一番厄介な部分の労力が減ることになり、かなり気楽に構えていても安定して良い音が得られるようになる、のではないかと、思ってるのだけど。
あちこちの説明を読むと、PCMには出来ないところに踏み込んだ技術のようだ。
過去のCD導入の時は音がいいと言われながら違ったし、ハイレゾも音がいいと言われながらそうなの？という感じだし、今回は、確かに音がいいと言われながら普及するといいなあと思っている。
でも僕自身、試聴機会がないので、なんとかならないかな、と思っている。

デジタルオーディオはノイズとの戦いということで、いろいろ些細な変化で音が変わる。
アナログの場合はノイズや歪みも味のうちという場面があるけど、デジタルだと悪化要因にしかならない。

先日は、イーサネットハブを外したら音が変わるという、デジタルオーディオをやっている人間にとってはよくあるあるある状況に陥って、もとに戻してみたりしてるのだけど、戻してみても精彩を欠く。
何が原因だろうとしばらく悩んだけど、LANターミネーターが足りないから端子だけ差しておけばいいか、と思って刺していたLANケーブル端子（ターミネーターに加工前で、端子に10cm足らずのケーブルが付いている。抵抗が足りなくて製作が滞っているのだ）が怪しいと思い至り、外してみたら音が戻った。

10cmのケーブル端がノイズを拾っていた？ということらしい？
もしかしたら、僕が知らないだけでよくあることなのかもしれないけど、やはり体験すると感心するやらあきれるやらで、いろいろと細かいことだよな、と思う。

音がいいのはいいんだけど、敏感すぎるのも扱いにくいよなあ、と思う事がある。
昨日と今日で、なんとなく違うのだ。
気圧のせいやら電圧のせいやら、よく分からない。
好きでめんどくさいことしてるんだから誰にも同情されんだろうけど、もうちょっと大雑把にやれないかなとか思ったり。
まあ、そうもいかないのは分かってるんだけどさ。

6月20日現在、下図のような感じで継いでいる（変更追記。文章の流れで、図の位置を上に上げた）。

先日外したハブというのはFX08-mini（hub 5）で、以前は数を継げるほど音が良くなるハブと言われていた。うちでも3台までは継げてみたことがあるけど、まあ2台でいいかということで減らして、最近は1台だけPPAPのフロントとバックエンドの間に挟んでいた。
ふと、なくてもいいんじゃないの？と思って外したら、思わしくなかったのだ。

このハブは、何をしているんだろうという。
ないならないで精彩を欠くので、デジタル信号の打ち直しとか安定化とか、そういうことをしてるんだろうと思う。
一方で、端子に刺さったケーブルは悪化要因にもなるのだ。切れ端で悪化するなら、ケーブルそのものも悪化要因になる可能性はあるのかな。
音が精彩を欠いたのは、ハブを外したからじゃなくてケーブルが違ったからかもしれない。つまりハブからRas Piまでの距離が違うのだ。片やFX08-miniから50cm程度で、FX08-miniを外したらGS105Eまで1m以上と、そこそこの差があって、これが実はいけなかったんじゃないのか。とか。いや、もしかしたら、ケーブルは端をターミネートしてるかどうかのほうが影響が大きいのかもしれない。経験的に音が悪化するのはケーブル端に何もつないでいない時だ。でも、そもそもハブが違うじゃんというのもあったり。
わけが分からないね。

引きずってた案件としてNASを追加したいというのがあって。
ストレージ使用量が全容量の4分の3を超えたので、いずれ対策が必要になるのは分かっている。NASを追加するとしたらどう設定しようかというのも悩みだし、追加するとなるとハブの何処に刺すのということが出てくる。ハブ足りないから追加しようか、とか。
PCトラポからの距離はどの程度まで許容されるのか。漠然とした印象ではトラポとNASが近いに越したことはないという印象なんだけど、実際にそこはどうなのか、とか。

そんなわけで昔使っていたBaffaloのハブ（hub 2）を戻している。ここにNASやサブクライアントPC、DHCPサーバーとの連結など、ノイズ源になりそうなものをまとめてみようという考え。
サブクライアントPCは音源データをNASに送るのに使っている。普段、ncmpcppでmpdを操作してるのはwlanで継いだクライアントPCが主なんだけど、無線lanボードの通信速度が遅すぎて、ギガバイト以上のリッピングファイルやハイレゾファイルのNASへの転送には全く使う気になれないのだ。有線だと違うんだけどダイニング周りにケーブルを引き回す気になれない。サブクライアントPCは有線で継ぐことができる場所に置いている。
FX08-mini、GS105EへのLANケーブルの接続は最小限にして負荷を減らし、使わないLAN端子はOFFにしたりターミネータを刺してノイズ低減に努める。サブシステムのほうはトラポのRas pi/piCoreで384kHzまでアップサンプリングするからノイズに耐性があるはずなので、96kHz上限のメインシステムよりノイズ対策は緩い。
とか、もったいぶったことを書いているが後付けの理屈で能書きだ。

NASは型落ちのhs-251を入手して、どういう設定で継ぐか延々迷っていたんだけど、もうRAID1でいいやってことにした。
他の選択枝となると、HDD2台でRAIDを組まずに運用する方法だけど、そうなるとバックアップの管理が重要になってくる。RAID1のほうがNAS自体の耐障害性信頼度が高い分、バックアップ管理の重要度は減るんじゃないかな。RAID0とか他の組み方はデメリットが大きくて考えにくい。
RAID1だとNAS2台で運用せざるを得ないんだけど、音への影響はどうなんだろう、、、
NAS2台をマウントすることになるras piへの負担が増えるのと、ネットワーク内のノイズ源が増える。
考えてばかりいても仕方ない。
やってみよう。
ということでやってみたら、以外に音への影響は小さいのかな？
1台のときとの差を聴き取れないような。
というか、、、
NASというのは時々リブートしたほうがいいのかな、と思った。安定動作のために。
あとhs-251のほうが210よりも機械としてのスペックが高い分、スペックが高い音が出ている。これはなるほどなあと思った。
当面、これでいくことにした。
役割分担としては、hs-251がクラシックの音源、エスニックや環境音のライブ録音音源、ハイレゾ。hs-210にはロック、ジャズ、JポップなどポップミュージックのCDリッピング音源を担当してもらう。

以前は、hub 3（GS105E）に接続が集中していて、今回、NASを増やすのを機にハブを増やしている。
NASやサブクライアントPCのhub 3への接続を、新しく追加したhub 2に移してみたところ、音のほうはなんとなく落ち着いてしっとりした感じになった印象がある。クリアネスは低下していないと思うので、悪くはないだろうという判断だ。踏み込んでじっくり時間をとった試聴はしていないので、印象なんだけど。
情報量が低下しているようなら考え直さないといけないけど、たぶん大丈夫だろ。

ほんとうは、hub 3からhub 5まではハブ1台で済まそうと思えばできるんだけど、以前からの流れでは数珠繋ぎになっていた。hub 5のFX08-miniを外したら思わしくなかったというのは前述したとおり。じゃあ、hub 3とhub 4を1台にまとめたらどうなんだろうとか考えたんだけど、まとめるより分岐させることにした。
メインシステムはfireface UCX CCモードでPPAPだけど、サンプリング周波数・ビット深度を固定しないといけないので、CDリッピング音源への対応が中心になる。ハイレゾは24/96までだ（しかし今回、これが今まで以上にいい音で鳴ってる気がする。NASの力だろうか、、、）。
ハイレゾ音源は192kHz以上のもあるし、ある程度は柔軟に対応できる環境も残しておきたいし、RAM音源再生ができる環境も維持しておきたいとも思っていて。これらの機能を、とりあえずサブシステムに振り分けることにした。

そうした諸々の結果が上の図のようになっている。
どうなることかと思っていたけど、意外にもパフォーマンスは改善している。今後もこの調子でいきたいところだ。

先日、piCore7で作るPPAP Frontというエントリーをアップした。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180529a.htm

その中で、/mnt/mmcblk0p2/tce/onboot.lst を編集することでタスクを減らせるという話を書いた。

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

mc.tcz
openssh.tcz
boost-dev.tcz
libsamplerate-dev.tcz
libsamplerate-doc.tcz
flac-doc.tcz
libcue.tcz
libcue-dev.tcz
libid3tag-dev.tcz
libmad-dev.tcz
mpg123.tcz
lame-dev.tcz
lame-doc.tcz
libmpdclient-dev.tcz
libmpdclient-doc.tcz
mpd-0.19.19.tcz
nmap.tcz

ついにここまで削ったが、ちゃんと音は出ているようだ、、、

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   833.2M     11.0M    822.2M   1% /
tmpfs                   462.9M         0    462.9M   0% /dev/shm
/dev/mmcblk0p2            3.6G    177.9M      3.3G   5% /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/loop53             512.0K    512.0K         0 100% /tmp/tcloop/sqlite3
/dev/loop54             128.0K    128.0K         0 100% /tmp/tcloop/libudev
192.168.1.80:/titan       2.7T      2.0T    670.6G  76% /mnt/music/nas

55個になった、、、
じゃあ音はどうなのかというと、例によって比較はできてないんだな、、、
これ以上は削るわけにはいかないような気がするし、この手法で出来るのはここらあたりまでかと思う。

今回は音の比較をしたという話だ。
結論から書くけど、音は良くなる。前の状態には戻したくないな、と思う程度の変化はある。

うちにはメインシステムで運用しているRas Pi以外にテスト運用に使うのが数台あってダイニングの本棚の底のほうに隠すかのように置いてある。前のエントリーをアップした時点では、こうした試験運用piCoreで音を出している、という状況だった。
LANの状態は下図のような感じ。

クライアントPCノートでfront1にsshでログイン、onboot.lstを編集してはリブートし、back-end1に音声データを送って試してみた。ある程度までタスクを減らせたのは前述のとおり。
back-end1に繋がってるのは小さいデスクトップ用モニタースピーカーなので音質評価は難しい。

front1から、メインシステムのback-end2にデータを送ってみる。リビングのJBLの4425mk2から音が出る。
まあ、こんなもんかな、、、
ふだんfront2/back-end2で鳴らしているのに比べると、むしろ音は良くない。

これは想定内でもあって、というのは図を見れば分かるんだけど、front1からback-end2への伝送経路はとても長い。
音源データの流れは、
NAS - hub2 - hub0 - hub1 - front1 - hub1 - hub0 - hub2 - hub3 - back-end2
と、こんな感じ。
hub0はルーターとDHCPサーバーも兼ねていて、そこをデータが通過するのも更に条件を悪化させているんじゃないかと思う。
front2からback-end2への流れは、
NAS - hub2 - front2 - hub2 - hub3 - back-end2
こんな感じ。
front以降に通過する段階がずいぶん違う。
この状況だったらonboot.lstを編集していないpiCoreのほうが音がいい。
というかタスク軽減による効果がはっきりしない。

ということで、front1に刺してあるonboot.lst編集済みmicroSDを抜いて、front2に差し替える。両方とも同じRas pi2初期型だから差し替えるだけで問題なく動く。pi2後期型だとどうなのか分からないけど。

編集なしと比べてどうなのか。、、、
微妙に違う。
というか、front1とfront2の大きな差に比べたら、差は少ない。
しかし、少ないとはいえ無視できないレベルの改善はあって、OSが不安定になるとか問題がないようならonboot.lstを編集しタスクを減らしたほうが良さそうだ。

そんなことを考えながら続けてあれこれ聴いてみるうちに、なるほど、これは戻れないかもと思うようになった。
音のリアリティ、ＳＮ感が高く細やかで雑味が少なくなる感じ。音場表現もより安定し深みが出て、前後も見易くなるようだ。

今回はPPAP運用の流れでonboot.lstを編集したけど、PPAPで使うかどうかに関係なくpiCoreでmpdの音を改善しようと思ったら試みていい方法だと思う。Ras pi1台でのmpd運用の時でも音質改善する可能性がある。

前回、前々回とPPAP関連のエントリーが続いている。
2月以降、取り上げてはいるんだけど、このサイトではPPAPについて詳しい説明はしていない。
詳しいことは発案者の記載などをあたってもらう方がむしろ良いかとも思うので、今更だけど関連のアドレスを記載しておく。

オーディオ道 ゆきて帰りし物語 | PHILE WEBコミュニティ
http://community.phileweb.com/mypage/entry/4787/20180104/
http://community.phileweb.com/mypage/entry/4787/20171227/
http://community.phileweb.com/mypage/entry/4787/20171218/

Home · papalius/symphonic-mpd Wiki · GitHub
https://github.com/papalius/symphonic-mpd/wiki
Home | symphonic-mpd
http://mpd.sytes.net/ja
セパレート構成まとめWiki
https://github.com/papalius/symphonic-mpd/wiki/%E3%82%BB%E3%83%91%E3%83%AC%E3%83%BC%E3%83%88%E6%A7%8B%E6%88%90%E3%81%BE%E3%81%A8%E3%82%81Wiki

PPAPは、もともとはsymphonic-mpdに関連して提案されたmpdの運用方法だった。
symphonic-mpdを単体で運用するよりも、役割分担させてセパレート構成にしたほうがいい音がするというのが始まりだ。セパレート構成というアイデア自体は数年前からPCオーディオのノウハウとしてポピュラーなものになっている。しかし「ncat - aplay」の連携で音を出すというアイデアが公の場に上がったのは、たぶん、ここが初めてだろうと思う。
この方法に、発案者のパパリウス氏が「PPAP (piped pcm audio play)」と名付けたのだ。パパリウス氏はsymphonic-mpdのディストリビューターだ。
今年1月中旬以降、symphonic-mpd関係のサイトは公開を中断したまま更新されないままとなっている。
何がどうなっているのか心配だけど、

とかなんとか、書いていたら6月2日に復活した！
http://community.phileweb.com/mypage/entry/4787/20180104/58139/
symphonic-mpd v0.5.0

PPAPの考え方自体はsymphonic-mpdでしか適用できないものではない。Linuxであれば、おおよそどんなディストリビューションでも応用し使う事ができて、ほとんどの場合、確実に音質向上が期待できるアイデアだと思う。
実際、lightMPDベースのバックエンドも公開されている。僕はpiCoreでやっているけど、確かに音が良くなっている。

Windowsのほうでは「DLNAプッシュ再生方式」が話題になっている。
http://community.phileweb.com/mypage/entry/2408/20180523/
ＰＣオーディオに見て、触って、聴いてみる－Ⅴ　その４
http://kotonohanoana.com/archives/20430
【ネットワークオーディオTips】DLNAの「プッシュ再生」について

プッシュ再生方式は、すごくPPAP方式と似ている。
DMRとDMS+DMCの役割は、そのままPPAPのバックエンドとフロントの役割と同じに見える。同時期に同じような構成、考え方がウェブ上で話題になっているというのも不思議な感じだ。将来、こういうコンセプトに影響を受けた製品が商品化されることがあるかもしれないとか、考えたりする。

そもそも、symphonic-mpdはストイックなディストリで、今もサイトに「アプローチに逆行すると判断したものはバッサリ断捨離している尖ったディストリビューション」と掲げている。PPAPはもっと間口が広くてゆるいコンセプトだと思う。僕は、ずいぶん方向性を変えるんだな、と驚いたものだった。
v0.5.0では、以前の方向性に戻っているのかな、、、
現時点では、本家のsymphonic-mpdでPPAPを続けるつもりがあるのかどうか分からない。PPAPは間口こそ広いけど、サンプリング周波数を固定しないといけないとか意外と扱いにくい面があるし、もしかしたら突き詰めてコントロールするには不向きと判断されるかもしれない。

せっかくアイデアとして世に出たものなのだし、うちでは成果があるのだからpiCoreでゆるゆる運用していくつもりだ。
間口が広いPPAPだから、そういうのもありだろうと勝手にそんな風に考えている。

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

３月に上記のエントリーを上げて、前回はバックエンドのエントリーを上げた。
フロントのエントリーがないのも、ちょっとね、と思って独立したエントリーにまとめることにした。新しいことはあんまりないんだけど。

課題としては、
フロント化に最小限必要な環境を見つけたい
mpdをOS起動時に自動起動できないか、といったところなんだけど、よく分からないところは分からない。

最初にお断り書き。
このエントリーはRaspberry pi2の使用を前提として書いている。
3以上は所有していないしB+以前の機種で仕事量が多いフロントを受け持たせる気に僕自身はなれないという事があるので。
アップサンプリングとか負担が多い仕事をさせずに動かすならB+とかでも問題ないかもしれないけど、そこはうちではやっていないので分からないところだ。

まず、microSDにpiCoreを焼いて、ras pi2に刺して起動して初期セッティングする。
詳細は、こちらのエントリーを参照のこと。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.htm
piCore7にmpdをインストールする方法

以下、sshでログイン後の流れを.ash_historyファイルからコピペ。

filetool.sh -b
sudo fdisk -u /dev/mmcblk0

sudo resize2fs /dev/mmcblk0p2
vi /opt/eth0.sh
chmod +x /opt/eth0.sh
vi /opt/bootsync.sh
vi /opt/.filetool.lst
filetool.sh -b

ここまでで、基本的な初期セッティングは終了。
バックエンドとほとんど同じだ。
出力をpipe - LAN経由でするのでi2s出力の設定は要らない。ネット上を探したらHAT形式のLAN出力ボードみたいなものもあるみたいなんだけど、、いや、USB出力だったっけ？、、そういうのを使う場合以外は要らないという意味だ。

今回は、先にmpdをダウンロードし解凍し、INSTALLファイルを確認する。
バージョンは0.19.19.

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*
less mpd-0.19*/INSTALL

Dependencies
------------
gcc 4.7 or later - http://gcc.gnu.org/
clang 3.2 or later - http://clang.llvm.org/
Any other C++11 compliant compiler should also work.

Boost 1.46 - http://www.boost.org/

GLib 2.28 - http://www.gtk.org/
General-purpose utility library.

最低限、これだけは必要ということか。ずっと更に下の方を読んでいくと、他にも必要なものが書いている、、、
取り敢えず、下記をインストールしてみる。

tce-load -wi \
gcc_base-dev.tcz gcc-doc.tcz gcc_libs-dev.tcz gcc_libs.tcz gcc-locale.tcz gcc.tcz \
glib2-dev.tcz glib2-doc.tcz glib2-locale.tcz glib2-python.tcz glib2-dev.tcz \
glibc_add_lib.tcz glibc_apps.tcz glibc_base-dev.tcz glibc_gconv.tcz glibc_i18n_locale.tcz \
glib-networking-dev.tcz glib-networking-locale.tcz glib-networking.tcz \
boost-dev.tcz boost.tcz

tce-load -wi \
flex-dev.tcz flex-doc.tcz flex-locale.tcz flex.tcz \
gdbm-dev.tcz gdbm-doc.tcz gdbm-locale.tcz gdbm.tcz \
bison-dev.tcz bison-doc.tcz bison-locale.tcz bison.tcz

ls /usr/local/tce.installed/

実際には、こうしたコマンドに表記されているもの以外にも関連のあるものがあれやこれやとインストールされる。

次にmpdが使うライブラリやエンコーダーをインストール。
以前はalsa関連はまとめてインストールしていたけど、考えてみたらPPAPのフロントではalsaを使わない。だったらなくても問題ない？ということで、コマンドからalsaを省いてみた。

tce-load -wi \
libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz \
flac-dev.tcz flac.tcz flac-doc.tcz libcue.tcz libcue-dev.tcz \
icu-dev.tcz icu.tcz libid3tag-dev.tcz libid3tag.tcz \
libmad-dev.tcz libmad.tcz mpg123.tcz lame-dev.tcz lame-doc.tcz lame.tcz \
libmpdclient-dev.tcz libmpdclient-doc.tcz libmpdclient.tcz

しかし関連があるということで、alsa-devとalsa-modules-4.1.13-piCore_v7+がインストールされている。

この時点でmpdのコンパイル、インストールを試みたけど失敗。
./configureで、いろいろ足りないみたいなことを言ってくる。
何が足りないのかは、本当はlogを読まないといけないのだけど、、、

手を抜いて、、、下記追加。

tce-load -wi \
binutils-dev.tcz binutils-doc.tcz binutils-locale.tcz binutils.tcz \
ncurses-dev.tcz \
make-doc.tcz make-locale.tcz make.tcz \
automake.tcz autoconf-doc.tcz autoconf.tcz libtool-dev.tcz libtool-doc.tcz \
compile-essentials.tcz squashfs-tools.tcz bash-locale.tcz bash.tcz \
bc-doc.tcz bc.tcz pkg-config-doc.tcz pkg-config.tcz cmake-doc.tcz cmake.tcz

こんなところでどうか。
予めダウンロードして解凍したmpdを、もう一度コンパイル。
コマンドを羅列。

cd mpd-0.19*

./configure --enable-pipe-output
make
mkdir ../mpd
sudo make DESTDIR=../mpd install

寝てる間にmakeさせたので、そこでかかった時間は分からないけど、install過程はスムーズに終了。

cd
mksquashfs mpd mpd-0.19.19.tcz
md5sum mpd-0.19.19.tcz > mpd-0.19.19.tcz.md5.txt
sudo mv *tcz* /mnt/*2/tce/optional
sudo vi /mnt/*2/tce/onboot.lst

~/ディレクトリにmpd-0.19.19.tcz、md5.txtファイルを作って、/mnt/mmcblk0p2/tce/optionalにコピー転送。
onboot.lstを開いて、一番下に「mpd-0.19.19.tcz」を追記。

これでインストール完了。

あとはmpd.conf、mpdの動作環境を作成していく。

cp m*9/doc/mpdconf.example .mpdconf
sudo rm -rf mpd*

vi .mpdconf
mkdir .mpd
mkdir .mpd/playlists

filetool.sh -b

上記ではダウンロードしたのをコピーして、/home/tcに.mpdconfを作っている。
でもコピーじゃなくても、mpdが読める場所に書式に則って作ってあれば構わない。~/.mpdconfはmpdで指定されているデフォルトmpd.conf設定のうちの１つだ。

sudo rm -rf mpd* で、インストールに使った諸々のデータを削除しておく。
これはインストールが終わったら使わなくなる残骸で、残しておくとfiletool.sh -bを打つたび、microSDカードに上書き保存されることになる。システム運用していたら、アップデートしたmpdの音楽データベースをsshからfiletool.sh -bを打って保存する必要が度々あるんだけど、この残骸を予め削除しておいた場合は数秒で終わる。残していたら数分かかる。
使わないデータを長い時間をかけて保存する行程を繰り返す必要はないので。

下記はmpd.confの記載例。
詳細はmpdのUser's Manual等を参照のこと。自分の使いたいように設定する。
https://www.musicpd.org/doc/user/index.html The Music Player Daemon - User's Manual

PPAP(aplay)で扱う事ができるサンプリング周波数の上限は192kHzなので注意。

music_directory "/mnt/music"
playlist_directory "~/.mpd/playlists"
db_file "~/.mpd/database"
log_file "~/.mpd/log"
pid_file "~/.mpd/pid"
state_file "~/.mpd/state"
sticker_file "~/.mpd/sticker.sql"

auto_update     "no"

mixer_type "software" ## hardware, software or none
## replay_gain_handler "none" ## software, mixer or none

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.82 4444"
}

filesystem_charset "UTF-8"
id3v1_encoding "UTF-8"

上記のmpd.confだと、replay_gain_handlerの設定が読み込めないというエラーでmpdの起動に失敗したので、コメントアウトしている。alsa関連でインストールしていないものが多いので、そのせいだろうか。

上記のmpd.confに合わせてmusic_directoryを設定する必要がある。
bootlocal.shにコマンドを記述しておくとOS起動時に実行される。起動時にmusic_directoryを作って、NASのtitanディレクトリをマウントするように設定。

vi /opt/bootlocal.sh

bootlocal.shに下記を記述。

mkdir /mnt/music
mkdir /mnt/music/nas
mkdir /mnt/music/ram
touch /mnt/music/ram/dummy.cue
chmod -R 777 /mnt/music
mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan /mnt/music/nas

設定を忘れず保存すること。

filetool.sh -b

忘れてはいけない、、、最後になってしまったが、nmapをインストールする。

tce-load -wi nmap.tcz

以上で、piCore7のフロント化、完成。

sudo reboot

sudo rebootで再起動すると、NASをマウントした状態になる。
使用に際してはsshで再度ログインして、mpdを起動させる仕様。自動起動にはしていない。mpdを起動させたらあとはmpdクライアントで操作できる。

この状態で「df」コマンドを打つとこんな感じ。

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   833.2M     11.4M    821.8M   1% /
tmpfs                   462.9M         0    462.9M   0% /dev/shm
/dev/mmcblk0p2            3.6G    177.9M      3.3G   5% /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.4M      4.4M         0 100% /tmp/tcloop/gcc_base-dev

(中略)

/dev/loop137            128.0K    128.0K         0 100% /tmp/tcloop/libudev
/dev/loop138            128.0K    128.0K         0 100% /tmp/tcloop/libtasn1
192.168.1.80:/titan       2.7T      2.0T    670.6G  76% /mnt/music/nas

139個のtczがインストールされて、その多くが待機状態になってるということかと。
ちなみに最初に作ったフロントではどうかというと、

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   833.2M     11.3M    821.9M   1% /
tmpfs                   462.9M         0    462.9M   0% /dev/shm
/dev/mmcblk0p2            3.6G    187.0M      3.3G   5% /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              896.0K    896.0K         0 100% /tmp/tcloop/nmap-doc

(中略)

/dev/loop155            128.0K    128.0K         0 100% /tmp/tcloop/libtasn1-dev
/dev/loop156            128.0K    128.0K         0 100% /tmp/tcloop/libtasn1
192.168.1.80:/titan       2.7T      2.0T    670.6G  76% /mnt/music/nas

157個。新しい方が20ほど少ない、、、どうなんでしょうなあ、、、

前からちょっと気になっていたことを試すことにする。ひょっとして、onboot.lstを編集したらタスクが減るんじゃないかな。

mc.tcz
openssh.tcz
gcc_base-dev.tcz
gcc-doc.tcz
gcc_libs-dev.tcz
gcc-locale.tcz
glib2-dev.tcz
glib2-doc.tcz
glib2-locale.tcz
glib2-python.tcz
glibc_add_lib.tcz
glibc_apps.tcz
glibc_base-dev.tcz
glibc_gconv.tcz
glibc_i18n_locale.tcz
glib-networking-dev.tcz
glib-networking-locale.tcz
boost-dev.tcz
flex-dev.tcz
flex-doc.tcz
flex-locale.tcz
gdbm-dev.tcz
gdbm-doc.tcz
gdbm-locale.tcz
bison-dev.tcz
bison-doc.tcz
bison-locale.tcz
libsamplerate-dev.tcz
libsamplerate-doc.tcz
flac-doc.tcz
libcue.tcz
libcue-dev.tcz
libid3tag-dev.tcz
libmad-dev.tcz
mpg123.tcz
lame-dev.tcz
lame-doc.tcz
libmpdclient-dev.tcz 
libmpdclient-doc.tcz 
binutils-dev.tcz     
binutils-doc.tcz     
binutils-locale.tcz  
ncurses-dev.tcz      
make-doc.tcz         
make-locale.tcz      
automake.tcz         
autoconf-doc.tcz    
libtool-dev.tcz     
libtool-doc.tcz     
compile-essentials.tcz
squashfs-tools.tcz    
bash-locale.tcz       
bc-doc.tcz            
bc.tcz                
pkg-config-doc.tcz    
pkg-config.tcz        
cmake-doc.tcz         
cmake.tcz             
mpd-0.19.19.tcz       
nmap.tcz              

当初のonboot.lstの記載はこんな感じ。これをrebootを繰り返しながら書き換えていく、、、
どうも、必要となれば引っ張り起こされるtczと、起こされないので最初からリストしておかないといけないtczがあるようだ。

mc.tcz
openssh.tcz
boost-dev.tcz
libsamplerate-dev.tcz
libsamplerate-doc.tcz
flac-doc.tcz
libcue.tcz
libcue-dev.tcz
libid3tag-dev.tcz
libmad-dev.tcz
mpg123.tcz
lame-dev.tcz
lame-doc.tcz
libmpdclient-dev.tcz
libmpdclient-doc.tcz
mpd-0.19.19.tcz
nmap.tcz

ついにここまで削ったが、ちゃんと音は出ているようだ、、、

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   833.2M     11.0M    822.2M   1% /
tmpfs                   462.9M         0    462.9M   0% /dev/shm
/dev/mmcblk0p2            3.6G    177.9M      3.3G   5% /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/loop53             512.0K    512.0K         0 100% /tmp/tcloop/sqlite3
/dev/loop54             128.0K    128.0K         0 100% /tmp/tcloop/libudev
192.168.1.80:/titan       2.7T      2.0T    670.6G  76% /mnt/music/nas

55個になった、、、
じゃあ音はどうなのかというと、例によって比較はできてないんだな、、、
これ以上は削るわけにはいかないような気がするし、この手法で出来るのはここらあたりまでかと思う。

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

piCore7でPPAPバックエンドは恐ろしいほど簡単にできる。
そう思っていたら、後から「こうすれば良かった」とか出てきてるので上記のエントリーに随時加筆訂正を入れていたんだけど、読みにくすぎる。

問題になっているのはバックエンドに関してだけだ。
なので、piCore7 PPAP Back-Endの作り方を、独立したエントリーにまとめることにした。

まず、microSDにpiCoreを焼いて、i2s DACの設定など必要に応じて記載して、ras piに刺して起動する。
詳細は、こちらのエントリーを参照のこと。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.htm
piCore7にmpdをインストールする方法

以下、sshでログイン後の流れを.ash_historyファイルからコピペ。

filetool.sh -b
sudo fdisk -u /dev/mmcblk0
sudo resize2fs /dev/mmcblk0p2
vi /opt/eth0.sh
chmod +x /opt/eth0.sh
vi /opt/bootsync.sh
vi /opt/.filetool.lst
filetool.sh -b

ここまでで、基本的なセッティングを終了。
続いて、nmapとalsaをインストール。

ras pi B+の場合。

tce-load -wi nmap.tcz alsa-modules-4.1.13-piCore+.tcz alsa.tcz

ras pi 2の場合。

tce-load -wi nmap.tcz alsa-modules-4.1.13-piCore_v7+.tcz alsa.tcz

これだけでいいのか、という感じ。

続いて、bootlocal.shを編集。
コマンド設定を書き込んで、piCore起動時にバックエンドとして機能するようにする。

vi /opt/bootlocal.sh

16/44.1のデータを受ける場合は、下記をbootlocal.shに追記する。

/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"

下記は24/192のデータを受ける場合。
192kHzがaplayで扱うことができるサンプリング周波数の上限なので、PPAPの上限も192kHzになる。

/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"

https://linux.die.net/man/1/aplay
aplay(1) - Linux man page

前回のエントリーで書いたけど、piCore7の場合は「-D plughw:0,0」の記載がなかったら、dmixが起動して48kHzにリサンプリングされる。
しかし、alsa-modules-4.1.13-piCore_v7+.tczとalsa.tczしかインストールされてない状態だと、mpdの再生自体が止まるようだ。ncmpcppに「paused」が表示されて、音が出なくなる。これら以外のalsa関連のtczがインストールされていないと、dmix自体が動かないし出力もしないらしい。
dmixがインストールされていないんじゃないかな。
というか、dmixがなかったら音が出ないのか？、、
あれこれインストールするより「-D plughw:0,0」を指定したほうがシンプルだし扱いやすくていいと思う。

この「hw」「plughw」という文字列だけど、どうもあちこちで説明の内容が違う。
環境によって違ってくるのか「aplay -l」で表示されるデバイス名を指定できるという話や、plughwを使うとリサンプリングされるという話もある（えぇー？）。
しかし、うちではplughwを記載したら、確かにフロントから出力したとおりのサンプリング周波数が表示されるんだよね、、、

以前に使っていた、
/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -M --period-size=512 --buffer-size=4096 -t raw -f S24_LE -r192000 -c2"
というようなコマンドだと、前述の通り音が出ない。alsa-dev.tcz alsa-doc.tcz alsaequal.tcz alsa-locale.tcz、、まあ、どれが働くのかわからないけど、これらがインストールされていたらdmixが働いて48kHzに変換された上で、音が出る。

/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_LE -r192000 -c2"
だったら「paused」が表示されて音が出ないんだけど、alsa-dev.tcz alsa-doc.tcz alsaequal.tcz alsa-locale.tczを追加インストールしても、「paused」で音が出なかった。「-D hw:0,0」はあちこちでdmixによるリサンプリングをさせない設定とされているんだけど、どうもpiCore7ではうまく機能しない。

/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"
これだったら、こちらの求めるように機能して音が出る。どこかでそうなるように設定されているのかもしれないけど、よく分からない。
現状、変換せずに音が出てくれたらいい、という感じだ。

閑話休題。

忘れないように設定を保存しリブートすれば、PPAP Back-Endとして機能する。

filetool.sh -b
sudo reboot

以下、Ras pi 2で設定して「df」を打った結果。

tc@box:~$ df
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   833.2M      9.5M    823.7M   1% /
tmpfs                   462.9M         0    462.9M   0% /dev/shm
/dev/mmcblk0p2           28.3M     13.1M     13.6M  49% /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_v7+
/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

インストールされたtceの一覧。

tc@box:~$ ls /usr/local/tce.installed/
alsa                            libelf                          libudev                         openssh
alsa-modules-4.1.13-piCore_v7+  libgcrypt                       libusb                          openssl
bzip2-lib                       libgpg-error                    lua-lib                         pcre
gamin                           libnl                           mc
glib2                           libpcap                         ncurses
libasound                       libssh2                         nmap
tc@box:~$ 

piCoreはループバックデバイス機能を使って、インストールしたファイルをイメージであるかのように扱いRAM上に展開する。で、合ってるのかな？
結果、軽量なシステムのはずだけどプロセスが多くなるみたい。
削れるものはあるかもしれないけど、僕のほうでは無理せずにこのまま使っている。

どこから書いたものか。
数ヶ月前、nano iDSD LEが壊れた。
PPAP(piped pcm audio play)のバックエンドをつないで音を出そうとしていたら、音が出なくなってしまったのだ。
うちのDACはfireface UCXのCCモードとi2s DACということになった。
LEは音源のサンプリング周波数をLEDの色で表示する機能があった。
CCモードのUCXは入力信号のサンプリング周波数を表示しない。
iPadをつないでいたら、TotalMix FXの画面から見えるんだろうけど、うちにはiPadはない。
そういうわけで、、、
バックエンドのUSB出力が48kHzにリサンプリングされているのについ最近まで気付かなかった。不覚だった、、、

もしもこれを読んで驚いている人がいたら、すみません。おわびします。

下記のエントリーには加筆訂正を入れました。
piCore7でppap (piped pcm audio play)を試みる
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180301a.htm

それでも、やはりPPAPの音はいい。
サンプリングの良し悪しなんかより、バックエンドで負担軽減のほうがずっと音質改善につながるってことなのかな、、、
感心したり凹んだりしていてもしょうがないので、ちょっとなんとかしようということになる。

なんで気付いたのか書いておかないといけない。

実はずいぶん前にTEAC UD-501を入手していた。
半額以下で売られていて、もともと興味があった機種だったので、迷った末に入手して、したはいいけど、なかなか出番がなくて死蔵していた。
LEから音が出なくなって、使ってみようかとも思ったけど、体調不良もあって伸び伸びに。
体調が回復して、数日前に思い出してつないでみた。
UCXに出力してるのと同じ96kHzで送ったら、UD-501のインジケーターに48kHzと表示されて、あれー？？？、ということに。

バックエンドにsshでログインして「cat /proc/asound/card*/pcm0p/sub0/hw_params」と打ってみたら「48000」と表示が。
フロントではどうかというと、フロントではalsaは働いていないので「No such file or directory」と表示される。
そうなんだよね、、、だから確認する手段が全くなかったわけではないのだ。
今から思えばだけど、抜けていて気付いてない。

最初は何で48kHzに変換されるのか分からず戸惑ったけど、48kHzといえば、、、というので思い出した。
alsaはデフォルトで48kHzに変換することがある。

過去にあげたエントリー↓5年前だけど、もっと遥か昔のような気がする、、、

http://blown-lei.net/endive/blosxom.cgi/audio_diary/20130302a.htm

mpdを終了し、mpd.confを編集する。

##	device		"hw:0,0"	# optional

文頭の##を削除して保存。
mpdを再起動する。

ALSAはデフォルトでdmixを有効にしている。
5年前はmpd.confのalsaの設定で修正した。
PPAPのバックエンドで同じ手は使えない。どこで設定したらいいのか、、、
alsaのサイトで手がかりがないか探す。

https://www.alsa-project.org/main/index.php/Asoundrc
Asoundrc - AlsaProject

Some notes:

The dmix PCM name is already defined in the global configuration file /usr/share/alsa/alsa.conf.

- The default sample rate for this device is 48000Hz. If you would like to change it use:

aplay -D"plug:'dmix:RATE=44100'" test.wav

- An example command for dmix plugin to use 44100Hz sample-rate and hw:1,0 output device:

aplay -Dplug:\'dmix:SLAVE=\"hw:1,0\",RATE=44100\' test.wav

わからん。 /usr/share/alsa/alsa.confは、piCoreにはない。
それに-D"plug:'dmix:RATE=44100'"って結局dmix使ってるんじゃ？

そういえば、lightMPDはどうしてるんだろう、、、
ということで、今一度、rpi2-smpdplayer-usb-20180103の中を探ってみる、、、
以前、うちのシステムにつなごうとしたことがあったんだけど、結局はよく分からず上手くいかなかった。
何か参考にできないか、、、

smpdplayer.confの中にこんな記載を見つける。

APLAY_ARGS="-D hw:0,0 --test-nowait -q -M --period-size=384 --buffer-size=21888 -t raw -f cd"

これってaplayコマンドのオプションそのものだよね、、、
これを参考に「-D hw:0,0」をうちのシステムに書き込んでみたけど、、、残念、動かない。

hw:がキーワードかな、、、あれこれネット上を探して次に参考にしたのがこちら。

http://takuya-1st.hatenablog.jp/entry/2016/04/18/011246
Raspberry Pi のオーディオ・デバイスを指定して音を再生する。 - それマグで！

aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Left.wav

こんな書き方があるのか、、、
これを参考に、うちのPPAP バックエンドの/opt/bootlocal.shを以下のように書き換える。

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

これで、ビンゴ！
UD-501のインジケーターに96kHzが表示されるようになりました！

そんなこんなで、fireface UCXにCCモード上限の96kHzで入力できるようになった。
バックエンドで「cat /proc/asound/card*/pcm0p/sub0/hw_params」を打つと「96000」と表示される。

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

UD-501はどうかといえば、192kHzまではPPAPで使える。384kHzは音が途切れ途切れで使えない。
NASマウントmpdからのUSB出力で、NAS音源の384kHzハイレゾを鳴らせないなら、PPAPで384kHzを鳴らせないのもRasberry pi2のLAN/USB周りの限界ということになるかと思う。
やってみたら、問題なく鳴る。
ということは、うちのPPAPの何処かに348kHzを送れない原因があるということだ。

この辺は今後の課題だ。

それにしても、UCXで気付かずに聴いていた48kHzの音はなんだか良かった。
このサイトの５年前のエントリーにも、48kHzのときのほうがゆったりして暖かい音が出ていた印象があるとか書いている。
今回の顛末で感じている印象も５年前と同じなのだ。-D plughw:0,0を書き込んだバックエンドから出る音は以前よりもクールで、それは48kHzにしても同様だ。

これはもしかしたら、dmixの音なのかもしれないと思い至った。
前々回のエントリーで書いた、mpdの設定で「mixer_type "software"」を記述する場所によって音色が違う気がする、というのも、alsaの項目内に書けばdmixが働き、そうでないなら働かないとしたら、なんとなく音色が違うのも辻褄が合う。
どんなものだろうか。

今回は、ほんと報告だけ。
宿題として残っていたタイトルの題目なんだけど、結論から言えば、ほぼ一瞬で決着が付いた。ppapの圧勝だった。
これは実は正直、意外でも何でもなくて、ppapで聴き始めた当初から予測していたことだった。
それぐらい、うちの環境では過去になかった音質で音楽が鳴っているのだ。

試聴環境を以下に列挙。

RAMメモリ再生の弱点は、複雑なエンコードなどの処理を行うmpdが動いているRas Piから、DACにデータを送っていることだ。NASのマウントなどネットワークからのノイズや負担を排除しても、mpd動作自体の負担からは逃れられない。
ppapのバックエンドは、上流から送られてきたデータをDACに受け渡す処理しかしていない。
処理が軽いということは、より安定して動くということだ。
それが決定的な違いを生んでいる。

最近、philewebで話題になっている通称miniPCという再生方式は、windowsでfoobar2000という、それかよ？というシステムで高音質を引き出しているらしい。上流はminimserverでupnp、下流のwindowsは不要なプロセスをカットしDACへの伝送に特化してるという。
設計思想がppapと似ているのが分かる。

http://asoyaji.blogspot.jp/2018/03/pc.html PCで音楽 - PCオーディオの最新

ppapのフロントでRAMメモリ再生を行なったらどうなのか、というのは突っ込んでいくとあるんだけど、いつかそのうちに気が向けば。
現状で十二分以上に不満がなくて、音楽に浸るほうが先なんだよね。

最近のシステム構成は下図のような感じ。

piCore7をpiped pcm audio play方式で使い始めて１ヶ月になる。
僕はずっとmpdクライアントによる音量調節（mpd.confへの記述 : mixer_type "software" 設定によるもの）はalsaを介するものだ思い込んでいて、pipe出力を使うppapでは使えないという理解をしていたんだけど、実際にはmpdの仕様でずっと昔から使えるということが数日前に判明した。
実際、設定してみたらncmpcppから音量調整ができる。
利便性という面でもNASマウント音源をmpdで再生するのと全く遜色なしということになる。
mpd.confの設定は、うっかり間違えて覚えたまま気付かずにいる事が他にもあるかもしれない。バージョンアップで設定方法が変わってるものもある。チェックしておく必要があると思う。

先日、このsoftwareボリュームを使えないと思い込んで、fireface UCX付属のリモートコントローラーを使ってデジタルボリュームを調整したら、アンプのボリュームを弄るよりいいんじゃないかと考えて、試してみた。というのも、うちでは上流の音量を下げなかったらアンプのボリュームをかなり絞る必要があるから。DACの出力を絞ることができれば、アンプのボリュームを開けることが出来る。
これが、あんまり良くなかった。
ちょい聞き、大して差がないけど、プラセボも疑うけど、なんでか、微妙なところで、つまらなく聴こえた。潤いが失われるというのか、砂っぽくなるというか、音楽の生命感が微妙に減衰する。使わないほうがいい。たぶん、DACもデジタルトラポ同様、余計な仕事をさせないほうが音は良いんだと思う。

今回、結果として比較することになったけど、mpdのデジタルボリュームはそうした音質の変化が少ないと思う。

いや、正確には違うかな、、、
以前はaudio_outputの項目内に、type "alsa"と併記してmixer_type "software"と書き込んでいた。
現在はalsa出力は使わないので、audio_output項目とは別に独立したmixer_typeの項目で設定している。
audio_output項目の中に設定していたときは、ボリュームを絞るとなんとなく柔らかい音色になっていた。聴きやすいといえばいいけど、ゆるいのはゆるい。
mixer_typ項目で設定してから、それがなくなった。同じ音質で音量だけ下がる。その一方、音量変化のカーブは急激になった気がする。ちゃんと比較試聴したわけではないんだけど。

アンプのアナログボリュームと比べてどうかは確認していない。
それでも十二分に実用になるレベルだと確認できたのでとりあえず良かった。

そんなこんなで、最近はppapで聴いてばかりいる。
384kHz対応のnano iDSD LEが壊れてしまって、現状うちで対応できるのはi2s DACで192kH、fireface UCX CCモードで96kHzというのもあって、いっそのことと割り切って当面ppapで96/24に固定でいいか、となっている。
768kHz対応するDACが出てたりして、どうしようかと思うけど、しばし考えようかという感じ。

過去に何回か、複数のPCで機能を役割分担するデジタルトラポの方式を試したことがあったけど（upnpやhtmlでの伝送を試したことがある）、共通して感じるのは音色の軽さだ。ppapの音も軽い。軽いというよりスピード感といった方がいいのか。

普通、音が軽い場合は密度感も低い。
例えばケースを付けないRas piにvolumio1.55を刺してi2s DACを鳴らした場合、音は軽く密度も低くなる。ポップミュージック向きのノリが良くて楽しい音で、馴染みやすく気安く聴けるけど、そこでケースを付けたら忽ち楽しくない音になったりする。

役割分担方式の場合、軽いんだけど密度が高い。
重いはずのものが軽く動く感じ。そうなると、まるで音がエネルギーの塊のように見えてくるのだ。聴いていて驚きを感じる音になる。
しかもそれが、極めてさりげない。
この、さりげない、危なげない感じというのは、システムに余計な負担がかかっていない証左だと思う。

ppapは以前に試した役割分担方式よりも、いや、今まで聴いたどのシステムよりも、この驚き感とさりげなさが強い気がする。当たり前のように自然な音なのに、エネルギー感、生命感が強い。
どちらかの方向で優れているのではなく、両立しているのがいい。

こういっては何だが、piCoreはハイファイ再生が得意なディストリとは言えないと思っている。もっと優秀なディストリが沢山あるからだ。
例えば端末でtopを打ったら、何をしてるのか分からないタスクがたくさん表示される。lightMPDベースのバックエンドとか、恐ろしいほどすっきりしている（うちでは起動はできたが、残念ながら音が出なくて根負けした）。比べたらpiCoreは、ゆるいはずだ。せめてリアルタイムカーネル化できないかと思ったりしたけど、能力がないので素のまま使っている。
そんな状態にも関わらず、これだけ鳴れば凄いんじゃないか、と思うだけの音が出る。
それは、この方式が優れているからだと思う。

メモリ再生と比較してみないといけないんだけど、暇がない。
いや、いけないということはないんだけど、しておかないとすっきりしないという感じ。宿題を置いたままで気楽に遊べない感じだ。いつかそのうちにしようと思う。

システム構成図では、新しいNASとしてHS-251が追加になっているんだけど、まだ実際には繋がっていない。
近日中にHDを入手して設置する予定。
HS-210だけでは足りなくなってきたので追加することにした。HS-210のHDを変えることで容量を増やす手もあるんだけど、時間も手間もかかる上に、思ったほど増やせないし、使わなくなった3TBのHDが2つ手元に残る、なんてことになるので、、、いっそ追加でいいやということに。
NASが増えるのはノイズ源が増えるということではあるけど。

イーサネットハブを一部、NETGEAR GS105E-200JPSに交換している。
分かりやすく説明してるサイトのアドレスをメモ。
https://cre027t.jp/gs105e/
NETGEAR GS105Eをオーディオ用HUBとして使う

このハブは、ポートを選択してvlanを構成することができるので、ちょうどいいのでppapのバックエンドを家庭内LANと切り離すの使うことにした。
効果は、プラセボレベルで効いている感じ。
なんとなくだけど、切り離した方がいいのかな、というか。
UCXのデジタルボリュームとmpdのsoftwareボリュームの比較の方が、これよりはもう少し判断しやすい感じかな。パケットは遮断できても電気的なノイズは完全に遮断できるわけじゃないし、ハブ自体が何かをしたらノイズが増える可能性もある。微妙なものだという気がする。
しばらく使いながら様子を見ようという感じだ。

先日、リサプラーによって再生音の定位に違いを生じるかどうか、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によっても違うんだし。きりがないっちゃきりがない。

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

１月半ばからppapに取り組んでいる。
２月上旬での状況を前回のエントリーに書いたんだけど、その後、体調崩して人生初めての入院したりで、まだ本調子じゃない。
それでもようやく進捗があった。
piCore7をフロント化するのに成功した。

追記。せっかく作ってあったので構成図をアップ。

しかし、そもそも何でpiCore7なのか。
今回、フロントをどうするかはかなり難航した。普段使いのノートPC（Fedora26、27）は簡単にフロント化できたんだけど、アップサンプリングがうまくいかず原因は不明。それもあってRaspberry Pi2のフロント化に臨んだんだけど、これが難しかった。

まず、piCoreはpipeが使えないと来た。
その続きで、ライブラリを追加したりshellを変えてみたり、あれこれ試みたけど失敗続き。

次にRaspbian stretchを試みた。以前はちゃんと動いてmpdのインストールも出来たはずだが、今回これが起動しない。いや、起動しているんだけどdhcpサーバからipアドレスが振られないようで、LANに繋がって来ないのだ。原因不明。昔のjessieも引っ張り出してみたけど同様。

じゃあVolumio2でどうか。なんだか構造がよく分からない。mpd.confをいじったりncmpcppでアクセスして操作しても出音に反映されないことがある。どうなってるんだか、分からない。この際と思ってvolumio1.55でやってみたけど、やはりpipeが壊れてると表示される。

Archphile、、、これもLANに繋がらない。

そうこうして、piCore7に戻ってきたのだ、、、
今回あれこれやるうちに、ようやく気付いた。
piCoreの何がいいって、必ず普通に起動するのだ！

動かないことがあるディストリは、繰り返し試みたり試したりするには向かない。
その点、piCoreは焼くのは一瞬だし起動しないということがないしセッティングも短時間で出来上がる。扱いやすいという点で他の追随を許さないのだ（当家比較）。そういうわけで、ついつい使ってしまうんだと思う。

Front

そういうわけで、piCore7に戻ってきた。ようやくなんとかなったけど、何故なんとかなったのか正確な理由は分からない。
今回の流れを記載していく。.ash_historyファイルからコピペ。

filetool.sh -b
sudo resize2fs /dev/mmcblk0p2
ifconfig
vi /opt/eth0.sh
chmod +x /opt/eth0.sh
vi /opt/bootsync.sh
vi /opt/.filetool.lst
filetool.sh -b

ここまでで、基本的なセッティングを終了。
詳細は、http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.htm こちらのエントリーを参照のこと。
続いて、環境を構築していく。

mpdをインストールするのに必要なコンパイラ等々プログラムをインストール、、、
はっきりしないんだけど、flex、bison、gdbmあたりを追加インストールしたらpipeを使えるようになったような。どれが効いているのかは未確認。

tce-load -wi \
gcc_base-dev.tcz gcc-doc.tcz gcc_libs-dev.tcz gcc_libs.tcz gcc-locale.tcz gcc.tcz \
glib2-dev.tcz glib2-doc.tcz glib2-locale.tcz glib2-python.tcz glib2-dev.tcz \
glibc_add_lib.tcz glibc_apps.tcz glibc_base-dev.tcz glibc_gconv.tcz glibc_i18n_locale.tcz \
glib-networking-dev.tcz glib-networking-locale.tcz glib-networking.tcz \
binutils-dev.tcz binutils-doc.tcz binutils-locale.tcz binutils.tcz \
ncurses-dev.tcz make-doc.tcz make-locale.tcz make.tcz automake.tcz \
autoconf-doc.tcz autoconf.tcz libtool-dev.tcz libtool-doc.tcz \
compile-essentials.tcz squashfs-tools.tcz bash-locale.tcz bash.tcz bc-doc.tcz bc.tcz \
pkg-config-doc.tcz pkg-config.tcz cmake-doc.tcz cmake.tcz

tce-load -wi \
flex-dev.tcz flex-doc.tcz flex-locale.tcz flex.tcz \
gdbm-dev.tcz gdbm-doc.tcz gdbm-locale.tcz gdbm.tcz \
bison-dev.tcz bison-doc.tcz bison-locale.tcz bison.tcz \
python-dev.tcz python-doc.tcz python.tcz boost-dev.tcz boost.tcz \
doxygen-doc.tcz doxygen.tcz pv-doc.tcz pv-locale.tcz pv.tcz \
bash-doc.tcz bash-locale.tcz bash.tcz bc-doc.tcz bc.tcz

次にalsa、nmap、mpdが使うライブラリやエンコーダーをインストール。

tce-load -wi \
alsa.tcz alsa-config.tcz alsa-doc.tcz alsa-dev.tcz alsaequal.tcz \
alsa-locale.tcz alsa-modules-4.1.13-piCore_v7+.tcz alsa-modules-4.1.20-piCore_v7+.tcz \
nmap-doc.tcz nmap.tcz

tce-load -wi \
libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz \
flac-dev.tcz flac.tcz flac-doc.tcz libcue.tcz libcue-dev.tcz \
icu-dev.tcz icu.tcz libid3tag-dev.tcz libid3tag.tcz \
libmad-dev.tcz libmad.tcz mpg123.tcz lame-dev.tcz lame-doc.tcz lame.tcz

tce-load -wi libmpdclient-dev.tcz libmpdclient-doc.tcz libmpdclient.tcz

filetool.sh -b

続いて、mpdをコンパイルしてインストール。今回使ったのはv0.19.19。
コマンドを羅列。

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 --enable-pipe-output

configureの結果表示を転記してみる。

########### MPD CONFIGURATION ############

Archive support:
	(+bzip2) (-ISO9660) (-ZIP) 
Client support:
	(+IPv6) (+TCP) (+UNIX Domain Sockets) 
Storage support:
	(-NFS) (-SMB) 
File format support:
	(-AAC) (-AdPlug) (+DSD) (-C64 SID) (-FFMPEG) (+FLAC) (-FluidSynth) (-GME) 
	(+libsndfile) (-MikMod) (-MODPLUG) (+MAD) (-MPG123) (-Musepack) 
	(-Opus) (-OggTremor) (+OggVorbis) (-WAVE) (-WavPack) (-WildMidi) 
Other features:
	(+libsamplerate) (-libsoxr) (+libmpdclient) (+inotify) (+SQLite) 
Metadata support:
	(+ID3) 
Playback support:
	(+ALSA) (+FIFO) (+File Recorder) (+HTTP Daemon) (-JACK) 
	(-libao) (+OSS) (-OpenAL) (-OS X) (+Pipeline) 
	(-PulseAudio) (-ROAR) (-SHOUTcast) (-Solaris) (-WinMM) 
Streaming encoder support:
	(+FLAC) (+LAME) (-Shine) (+Ogg Vorbis) (-Opus) (-TwoLAME) (+WAVE) 
Streaming support:
	(-CDIO_PARANOIA) (-CURL) (-SMBCLIENT) (-Soundcloud) 
	(-MMS) 
Event loop:
	epoll

##########################################

Generating files needed for compilation
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/doxygen.conf
config.status: creating systemd/mpd.service
config.status: creating config.h
config.status: executing depfiles commands
MPD is ready for compilation, type "make" to begin.
tc@box:~/mpd-0.19.19$ 

(+Pipeline)と表示されている。以前はここまで出来てもmakeで通らなかった。

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
sudo mv *tcz* /mnt/*2/tce/optional
sudo vi /mnt/*2/tce/onboot.lst

インストール完了。あとはmpd.conf、mpdの動作環境を作成していく。

cp m*9/doc/mpdconf.example .mpdconf
sudo rm -rf mpd*
vi .mpdconf
mkdir .mpd
mkdir .mpd/playlists

filetool.sh -b

mpd.confの記載例。

music_directory "/mnt/music"
playlist_directory "~/.mpd/playlists"
db_file "~/.mpd/database"
log_file "~/.mpd/log"
pid_file "~/.mpd/pid"
state_file "~/.mpd/state"
sticker_file "~/.mpd/sticker.sql"

auto_update     "no"

# audio_output {
# type "alsa"
# name "My ALSA Device"
# device "hw:0,0"
#
# mixer_device "default"
# mixer_control "PCM"
# mixer_index "0"
# }

mixer_type "software" ## hardware, software or none
replay_gain_handler "none" ## software, mixer or none

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.82 4444"
}

filesystem_charset "UTF-8"
id3v1_encoding "UTF-8"

上記のmpd.confに合わせてmusic_directoryを設定する例。
piCore起動時にmusic_directoryを作って、NASのtitanディレクトリをマウントするように設定している。

vi /opt/bootlocal.sh

（下記をbootlocal.shに追記）

mkdir /mnt/music
mkdir /mnt/music/nas
mkdir /mnt/music/ram
touch /mnt/music/ram/dummy.cue
chmod -R 777 /mnt/music
mount -o addr=192.168.1.80,nolock -t nfs 192.168.1.80:/titan /mnt/music/nas

これら設定を忘れず保存すること。

filetool.sh -b

以上で、piCore7のフロント化、完成。
ちょっと追記。使用に際してはsshでログインしmpdを起動させる仕様。自動起動にはしていない。

Back-End

バックエンドはraspberry pi B+/2、piCore7で組んでいる。
これは初期状態にalsaとnmapしかインストールしていないような状態で、それでもちゃんと動いている。
period-sizeの設定によってCPU使用率がかなり変わるようなので、うちでは256と多めに設定している。そのほうがCPU使用率が下がる。逆にbuffer-sizeは2048と少なめだ。どのくらいがいいのかは確かめていない。

filetool.sh -b
sudo resize2fs /dev/mmcblk0p2
cd /opt
vi eth0.sh
chmod +x eth0.sh
sudo vi bootsync.sh
vi .filetool.lst
filetool.sh -b

（ わかりにくいので追記。
ここまでの流れは.ash_historyファイルからのコピペ。
いくつか記録されてないコマンドがあったりする。
詳細は、http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.htm こちらのエントリーを参照のこと。
）

cd

（ 追記。
下記のalsa、nmapのインストールコマンドはras pi B+の場合のコマンド。
pi2/3の場合、alsa-modulesの名称が違うので注意を。
 ）

tce-load -wi \
nmap-doc.tcz nmap.tcz alsa-config.tcz alsa-dev.tcz alsa-doc.tcz \
alsaequal.tcz alsa-locale.tcz alsa-modules-4.1.13-piCore+.tcz \
alsa-modules-4.1.20-piCore+.tcz alsa.tcz

（ 追記。
4月13日の時点でras pi B+に7.xだとnmapのインストールがうまくいかない。
9.xだったら下記でうまくいく。

tce-load -wi \
nmap-doc.tcz nmap.tcz \
alsa-modules-4.9.22-piCore.tcz alsa-plugins-dev.tcz alsa-plugins.tcz \
alsa.tcz alsa-utils-doc.tcz alsa-utils-locale.tcz alsa-utils.tcz

以上、追記した。 ）



filetool.sh -b

vi /opt/bootlocal.sh

（下記をbootlocal.shに追記。適宜編集）

# /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"
/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=256 --buffer-size=2048 -t raw -f S24_LE -r96000 -c2"
# /usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -D plughw:0,0 -M --period-size=256 --buffer-size=4096 -t raw -f S24_LE -r192000 -c2"


（追記後、設定を保存）

filetool.sh -b

5月22日、追記。
上記に「 -D plughw:0,0」の記述を書き加えた。
これがないとUSBに出力が自動的に48kHzにリサンプリングされる。
alsaのデフォルトらしい。
i2s出力はリサンプリングされずに出力されるようだ。

音質評価は未だしていない。追々、余裕があるときに。