abk1's scratched blog 3

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

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

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

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

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

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

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

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

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

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

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

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

aplay: version 1.1.7 by Jaroslav Kysela 

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

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

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

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

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

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

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

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

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

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

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

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

先日、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で聴き始めた当初から予測していたことだった。
それぐらい、うちの環境では過去になかった音質で音楽が鳴っているのだ。

試聴環境を以下に列挙。

音源	Faure - Requiem - Philippe Herreweghe, La Chapelle Royale, Ensemble Musique Oblique Booker T. & The M.G.'s - Melting Pot
DAC	fireface UCX CCモード(24/96) / USB029H2RP
アンプ / スピーカー	SM-SX100 / 4425mk2 / T900A

方式	RAMメモリ再生	PPAP方式
Hardware / OS	raspberry pi 2 / piCore7	Front - raspberry pi 2 / piCore7 Back End - raspberry pi 2 / piCore7
software	mpd 0.19.19, libsamplerate, alsa	Front - mpd 0.19.19, libsamplerate, nfs, ncat Back End - ncat, aplay

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メモリ再生を行なったらどうなのか、というのは突っ込んでいくとあるんだけど、いつかそのうちに気が向けば。
現状で十二分以上に不満がなくて、音楽に浸るほうが先なんだよね。

１月半ばから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出力はリサンプリングされずに出力されるようだ。

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

昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが２つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。

https://github.com/papalius/symphonic-mpd/wiki/%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%81%A8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E3%82%92%E7%B9%8B%E3%81%90%E6%8A%80%E8%A1%93(piped-pcm-audio-play)

バックエンドは、ncat を使ってTCP4444ポートで待ち受け、流れてきたraw PCMデータをaplayに横流しします。
ncat・aplay部分のsystemdサービス定義は以下のような感じです。

ExecStart=/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay-1.1.5 -M --period-size=64 --buffer-size=136710 -t raw -f cd"

フロントのmpdは、デコード済みのraw PCMをpipe outputで取り出し、ncatでバックエンドのTCP4444ポートに流し込みます。
mpd.confのaudio_outputはこんな感じです。

audio_output {
  type "pipe"
  name "PIPE"
  always_on "yes"
  command "ncat 192.168.x.x 4444"
}

肝は、DACへの出力にalsaしか使わないということだと思う。

Linux系PCからのデジタルオーディオ出力に一般的に使われてきたmpdが外されている。
データ仲介ソフトとしてncatを使うことで「mpd + alsa」だったものが「alsaだけ」になっているということ。
mpdは「フロント」で音楽データを処理し「バックエンド」のalsaに送る役割、つまり一般的なupnpシステムであれば、dlnaサーバーソフト（例えばminimserverなど）が担ってきた役割を受け持っている、と言っていいのかな。

デジタルトランスポートとしての機能を複数のPCで役割分担させることによって、高音質化を目指す前例はたくさんある。しかしそれはJPLAYだったりupnp/dlnaシステムを使用したものだったりして、僕のニーズには合わないものだった。うちではlinuxでflac + cue sheetが使えないといけないのだ。
他にいくつか、僕なりに試みた方法もあったけど力及ばず満足できる物にならなかった。

当時、いろいろと試みる中で、minimserverを動かしてみたときは下図のような構成。
エントリーにしてアップしている。MinimServerをRaspberry Pi B+で動かしてみた

今回、ppapを知ったとき、過去に求めながら発見できなかったものが提示されていると思った。
これはやってみないといけないと思ったんだけど、あれこれあって、年を越し、月日が過ぎるうちに、なんだか雲行きが怪しくなってきた。本家サイトで公開中断が続いている。気にならないわけじゃないけど、だからといって僕のほうで余裕が出来たにも関わらず自粛？して手を付けないというのもおかしな話なので、手元の機材を弄り始めた、というところ。

僕は変なところで捻くれ者なんだろう、いくつか使えそうなディスクイメージがアップされているにも関らず、手持ちのものから弄っている。慣れないディストリの設定とか頭使ってやる余裕ないなあっていう感じ。老化現象だ。細かい設定とか神経配る気分がさらさら無くなっているのを感じるこの頃で、かなりマイペースだ。

まず、フロント。
試しに普段使いのCompaq 6730b Fedora 26を用意。既にmpdがインストール済み。
これにnmapをインストール。nmapに転送ソフトncatが含まれている。
dnf install nmap
さくっと終わる。
続いてmpd.confに、前述記述を参考にpipeの出力設定を書き込み

audio_output {
        type            "pipe"
        name            "my pipe"
        always_on "yes"
command "ncat 192.168.1.xxx 4444"
}

次にバックエンド。
Ras Pi B+にpiCore7を焼いてi2sDACの設定を書き込み刺して起動。
ip固定など初期設定して、alsaとnmap関連のtczをインストール。
上記のサイトやncat、aplayのネット上のマニュアルを参考に、下記コマンド（いきなりだけどbuffer-sizeは減らしてみた）を打ったらバックエンドは待機状態となる。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -M --period-size=64 --buffer-size=512 -t raw -f cd

フロントに戻って、mpdを再起動。
これでpipeからncatを使って音楽データを出力できるようになる。
ncmpcppでコントロール。

若干の試行錯誤はしたけど、比較的すんなり音が出た。
このとき、試しで継いでいたのは小さなパワードスピーカー。
その音を聴くと、なんだか凄そうと感じられるものがある。いつもと違う感というか。
図にしたら、こんな感じ。
minimserverを使ったupnpより、かなりすっきりしている。特にDACの直前が。

さて、sshからバックエンドに打った前記コマンドを、直接そのままバックエンドのbootlocal.shファイルに記載し、リブートしてみる。
バックエンドの起動を確認し、手元の6730bでncmpcppを操作したら、音が出た。
これで、起動後にsshでログインしてコマンドを打ったりしなくても、起動させたらそのままバックエンドとして機能するのを確認した。

次にメインシステムのnano iDSD LEに継いでいるRas Pi 2、piCore7にnmapをインストールして、バックエンドにして同様に音を出してみた。
なかなかいいかもしれない。鮮度が違う気がする（所謂プラセボ効果という奴）。

試験運用は上々。
フロントをRas Pi 2にして運用したい。
ウェブとか見てる普段使いの6730bをオーディオメインシステムのmpdサーバーにするのはどうかと思うので。
下図のような感じに出来れば。

先ほど使ったRas Pi 2、piCore7のmpd.conf設定を書き変える。
これで簡単に出力できるかな、と思ったら、pipeなんて出力は対応してないよ、とアラートが出てmpdが起動しない。
えぇー、、何それ。

fatal_error: line 109: No such audio output plugin: pipe

さて、弱った。
pipeが使えないって意味がわからない。pipeって「|」でしょ？使えないってありなの？linux的に。
本家サイトではvolumio2でもフロントに使えるという話もあり、いっそ使ってみようかとも思ったけど、、、なんか気が進まない。
つうか、volumio1.55もraspbianも、気付いたら１年もまともに触ってないのだ。
volumio2って、どうなってるのって感じ。
pipeについてあれこれと調べる。pipeというのは「pipeline」とも言われ、shellの機能として組み込まれているらしい？ということは分かった。
でも、結局、よくわからないのだった。

mpdをソースからコンパイルする際に指定したら、pipelineを使えるようにできるらしいということは分かった。
いっそ、こんな感じ。
./configure --enable-pipe-output
一見、きれいにconfigureは通るが、makeでエラーになる、、、
config.logを読むも、、、何が何だか分からない。

しかたない、raspbian stretchでやってみるか、、、
結果だけ言うと、pipeを使えるようにインストールはできたけど、いざ音を出そうとしたら「paused」で音が出ない。
/var/log/mpd/mpd.logを確認。

sh: 1: cannot create ncat: Permission denied
Jan 28 04:05 : errno: "my pipe" [pipe] failed to play: Write error on pipe: Broken pipe
Jan 28 04:05 : output: Failed to open audio output

Permission deniedって、どうしたらいいのか。mpdにroot権限あげたらいいのか？
いろいろやってみたけど、サジを投げた。

いっそ駄目元でpiCore6でやってみっか、、、
おお、、、いつの間にか、tczにmpdもdoxygenもboostもあるじゃん、、、
しかし結果はpiCore7と同様。pipe2がない？ということで、ソースからのコンパイルも失敗。

半月が過ぎて、結局、フロントは6730bのFedoraでしかうまくいってない、、、
これで本家もpipe使うのをやめたのかな、、、
、、、Fedoraって、ラズパイで動くかな、、、
Fedora27で用意されてるじゃないですか！Raspberry Pi 2/3で動くディストリが！

まあ、そんなこんなでFedora27をラズパイ2で動かそうとして、なにをどうミスったか、母艦6730bのFedora26をクラッシュさせてしまった。
OS再インストール環境の再構築をして、このエントリーを書いている。
まあ、なんだな、ちょっと休む。
ひどい風邪も引き込んだし、幸田浩子のアベマリアでもBGMにしながら養生しよう、、、

昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが２つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。

https://github.com/papalius/symphonic-mpd/wiki/%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%81%A8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E3%82%92%E7%B9%8B%E3%81%90%E6%8A%80%E8%A1%93(piped-pcm-audio-play)

バックエンドは、ncat を使ってTCP4444ポートで待ち受け、流れてきたraw PCMデータをaplayに横流しします。
ncat・aplay部分のsystemdサービス定義は以下のような感じです。

ExecStart=/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay-1.1.5 -M --period-size=64 --buffer-size=136710 -t raw -f cd"

フロントのmpdは、デコード済みのraw PCMをpipe outputで取り出し、ncatでバックエンドのTCP4444ポートに流し込みます。
mpd.confのaudio_outputはこんな感じです。

audio_output {
  type "pipe"
  name "PIPE"
  always_on "yes"
  command "ncat 192.168.x.x 4444"
}

肝は、DACへの出力にalsaしか使わないということだと思う。

Linux系PCからのデジタルオーディオ出力に一般的に使われてきたmpdが外されている。
データ仲介ソフトとしてncatを使うことで「mpd + alsa」だったものが「alsaだけ」になっているということ。
mpdは「フロント」で音楽データを処理し「バックエンド」のalsaに送る役割、つまり一般的なupnpシステムであれば、dlnaサーバーソフト（例えばminimserverなど）が担ってきた役割を受け持っている、と言っていいのかな。

デジタルトランスポートとしての機能を複数のPCで役割分担させることによって、高音質化を目指す前例はたくさんある。しかしそれはJPLAYだったりupnp/dlnaシステムを使用したものだったりして、僕のニーズには合わないものだった。うちではlinuxでflac + cue sheetが使えないといけないのだ。
他にいくつか、僕なりに試みた方法もあったけど力及ばず満足できる物にならなかった。

当時、いろいろと試みる中で、minimserverを動かしてみたときは下図のような構成。
エントリーにしてアップしている。MinimServerをRaspberry Pi B+で動かしてみた

今回、ppapを知ったとき、過去に求めながら発見できなかったものが提示されていると思った。
これはやってみないといけないと思ったんだけど、あれこれあって、年を越し、月日が過ぎるうちに、なんだか雲行きが怪しくなってきた。本家サイトで公開中断が続いている。気にならないわけじゃないけど、だからといって僕のほうで余裕が出来たにも関わらず自粛？して手を付けないというのもおかしな話なので、手元の機材を弄り始めた、というところ。

僕は変なところで捻くれ者なんだろう、いくつか使えそうなディスクイメージがアップされているにも関らず、手持ちのものから弄っている。慣れないディストリの設定とか頭使ってやる余裕ないなあっていう感じ。老化現象だ。細かい設定とか神経配る気分がさらさら無くなっているのを感じるこの頃で、かなりマイペースだ。

まず、フロント。
試しに普段使いのCompaq 6730b Fedora 26を用意。既にmpdがインストール済み。
これにnmapをインストール。nmapに転送ソフトncatが含まれている。
dnf install nmap
さくっと終わる。
続いてmpd.confに、前述記述を参考にpipeの出力設定を書き込み

audio_output {
        type            "pipe"
        name            "my pipe"
        always_on "yes"
command "ncat 192.168.1.xxx 4444"
}

次にバックエンド。
Ras Pi B+にpiCore7を焼いてi2sDACの設定を書き込み刺して起動。
ip固定など初期設定して、alsaとnmap関連のtczをインストール。
上記のサイトやncat、aplayのネット上のマニュアルを参考に、下記コマンド（いきなりだけどbuffer-sizeは減らしてみた）を打ったらバックエンドは待機状態となる。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -M --period-size=64 --buffer-size=512 -t raw -f cd

フロントに戻って、mpdを再起動。
これでpipeからncatを使って音楽データを出力できるようになる。
ncmpcppでコントロール。

若干の試行錯誤はしたけど、比較的すんなり音が出た。
このとき、試しで継いでいたのは小さなパワードスピーカー。
その音を聴くと、なんだか凄そうと感じられるものがある。いつもと違う感というか。
図にしたら、こんな感じ。
minimserverを使ったupnpより、かなりすっきりしている。特にDACの直前が。

さて、sshからバックエンドに打った前記コマンドを、直接そのままバックエンドのbootlocal.shファイルに記載し、リブートしてみる。
バックエンドの起動を確認し、手元の6730bでncmpcppを操作したら、音が出た。
これで、起動後にsshでログインしてコマンドを打ったりしなくても、起動させたらそのままバックエンドとして機能するのを確認した。

次にメインシステムのnano iDSD LEに継いでいるRas Pi 2、piCore7にnmapをインストールして、バックエンドにして同様に音を出してみた。
なかなかいいかもしれない。鮮度が違う気がする（所謂プラセボ効果という奴）。

試験運用は上々。
フロントをRas Pi 2にして運用したい。
ウェブとか見てる普段使いの6730bをオーディオメインシステムのmpdサーバーにするのはどうかと思うので。
下図のような感じに出来れば。

先ほど使ったRas Pi 2、piCore7のmpd.conf設定を書き変える。
これで簡単に出力できるかな、と思ったら、pipeなんて出力は対応してないよ、とアラートが出てmpdが起動しない。
えぇー、、何それ。

fatal_error: line 109: No such audio output plugin: pipe

さて、弱った。
pipeが使えないって意味がわからない。pipeって「|」でしょ？使えないってありなの？linux的に。
本家サイトではvolumio2でもフロントに使えるという話もあり、いっそ使ってみようかとも思ったけど、、、なんか気が進まない。
つうか、volumio1.55もraspbianも、気付いたら１年もまともに触ってないのだ。
volumio2って、どうなってるのって感じ。
pipeについてあれこれと調べる。pipeというのは「pipeline」とも言われ、shellの機能として組み込まれているらしい？ということは分かった。
でも、結局、よくわからないのだった。

mpdをソースからコンパイルする際に指定したら、pipelineを使えるようにできるらしいということは分かった。
いっそ、こんな感じ。
./configure --enable-pipe-output
一見、きれいにconfigureは通るが、makeでエラーになる、、、
config.logを読むも、、、何が何だか分からない。

しかたない、raspbian stretchでやってみるか、、、
結果だけ言うと、pipeを使えるようにインストールはできたけど、いざ音を出そうとしたら「paused」で音が出ない。
/var/log/mpd/mpd.logを確認。

sh: 1: cannot create ncat: Permission denied
Jan 28 04:05 : errno: "my pipe" [pipe] failed to play: Write error on pipe: Broken pipe
Jan 28 04:05 : output: Failed to open audio output

Permission deniedって、どうしたらいいのか。mpdにroot権限あげたらいいのか？
いろいろやってみたけど、サジを投げた。

いっそ駄目元でpiCore6でやってみっか、、、
おお、、、いつの間にか、tczにmpdもdoxygenもboostもあるじゃん、、、
しかし結果はpiCore7と同様。pipe2がない？ということで、ソースからのコンパイルも失敗。

半月が過ぎて、結局、フロントは6730bのFedoraでしかうまくいってない、、、
これで本家もpipe使うのをやめたのかな、、、
、、、Fedoraって、ラズパイで動くかな、、、
Fedora27で用意されてるじゃないですか！Raspberry Pi 2/3で動くディストリが！

まあ、そんなこんなでFedora27をラズパイ2で動かそうとして、なにをどうミスったか、母艦6730bのFedora26をクラッシュさせてしまった。
OS再インストール環境の再構築をして、このエントリーを書いている。
まあ、なんだな、ちょっと休む。
ひどい風邪も引き込んだし、幸田浩子のアベマリアでもBGMにしながら養生しよう、、、

昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが２つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。

https://github.com/papalius/symphonic-mpd/wiki/%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%81%A8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E3%82%92%E7%B9%8B%E3%81%90%E6%8A%80%E8%A1%93(piped-pcm-audio-play)

バックエンドは、ncat を使ってTCP4444ポートで待ち受け、流れてきたraw PCMデータをaplayに横流しします。
ncat・aplay部分のsystemdサービス定義は以下のような感じです。

ExecStart=/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay-1.1.5 -M --period-size=64 --buffer-size=136710 -t raw -f cd"

フロントのmpdは、デコード済みのraw PCMをpipe outputで取り出し、ncatでバックエンドのTCP4444ポートに流し込みます。
mpd.confのaudio_outputはこんな感じです。

audio_output {
  type "pipe"
  name "PIPE"
  always_on "yes"
  command "ncat 192.168.x.x 4444"
}

肝は、DACへの出力にalsaしか使わないということだと思う。

Linux系PCからのデジタルオーディオ出力に一般的に使われてきたmpdが外されている。
データ仲介ソフトとしてncatを使うことで「mpd + alsa」だったものが「alsaだけ」になっているということ。
mpdは「フロント」で音楽データを処理し「バックエンド」のalsaに送る役割、つまり一般的なupnpシステムであれば、dlnaサーバーソフト（例えばminimserverなど）が担ってきた役割を受け持っている、と言っていいのかな。

デジタルトランスポートとしての機能を複数のPCで役割分担させることによって、高音質化を目指す前例はたくさんある。しかしそれはJPLAYだったりupnp/dlnaシステムを使用したものだったりして、僕のニーズには合わないものだった。うちではlinuxでflac + cue sheetが使えないといけないのだ。
他にいくつか、僕なりに試みた方法もあったけど力及ばず満足できる物にならなかった。

当時、いろいろと試みる中で、minimserverを動かしてみたときは下図のような構成。
エントリーにしてアップしている。MinimServerをRaspberry Pi B+で動かしてみた

今回、ppapを知ったとき、過去に求めながら発見できなかったものが提示されていると思った。
これはやってみないといけないと思ったんだけど、あれこれあって、年を越し、月日が過ぎるうちに、なんだか雲行きが怪しくなってきた。本家サイトで公開中断が続いている。気にならないわけじゃないけど、だからといって僕のほうで余裕が出来たにも関わらず自粛？して手を付けないというのもおかしな話なので、手元の機材を弄り始めた、というところ。

僕は変なところで捻くれ者なんだろう、いくつか使えそうなディスクイメージがアップされているにも関らず、手持ちのものから弄っている。慣れないディストリの設定とか頭使ってやる余裕ないなあっていう感じ。老化現象だ。細かい設定とか神経配る気分がさらさら無くなっているのを感じるこの頃で、かなりマイペースだ。

まず、フロント。
試しに普段使いのCompaq 6730b Fedora 26を用意。既にmpdがインストール済み。
これにnmapをインストール。nmapに転送ソフトncatが含まれている。
dnf install nmap
さくっと終わる。
続いてmpd.confに、前述記述を参考にpipeの出力設定を書き込み

audio_output {
        type            "pipe"
        name            "my pipe"
        always_on "yes"
command "ncat 192.168.1.xxx 4444"
}

次にバックエンド。
Ras Pi B+にpiCore7を焼いてi2sDACの設定を書き込み刺して起動。
ip固定など初期設定して、alsaとnmap関連のtczをインストール。
上記のサイトやncat、aplayのネット上のマニュアルを参考に、下記コマンド（いきなりだけどbuffer-sizeは減らしてみた）を打ったらバックエンドは待機状態となる。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -M --period-size=64 --buffer-size=512 -t raw -f cd

フロントに戻って、mpdを再起動。
これでpipeからncatを使って音楽データを出力できるようになる。
ncmpcppでコントロール。

若干の試行錯誤はしたけど、比較的すんなり音が出た。
このとき、試しで継いでいたのは小さなパワードスピーカー。
その音を聴くと、なんだか凄そうと感じられるものがある。いつもと違う感というか。
図にしたら、こんな感じ。
minimserverを使ったupnpより、かなりすっきりしている。特にDACの直前が。

さて、sshからバックエンドに打った前記コマンドを、直接そのままバックエンドのbootlocal.shファイルに記載し、リブートしてみる。
バックエンドの起動を確認し、手元の6730bでncmpcppを操作したら、音が出た。
これで、起動後にsshでログインしてコマンドを打ったりしなくても、起動させたらそのままバックエンドとして機能するのを確認した。

次にメインシステムのnano iDSD LEに継いでいるRas Pi 2、piCore7にnmapをインストールして、バックエンドにして同様に音を出してみた。
なかなかいいかもしれない。鮮度が違う気がする（所謂プラセボ効果という奴）。

試験運用は上々。
フロントをRas Pi 2にして運用したい。
ウェブとか見てる普段使いの6730bをオーディオメインシステムのmpdサーバーにするのはどうかと思うので。
下図のような感じに出来れば。

先ほど使ったRas Pi 2、piCore7のmpd.conf設定を書き変える。
これで簡単に出力できるかな、と思ったら、pipeなんて出力は対応してないよ、とアラートが出てmpdが起動しない。
えぇー、、何それ。

fatal_error: line 109: No such audio output plugin: pipe

さて、弱った。
pipeが使えないって意味がわからない。pipeって「|」でしょ？使えないってありなの？linux的に。
本家サイトではvolumio2でもフロントに使えるという話もあり、いっそ使ってみようかとも思ったけど、、、なんか気が進まない。
つうか、volumio1.55もraspbianも、気付いたら１年もまともに触ってないのだ。
volumio2って、どうなってるのって感じ。
pipeについてあれこれと調べる。pipeというのは「pipeline」とも言われ、shellの機能として組み込まれているらしい？ということは分かった。
でも、結局、よくわからないのだった。

mpdをソースからコンパイルする際に指定したら、pipelineを使えるようにできるらしいということは分かった。
いっそ、こんな感じ。
./configure --enable-pipe-output
一見、きれいにconfigureは通るが、makeでエラーになる、、、
config.logを読むも、、、何が何だか分からない。

しかたない、raspbian stretchでやってみるか、、、
結果だけ言うと、pipeを使えるようにインストールはできたけど、いざ音を出そうとしたら「paused」で音が出ない。
/var/log/mpd/mpd.logを確認。

sh: 1: cannot create ncat: Permission denied
Jan 28 04:05 : errno: "my pipe" [pipe] failed to play: Write error on pipe: Broken pipe
Jan 28 04:05 : output: Failed to open audio output

Permission deniedって、どうしたらいいのか。mpdにroot権限あげたらいいのか？
いろいろやってみたけど、サジを投げた。

いっそ駄目元でpiCore6でやってみっか、、、
おお、、、いつの間にか、tczにmpdもdoxygenもboostもあるじゃん、、、
しかし結果はpiCore7と同様。pipe2がない？ということで、ソースからのコンパイルも失敗。

半月が過ぎて、結局、フロントは6730bのFedoraでしかうまくいってない、、、
これで本家もpipe使うのをやめたのかな、、、
、、、Fedoraって、ラズパイで動くかな、、、
Fedora27で用意されてるじゃないですか！Raspberry Pi 2/3で動くディストリが！

まあ、そんなこんなでFedora27をラズパイ2で動かそうとして、なにをどうミスったか、母艦6730bのFedora26をクラッシュさせてしまった。
OS再インストール環境の再構築をして、このエントリーを書いている。
まあ、なんだな、ちょっと休む。
ひどい風邪も引き込んだし、幸田浩子のアベマリアでもBGMにしながら養生しよう、、、

昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが２つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。

https://github.com/papalius/symphonic-mpd/wiki/%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%81%A8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E3%82%92%E7%B9%8B%E3%81%90%E6%8A%80%E8%A1%93(piped-pcm-audio-play)

バックエンドは、ncat を使ってTCP4444ポートで待ち受け、流れてきたraw PCMデータをaplayに横流しします。
ncat・aplay部分のsystemdサービス定義は以下のような感じです。

ExecStart=/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay-1.1.5 -M --period-size=64 --buffer-size=136710 -t raw -f cd"

フロントのmpdは、デコード済みのraw PCMをpipe outputで取り出し、ncatでバックエンドのTCP4444ポートに流し込みます。
mpd.confのaudio_outputはこんな感じです。

audio_output {
  type "pipe"
  name "PIPE"
  always_on "yes"
  command "ncat 192.168.x.x 4444"
}

肝は、DACへの出力にalsaしか使わないということだと思う。

Linux系PCからのデジタルオーディオ出力に一般的に使われてきたmpdが外されている。
データ仲介ソフトとしてncatを使うことで「mpd + alsa」だったものが「alsaだけ」になっているということ。
mpdは「フロント」で音楽データを処理し「バックエンド」のalsaに送る役割、つまり一般的なupnpシステムであれば、dlnaサーバーソフト（例えばminimserverなど）が担ってきた役割を受け持っている、と言っていいのかな。

デジタルトランスポートとしての機能を複数のPCで役割分担させることによって、高音質化を目指す前例はたくさんある。しかしそれはJPLAYだったりupnp/dlnaシステムを使用したものだったりして、僕のニーズには合わないものだった。うちではlinuxでflac + cue sheetが使えないといけないのだ。
他にいくつか、僕なりに試みた方法もあったけど力及ばず満足できる物にならなかった。

当時、いろいろと試みる中で、minimserverを動かしてみたときは下図のような構成。
エントリーにしてアップしている。MinimServerをRaspberry Pi B+で動かしてみた

今回、ppapを知ったとき、過去に求めながら発見できなかったものが提示されていると思った。
これはやってみないといけないと思ったんだけど、あれこれあって、年を越し、月日が過ぎるうちに、なんだか雲行きが怪しくなってきた。本家サイトで公開中断が続いている。気にならないわけじゃないけど、だからといって僕のほうで余裕が出来たにも関わらず自粛？して手を付けないというのもおかしな話なので、手元の機材を弄り始めた、というところ。

僕は変なところで捻くれ者なんだろう、いくつか使えそうなディスクイメージがアップされているにも関らず、手持ちのものから弄っている。慣れないディストリの設定とか頭使ってやる余裕ないなあっていう感じ。老化現象だ。細かい設定とか神経配る気分がさらさら無くなっているのを感じるこの頃で、かなりマイペースだ。

まず、フロント。
試しに普段使いのCompaq 6730b Fedora 26を用意。既にmpdがインストール済み。
これにnmapをインストール。nmapに転送ソフトncatが含まれている。
dnf install nmap
さくっと終わる。
続いてmpd.confに、前述記述を参考にpipeの出力設定を書き込み

audio_output {
        type            "pipe"
        name            "my pipe"
        always_on "yes"
command "ncat 192.168.1.xxx 4444"
}

次にバックエンド。
Ras Pi B+にpiCore7を焼いてi2sDACの設定を書き込み刺して起動。
ip固定など初期設定して、alsaとnmap関連のtczをインストール。
上記のサイトやncat、aplayのネット上のマニュアルを参考に、下記コマンド（いきなりだけどbuffer-sizeは減らしてみた）を打ったらバックエンドは待機状態となる。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -M --period-size=64 --buffer-size=512 -t raw -f cd

フロントに戻って、mpdを再起動。
これでpipeからncatを使って音楽データを出力できるようになる。
ncmpcppでコントロール。

若干の試行錯誤はしたけど、比較的すんなり音が出た。
このとき、試しで継いでいたのは小さなパワードスピーカー。
その音を聴くと、なんだか凄そうと感じられるものがある。いつもと違う感というか。
図にしたら、こんな感じ。
minimserverを使ったupnpより、かなりすっきりしている。特にDACの直前が。

さて、sshからバックエンドに打った前記コマンドを、直接そのままバックエンドのbootlocal.shファイルに記載し、リブートしてみる。
バックエンドの起動を確認し、手元の6730bでncmpcppを操作したら、音が出た。
これで、起動後にsshでログインしてコマンドを打ったりしなくても、起動させたらそのままバックエンドとして機能するのを確認した。

次にメインシステムのnano iDSD LEに継いでいるRas Pi 2、piCore7にnmapをインストールして、バックエンドにして同様に音を出してみた。
なかなかいいかもしれない。鮮度が違う気がする（所謂プラセボ効果という奴）。

試験運用は上々。
フロントをRas Pi 2にして運用したい。
ウェブとか見てる普段使いの6730bをオーディオメインシステムのmpdサーバーにするのはどうかと思うので。
下図のような感じに出来れば。

先ほど使ったRas Pi 2、piCore7のmpd.conf設定を書き変える。
これで簡単に出力できるかな、と思ったら、pipeなんて出力は対応してないよ、とアラートが出てmpdが起動しない。
えぇー、、何それ。

fatal_error: line 109: No such audio output plugin: pipe

さて、弱った。
pipeが使えないって意味がわからない。pipeって「|」でしょ？使えないってありなの？linux的に。
本家サイトではvolumio2でもフロントに使えるという話もあり、いっそ使ってみようかとも思ったけど、、、なんか気が進まない。
つうか、volumio1.55もraspbianも、気付いたら１年もまともに触ってないのだ。
volumio2って、どうなってるのって感じ。
pipeについてあれこれと調べる。pipeというのは「pipeline」とも言われ、shellの機能として組み込まれているらしい？ということは分かった。
でも、結局、よくわからないのだった。

mpdをソースからコンパイルする際に指定したら、pipelineを使えるようにできるらしいということは分かった。
いっそ、こんな感じ。
./configure --enable-pipe-output
一見、きれいにconfigureは通るが、makeでエラーになる、、、
config.logを読むも、、、何が何だか分からない。

しかたない、raspbian stretchでやってみるか、、、
結果だけ言うと、pipeを使えるようにインストールはできたけど、いざ音を出そうとしたら「paused」で音が出ない。
/var/log/mpd/mpd.logを確認。

sh: 1: cannot create ncat: Permission denied
Jan 28 04:05 : errno: "my pipe" [pipe] failed to play: Write error on pipe: Broken pipe
Jan 28 04:05 : output: Failed to open audio output

Permission deniedって、どうしたらいいのか。mpdにroot権限あげたらいいのか？
いろいろやってみたけど、サジを投げた。

いっそ駄目元でpiCore6でやってみっか、、、
おお、、、いつの間にか、tczにmpdもdoxygenもboostもあるじゃん、、、
しかし結果はpiCore7と同様。pipe2がない？ということで、ソースからのコンパイルも失敗。

半月が過ぎて、結局、フロントは6730bのFedoraでしかうまくいってない、、、
これで本家もpipe使うのをやめたのかな、、、
、、、Fedoraって、ラズパイで動くかな、、、
Fedora27で用意されてるじゃないですか！Raspberry Pi 2/3で動くディストリが！

まあ、そんなこんなでFedora27をラズパイ2で動かそうとして、なにをどうミスったか、母艦6730bのFedora26をクラッシュさせてしまった。
OS再インストール環境の再構築をして、このエントリーを書いている。
まあ、なんだな、ちょっと休む。
ひどい風邪も引き込んだし、幸田浩子のアベマリアでもBGMにしながら養生しよう、、、

昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが２つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。

https://github.com/papalius/symphonic-mpd/wiki/%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%81%A8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E3%82%92%E7%B9%8B%E3%81%90%E6%8A%80%E8%A1%93(piped-pcm-audio-play)

バックエンドは、ncat を使ってTCP4444ポートで待ち受け、流れてきたraw PCMデータをaplayに横流しします。
ncat・aplay部分のsystemdサービス定義は以下のような感じです。

ExecStart=/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay-1.1.5 -M --period-size=64 --buffer-size=136710 -t raw -f cd"

フロントのmpdは、デコード済みのraw PCMをpipe outputで取り出し、ncatでバックエンドのTCP4444ポートに流し込みます。
mpd.confのaudio_outputはこんな感じです。

audio_output {
  type "pipe"
  name "PIPE"
  always_on "yes"
  command "ncat 192.168.x.x 4444"
}

肝は、DACへの出力にalsaしか使わないということだと思う。

Linux系PCからのデジタルオーディオ出力に一般的に使われてきたmpdが外されている。
データ仲介ソフトとしてncatを使うことで「mpd + alsa」だったものが「alsaだけ」になっているということ。
mpdは「フロント」で音楽データを処理し「バックエンド」のalsaに送る役割、つまり一般的なupnpシステムであれば、dlnaサーバーソフト（例えばminimserverなど）が担ってきた役割を受け持っている、と言っていいのかな。

デジタルトランスポートとしての機能を複数のPCで役割分担させることによって、高音質化を目指す前例はたくさんある。しかしそれはJPLAYだったりupnp/dlnaシステムを使用したものだったりして、僕のニーズには合わないものだった。うちではlinuxでflac + cue sheetが使えないといけないのだ。
他にいくつか、僕なりに試みた方法もあったけど力及ばず満足できる物にならなかった。

当時、いろいろと試みる中で、minimserverを動かしてみたときは下図のような構成。
エントリーにしてアップしている。MinimServerをRaspberry Pi B+で動かしてみた

今回、ppapを知ったとき、過去に求めながら発見できなかったものが提示されていると思った。
これはやってみないといけないと思ったんだけど、あれこれあって、年を越し、月日が過ぎるうちに、なんだか雲行きが怪しくなってきた。本家サイトで公開中断が続いている。気にならないわけじゃないけど、だからといって僕のほうで余裕が出来たにも関わらず自粛？して手を付けないというのもおかしな話なので、手元の機材を弄り始めた、というところ。

僕は変なところで捻くれ者なんだろう、いくつか使えそうなディスクイメージがアップされているにも関らず、手持ちのものから弄っている。慣れないディストリの設定とか頭使ってやる余裕ないなあっていう感じ。老化現象だ。細かい設定とか神経配る気分がさらさら無くなっているのを感じるこの頃で、かなりマイペースだ。

まず、フロント。
試しに普段使いのCompaq 6730b Fedora 26を用意。既にmpdがインストール済み。
これにnmapをインストール。nmapに転送ソフトncatが含まれている。
dnf install nmap
さくっと終わる。
続いてmpd.confに、前述記述を参考にpipeの出力設定を書き込み

audio_output {
        type            "pipe"
        name            "my pipe"
        always_on "yes"
command "ncat 192.168.1.xxx 4444"
}

次にバックエンド。
Ras Pi B+にpiCore7を焼いてi2sDACの設定を書き込み刺して起動。
ip固定など初期設定して、alsaとnmap関連のtczをインストール。
上記のサイトやncat、aplayのネット上のマニュアルを参考に、下記コマンド（いきなりだけどbuffer-sizeは減らしてみた）を打ったらバックエンドは待機状態となる。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -M --period-size=64 --buffer-size=512 -t raw -f cd

フロントに戻って、mpdを再起動。
これでpipeからncatを使って音楽データを出力できるようになる。
ncmpcppでコントロール。

若干の試行錯誤はしたけど、比較的すんなり音が出た。
このとき、試しで継いでいたのは小さなパワードスピーカー。
その音を聴くと、なんだか凄そうと感じられるものがある。いつもと違う感というか。
図にしたら、こんな感じ。
minimserverを使ったupnpより、かなりすっきりしている。特にDACの直前が。

さて、sshからバックエンドに打った前記コマンドを、直接そのままバックエンドのbootlocal.shファイルに記載し、リブートしてみる。
バックエンドの起動を確認し、手元の6730bでncmpcppを操作したら、音が出た。
これで、起動後にsshでログインしてコマンドを打ったりしなくても、起動させたらそのままバックエンドとして機能するのを確認した。

次にメインシステムのnano iDSD LEに継いでいるRas Pi 2、piCore7にnmapをインストールして、バックエンドにして同様に音を出してみた。
なかなかいいかもしれない。鮮度が違う気がする（所謂プラセボ効果という奴）。

試験運用は上々。
フロントをRas Pi 2にして運用したい。
ウェブとか見てる普段使いの6730bをオーディオメインシステムのmpdサーバーにするのはどうかと思うので。
下図のような感じに出来れば。

先ほど使ったRas Pi 2、piCore7のmpd.conf設定を書き変える。
これで簡単に出力できるかな、と思ったら、pipeなんて出力は対応してないよ、とアラートが出てmpdが起動しない。
えぇー、、何それ。

fatal_error: line 109: No such audio output plugin: pipe

さて、弱った。
pipeが使えないって意味がわからない。pipeって「|」でしょ？使えないってありなの？linux的に。
本家サイトではvolumio2でもフロントに使えるという話もあり、いっそ使ってみようかとも思ったけど、、、なんか気が進まない。
つうか、volumio1.55もraspbianも、気付いたら１年もまともに触ってないのだ。
volumio2って、どうなってるのって感じ。
pipeについてあれこれと調べる。pipeというのは「pipeline」とも言われ、shellの機能として組み込まれているらしい？ということは分かった。
でも、結局、よくわからないのだった。

mpdをソースからコンパイルする際に指定したら、pipelineを使えるようにできるらしいということは分かった。
いっそ、こんな感じ。
./configure --enable-pipe-output
一見、きれいにconfigureは通るが、makeでエラーになる、、、
config.logを読むも、、、何が何だか分からない。

しかたない、raspbian stretchでやってみるか、、、
結果だけ言うと、pipeを使えるようにインストールはできたけど、いざ音を出そうとしたら「paused」で音が出ない。
/var/log/mpd/mpd.logを確認。

sh: 1: cannot create ncat: Permission denied
Jan 28 04:05 : errno: "my pipe" [pipe] failed to play: Write error on pipe: Broken pipe
Jan 28 04:05 : output: Failed to open audio output

Permission deniedって、どうしたらいいのか。mpdにroot権限あげたらいいのか？
いろいろやってみたけど、サジを投げた。

いっそ駄目元でpiCore6でやってみっか、、、
おお、、、いつの間にか、tczにmpdもdoxygenもboostもあるじゃん、、、
しかし結果はpiCore7と同様。pipe2がない？ということで、ソースからのコンパイルも失敗。

半月が過ぎて、結局、フロントは6730bのFedoraでしかうまくいってない、、、
これで本家もpipe使うのをやめたのかな、、、
、、、Fedoraって、ラズパイで動くかな、、、
Fedora27で用意されてるじゃないですか！Raspberry Pi 2/3で動くディストリが！

まあ、そんなこんなでFedora27をラズパイ2で動かそうとして、なにをどうミスったか、母艦6730bのFedora26をクラッシュさせてしまった。
OS再インストール環境の再構築をして、このエントリーを書いている。
まあ、なんだな、ちょっと休む。
ひどい風邪も引き込んだし、幸田浩子のアベマリアでもBGMにしながら養生しよう、、、

昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが２つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。

https://github.com/papalius/symphonic-mpd/wiki/%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%81%A8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E3%82%92%E7%B9%8B%E3%81%90%E6%8A%80%E8%A1%93(piped-pcm-audio-play)

バックエンドは、ncat を使ってTCP4444ポートで待ち受け、流れてきたraw PCMデータをaplayに横流しします。
ncat・aplay部分のsystemdサービス定義は以下のような感じです。

ExecStart=/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay-1.1.5 -M --period-size=64 --buffer-size=136710 -t raw -f cd"

フロントのmpdは、デコード済みのraw PCMをpipe outputで取り出し、ncatでバックエンドのTCP4444ポートに流し込みます。
mpd.confのaudio_outputはこんな感じです。

audio_output {
  type "pipe"
  name "PIPE"
  always_on "yes"
  command "ncat 192.168.x.x 4444"
}

肝は、DACへの出力にalsaしか使わないということだと思う。

Linux系PCからのデジタルオーディオ出力に一般的に使われてきたmpdが外されている。
データ仲介ソフトとしてncatを使うことで「mpd + alsa」だったものが「alsaだけ」になっているということ。
mpdは「フロント」で音楽データを処理し「バックエンド」のalsaに送る役割、つまり一般的なupnpシステムであれば、dlnaサーバーソフト（例えばminimserverなど）が担ってきた役割を受け持っている、と言っていいのかな。

デジタルトランスポートとしての機能を複数のPCで役割分担させることによって、高音質化を目指す前例はたくさんある。しかしそれはJPLAYだったりupnp/dlnaシステムを使用したものだったりして、僕のニーズには合わないものだった。うちではlinuxでflac + cue sheetが使えないといけないのだ。
他にいくつか、僕なりに試みた方法もあったけど力及ばず満足できる物にならなかった。

当時、いろいろと試みる中で、minimserverを動かしてみたときは下図のような構成。
エントリーにしてアップしている。MinimServerをRaspberry Pi B+で動かしてみた

今回、ppapを知ったとき、過去に求めながら発見できなかったものが提示されていると思った。
これはやってみないといけないと思ったんだけど、あれこれあって、年を越し、月日が過ぎるうちに、なんだか雲行きが怪しくなってきた。本家サイトで公開中断が続いている。気にならないわけじゃないけど、だからといって僕のほうで余裕が出来たにも関わらず自粛？して手を付けないというのもおかしな話なので、手元の機材を弄り始めた、というところ。

僕は変なところで捻くれ者なんだろう、いくつか使えそうなディスクイメージがアップされているにも関らず、手持ちのものから弄っている。慣れないディストリの設定とか頭使ってやる余裕ないなあっていう感じ。老化現象だ。細かい設定とか神経配る気分がさらさら無くなっているのを感じるこの頃で、かなりマイペースだ。

まず、フロント。
試しに普段使いのCompaq 6730b Fedora 26を用意。既にmpdがインストール済み。
これにnmapをインストール。nmapに転送ソフトncatが含まれている。
dnf install nmap
さくっと終わる。
続いてmpd.confに、前述記述を参考にpipeの出力設定を書き込み

audio_output {
        type            "pipe"
        name            "my pipe"
        always_on "yes"
command "ncat 192.168.1.xxx 4444"
}

次にバックエンド。
Ras Pi B+にpiCore7を焼いてi2sDACの設定を書き込み刺して起動。
ip固定など初期設定して、alsaとnmap関連のtczをインストール。
上記のサイトやncat、aplayのネット上のマニュアルを参考に、下記コマンド（いきなりだけどbuffer-sizeは減らしてみた）を打ったらバックエンドは待機状態となる。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -M --period-size=64 --buffer-size=512 -t raw -f cd

フロントに戻って、mpdを再起動。
これでpipeからncatを使って音楽データを出力できるようになる。
ncmpcppでコントロール。

若干の試行錯誤はしたけど、比較的すんなり音が出た。
このとき、試しで継いでいたのは小さなパワードスピーカー。
その音を聴くと、なんだか凄そうと感じられるものがある。いつもと違う感というか。
図にしたら、こんな感じ。
minimserverを使ったupnpより、かなりすっきりしている。特にDACの直前が。

さて、sshからバックエンドに打った前記コマンドを、直接そのままバックエンドのbootlocal.shファイルに記載し、リブートしてみる。
バックエンドの起動を確認し、手元の6730bでncmpcppを操作したら、音が出た。
これで、起動後にsshでログインしてコマンドを打ったりしなくても、起動させたらそのままバックエンドとして機能するのを確認した。

次にメインシステムのnano iDSD LEに継いでいるRas Pi 2、piCore7にnmapをインストールして、バックエンドにして同様に音を出してみた。
なかなかいいかもしれない。鮮度が違う気がする（所謂プラセボ効果という奴）。

試験運用は上々。
フロントをRas Pi 2にして運用したい。
ウェブとか見てる普段使いの6730bをオーディオメインシステムのmpdサーバーにするのはどうかと思うので。
下図のような感じに出来れば。

先ほど使ったRas Pi 2、piCore7のmpd.conf設定を書き変える。
これで簡単に出力できるかな、と思ったら、pipeなんて出力は対応してないよ、とアラートが出てmpdが起動しない。
えぇー、、何それ。

fatal_error: line 109: No such audio output plugin: pipe

さて、弱った。
pipeが使えないって意味がわからない。pipeって「|」でしょ？使えないってありなの？linux的に。
本家サイトではvolumio2でもフロントに使えるという話もあり、いっそ使ってみようかとも思ったけど、、、なんか気が進まない。
つうか、volumio1.55もraspbianも、気付いたら１年もまともに触ってないのだ。
volumio2って、どうなってるのって感じ。
pipeについてあれこれと調べる。pipeというのは「pipeline」とも言われ、shellの機能として組み込まれているらしい？ということは分かった。
でも、結局、よくわからないのだった。

mpdをソースからコンパイルする際に指定したら、pipelineを使えるようにできるらしいということは分かった。
いっそ、こんな感じ。
./configure --enable-pipe-output
一見、きれいにconfigureは通るが、makeでエラーになる、、、
config.logを読むも、、、何が何だか分からない。

しかたない、raspbian stretchでやってみるか、、、
結果だけ言うと、pipeを使えるようにインストールはできたけど、いざ音を出そうとしたら「paused」で音が出ない。
/var/log/mpd/mpd.logを確認。

sh: 1: cannot create ncat: Permission denied
Jan 28 04:05 : errno: "my pipe" [pipe] failed to play: Write error on pipe: Broken pipe
Jan 28 04:05 : output: Failed to open audio output

Permission deniedって、どうしたらいいのか。mpdにroot権限あげたらいいのか？
いろいろやってみたけど、サジを投げた。

いっそ駄目元でpiCore6でやってみっか、、、
おお、、、いつの間にか、tczにmpdもdoxygenもboostもあるじゃん、、、
しかし結果はpiCore7と同様。pipe2がない？ということで、ソースからのコンパイルも失敗。

半月が過ぎて、結局、フロントは6730bのFedoraでしかうまくいってない、、、
これで本家もpipe使うのをやめたのかな、、、
、、、Fedoraって、ラズパイで動くかな、、、
Fedora27で用意されてるじゃないですか！Raspberry Pi 2/3で動くディストリが！

まあ、そんなこんなでFedora27をラズパイ2で動かそうとして、なにをどうミスったか、母艦6730bのFedora26をクラッシュさせてしまった。
OS再インストール環境の再構築をして、このエントリーを書いている。
まあ、なんだな、ちょっと休む。
ひどい風邪も引き込んだし、幸田浩子のアベマリアでもBGMにしながら養生しよう、、、

昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが２つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。

https://github.com/papalius/symphonic-mpd/wiki/%E3%83%95%E3%83%AD%E3%83%B3%E3%83%88%E3%81%A8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E3%82%92%E7%B9%8B%E3%81%90%E6%8A%80%E8%A1%93(piped-pcm-audio-play)

バックエンドは、ncat を使ってTCP4444ポートで待ち受け、流れてきたraw PCMデータをaplayに横流しします。
ncat・aplay部分のsystemdサービス定義は以下のような感じです。

ExecStart=/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay-1.1.5 -M --period-size=64 --buffer-size=136710 -t raw -f cd"

フロントのmpdは、デコード済みのraw PCMをpipe outputで取り出し、ncatでバックエンドのTCP4444ポートに流し込みます。
mpd.confのaudio_outputはこんな感じです。

audio_output {
  type "pipe"
  name "PIPE"
  always_on "yes"
  command "ncat 192.168.x.x 4444"
}

肝は、DACへの出力にalsaしか使わないということだと思う。

Linux系PCからのデジタルオーディオ出力に一般的に使われてきたmpdが外されている。
データ仲介ソフトとしてncatを使うことで「mpd + alsa」だったものが「alsaだけ」になっているということ。
mpdは「フロント」で音楽データを処理し「バックエンド」のalsaに送る役割、つまり一般的なupnpシステムであれば、dlnaサーバーソフト（例えばminimserverなど）が担ってきた役割を受け持っている、と言っていいのかな。

デジタルトランスポートとしての機能を複数のPCで役割分担させることによって、高音質化を目指す前例はたくさんある。しかしそれはJPLAYだったりupnp/dlnaシステムを使用したものだったりして、僕のニーズには合わないものだった。うちではlinuxでflac + cue sheetが使えないといけないのだ。
他にいくつか、僕なりに試みた方法もあったけど力及ばず満足できる物にならなかった。

当時、いろいろと試みる中で、minimserverを動かしてみたときは下図のような構成。
エントリーにしてアップしている。MinimServerをRaspberry Pi B+で動かしてみた

今回、ppapを知ったとき、過去に求めながら発見できなかったものが提示されていると思った。
これはやってみないといけないと思ったんだけど、あれこれあって、年を越し、月日が過ぎるうちに、なんだか雲行きが怪しくなってきた。本家サイトで公開中断が続いている。気にならないわけじゃないけど、だからといって僕のほうで余裕が出来たにも関わらず自粛？して手を付けないというのもおかしな話なので、手元の機材を弄り始めた、というところ。

僕は変なところで捻くれ者なんだろう、いくつか使えそうなディスクイメージがアップされているにも関らず、手持ちのものから弄っている。慣れないディストリの設定とか頭使ってやる余裕ないなあっていう感じ。老化現象だ。細かい設定とか神経配る気分がさらさら無くなっているのを感じるこの頃で、かなりマイペースだ。

まず、フロント。
試しに普段使いのCompaq 6730b Fedora 26を用意。既にmpdがインストール済み。
これにnmapをインストール。nmapに転送ソフトncatが含まれている。
dnf install nmap
さくっと終わる。
続いてmpd.confに、前述記述を参考にpipeの出力設定を書き込み

audio_output {
        type            "pipe"
        name            "my pipe"
        always_on "yes"
command "ncat 192.168.1.xxx 4444"
}

次にバックエンド。
Ras Pi B+にpiCore7を焼いてi2sDACの設定を書き込み刺して起動。
ip固定など初期設定して、alsaとnmap関連のtczをインストール。
上記のサイトやncat、aplayのネット上のマニュアルを参考に、下記コマンド（いきなりだけどbuffer-sizeは減らしてみた）を打ったらバックエンドは待機状態となる。

/usr/local/bin/ncat -kl 4444 -e "/usr/local/bin/aplay -M --period-size=64 --buffer-size=512 -t raw -f cd

フロントに戻って、mpdを再起動。
これでpipeからncatを使って音楽データを出力できるようになる。
ncmpcppでコントロール。

若干の試行錯誤はしたけど、比較的すんなり音が出た。
このとき、試しで継いでいたのは小さなパワードスピーカー。
その音を聴くと、なんだか凄そうと感じられるものがある。いつもと違う感というか。
図にしたら、こんな感じ。
minimserverを使ったupnpより、かなりすっきりしている。特にDACの直前が。

さて、sshからバックエンドに打った前記コマンドを、直接そのままバックエンドのbootlocal.shファイルに記載し、リブートしてみる。
バックエンドの起動を確認し、手元の6730bでncmpcppを操作したら、音が出た。
これで、起動後にsshでログインしてコマンドを打ったりしなくても、起動させたらそのままバックエンドとして機能するのを確認した。

次にメインシステムのnano iDSD LEに継いでいるRas Pi 2、piCore7にnmapをインストールして、バックエンドにして同様に音を出してみた。
なかなかいいかもしれない。鮮度が違う気がする（所謂プラセボ効果という奴）。

試験運用は上々。
フロントをRas Pi 2にして運用したい。
ウェブとか見てる普段使いの6730bをオーディオメインシステムのmpdサーバーにするのはどうかと思うので。
下図のような感じに出来れば。

先ほど使ったRas Pi 2、piCore7のmpd.conf設定を書き変える。
これで簡単に出力できるかな、と思ったら、pipeなんて出力は対応してないよ、とアラートが出てmpdが起動しない。
えぇー、、何それ。

fatal_error: line 109: No such audio output plugin: pipe

さて、弱った。
pipeが使えないって意味がわからない。pipeって「|」でしょ？使えないってありなの？linux的に。
本家サイトではvolumio2でもフロントに使えるという話もあり、いっそ使ってみようかとも思ったけど、、、なんか気が進まない。
つうか、volumio1.55もraspbianも、気付いたら１年もまともに触ってないのだ。
volumio2って、どうなってるのって感じ。
pipeについてあれこれと調べる。pipeというのは「pipeline」とも言われ、shellの機能として組み込まれているらしい？ということは分かった。
でも、結局、よくわからないのだった。

mpdをソースからコンパイルする際に指定したら、pipelineを使えるようにできるらしいということは分かった。
いっそ、こんな感じ。
./configure --enable-pipe-output
一見、きれいにconfigureは通るが、makeでエラーになる、、、
config.logを読むも、、、何が何だか分からない。

しかたない、raspbian stretchでやってみるか、、、
結果だけ言うと、pipeを使えるようにインストールはできたけど、いざ音を出そうとしたら「paused」で音が出ない。
/var/log/mpd/mpd.logを確認。

sh: 1: cannot create ncat: Permission denied
Jan 28 04:05 : errno: "my pipe" [pipe] failed to play: Write error on pipe: Broken pipe
Jan 28 04:05 : output: Failed to open audio output

Permission deniedって、どうしたらいいのか。mpdにroot権限あげたらいいのか？
いろいろやってみたけど、サジを投げた。

いっそ駄目元でpiCore6でやってみっか、、、
おお、、、いつの間にか、tczにmpdもdoxygenもboostもあるじゃん、、、
しかし結果はpiCore7と同様。pipe2がない？ということで、ソースからのコンパイルも失敗。

半月が過ぎて、結局、フロントは6730bのFedoraでしかうまくいってない、、、
これで本家もpipe使うのをやめたのかな、、、
、、、Fedoraって、ラズパイで動くかな、、、
Fedora27で用意されてるじゃないですか！Raspberry Pi 2/3で動くディストリが！

まあ、そんなこんなでFedora27をラズパイ2で動かそうとして、なにをどうミスったか、母艦6730bのFedora26をクラッシュさせてしまった。
OS再インストール環境の再構築をして、このエントリーを書いている。
まあ、なんだな、ちょっと休む。
ひどい風邪も引き込んだし、幸田浩子のアベマリアでもBGMにしながら養生しよう、、、