Current filter: »ppap« (Click tag to exclude it or click a conjunction to switch them.)
Jun 08, 2018
piCoreのonboot.lstを編集してタスク軽減を目指す
先日、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.lstmc.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/nas55個になった、、、
じゃあ音はどうなのかというと、例によって比較はできてないんだな、、、
これ以上は削るわけにはいかないような気がするし、この手法で出来るのはここらあたりまでかと思う。
今回は音の比較をしたという話だ。
結論から書くけど、音は良くなる。前の状態には戻したくないな、と思う程度の変化はある。
うちにはメインシステムで運用している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を編集しタスクを減らしたほうが良さそうだ。
そんなことを考えながら続けてあれこれ聴いてみるうちに、なるほど、これは戻れないかもと思うようになった。
音のリアリティ、SN感が高く細やかで雑味が少なくなる感じ。音場表現もより安定し深みが出て、前後も見易くなるようだ。
今回はPPAP運用の流れでonboot.lstを編集したけど、PPAPで使うかどうかに関係なくpiCoreでmpdの音を改善しようと思ったら試みていい方法だと思う。Ras pi1台でのmpd運用の時でも音質改善する可能性がある。
Jun 05, 2018
PPAP (piped pcm audio play) 関連サイトアドレス集
前回、前々回と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/
PCオーディオに見て、触って、聴いてみる-Ⅴ その4
http://kotonohanoana.com/archives/20430
【ネットワークオーディオTips】DLNAの「プッシュ再生」について
プッシュ再生方式は、すごくPPAP方式と似ている。
DMRとDMS+DMCの役割は、そのままPPAPのバックエンドとフロントの役割と同じに見える。同時期に同じような構成、考え方がウェブ上で話題になっているというのも不思議な感じだ。将来、こういうコンセプトに影響を受けた製品が商品化されることがあるかもしれないとか、考えたりする。
そもそも、symphonic-mpdはストイックなディストリで、今もサイトに「アプローチに逆行すると判断したものはバッサリ断捨離している尖ったディストリビューション」と掲げている。PPAPはもっと間口が広くてゆるいコンセプトだと思う。僕は、ずいぶん方向性を変えるんだな、と驚いたものだった。
v0.5.0では、以前の方向性に戻っているのかな、、、
現時点では、本家のsymphonic-mpdでPPAPを続けるつもりがあるのかどうか分からない。PPAPは間口こそ広いけど、サンプリング周波数を固定しないといけないとか意外と扱いにくい面があるし、もしかしたら突き詰めてコントロールするには不向きと判断されるかもしれない。
せっかくアイデアとして世に出たものなのだし、うちでは成果があるのだからpiCoreでゆるゆる運用していくつもりだ。
間口が広いPPAPだから、そういうのもありだろうと勝手にそんな風に考えている。
May 29, 2018
piCore7で作るPPAP Front
piCore7でppap (piped pcm audio play)を試みる
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180301a.htm
3月に上記のエントリーを上げて、前回はバックエンドのエントリーを上げた。
フロントのエントリーがないのも、ちょっとね、と思って独立したエントリーにまとめることにした。新しいことはあんまりないんだけど。
課題としては、
フロント化に最小限必要な環境を見つけたい
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設定のうちの1つだ。
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個になった、、、
じゃあ音はどうなのかというと、例によって比較はできてないんだな、、、
これ以上は削るわけにはいかないような気がするし、この手法で出来るのはここらあたりまでかと思う。
May 27, 2018
piCore7で作るPPAP Back-End (2020.08.16.追記)
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"
これだったら、こちらの求めるように機能して音が出る。どこかでそうなるように設定されているのかもしれないけど、よく分からない。
現状、変換せずに音が出てくれたらいい、という感じだ。
2020.08.16.追記。
上記の「hw」と「plughw」の件について、解決したと思うので昨日にエントリーを挙げた。
PPAP back-Endの設定を考え直す(hwとplughw)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200815a.htm
要は、コマンドの書き間違いのせいでエラーが起きていたということ。データのフォーマットの記載が不正確だったので、plughwで記載する必要が生じたらしい。具体的には「S24_LE」というのが間違いだったのではないかと。
おそらく正確な記載は「S32_LE」だったのではないかと思うのだけど、今となっては推測だ。
閑話休題。
忘れないように設定を保存しリブートすれば、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上に展開する。で、合ってるのかな?
結果、軽量なシステムのはずだけどプロセスが多くなるみたい。
削れるものはあるかもしれないけど、僕のほうでは無理せずにこのまま使っている。
May 23, 2018
PPAP Back-EndのUSB出力が48kHzになっていたので修正した(2020.08.16.追記)
2020.08.16.追記。
このエントリーで書いた内容については、ずっと疑問に思っていた。
ようやく原因が見つかった。例によって、残念な感じである。。。
伝送データのフォーマット記載のミスがあったせいで、このエントリーに書いたような顛末(-D hw:0,0というオプションが使えない)に至ったようだ。
具体的にはコマンドの「-f S24_LE」という記載が間違いだった可能性がある。それを「-D plughw:0,0」というオプションを使うことでカバーする、という状態になっていたと考えられる。そういった内容を昨日のエントリーで記述したので、追記しておく。
PPAP back-Endの設定を考え直す(hwとplughw)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200815a.htm
どこから書いたものか。
数ヶ月前、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 - AlsaProjectSome 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を送れない原因があるということだ。
この辺は今後の課題だ。
追記。
aplay(1) - Linux man page
https://linux.die.net/man/1/aplay
上記サイトをみたら「Valid values are 2000 through 192000 Hertz.」と書いている。
なるほど、aplayを使うなら上限は192kHzだ。
それにしても、UCXで気付かずに聴いていた48kHzの音はなんだか良かった。
このサイトの5年前のエントリーにも、48kHzのときのほうがゆったりして暖かい音が出ていた印象があるとか書いている。
今回の顛末で感じている印象も5年前と同じなのだ。-D plughw:0,0を書き込んだバックエンドから出る音は以前よりもクールで、それは48kHzにしても同様だ。
これはもしかしたら、dmixの音なのかもしれないと思い至った。
前々回のエントリーで書いた、mpdの設定で「mixer_type "software"」を記述する場所によって音色が違う気がする、というのも、alsaの項目内に書けばdmixが働き、そうでないなら働かないとしたら、なんとなく音色が違うのも辻褄が合う。
どんなものだろうか。
May 06, 2018
RAMメモリ再生とppap(piped PCM audio play)を比較した
今回は、ほんと報告だけ。
宿題として残っていたタイトルの題目なんだけど、結論から言えば、ほぼ一瞬で決着が付いた。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メモリ再生を行なったらどうなのか、というのは突っ込んでいくとあるんだけど、いつかそのうちに気が向けば。
現状で十二分以上に不満がなくて、音楽に浸るほうが先なんだよね。
Mar 01, 2018
piCore7でppap (piped pcm audio play)を試みる(05.22、2020.08.16、追記)
1月半ばからppapに取り組んでいる。
2月上旬での状況を前回のエントリーに書いたんだけど、その後、体調崩して人生初めての入院したりで、まだ本調子じゃない。
それでもようやく進捗があった。
piCore7をフロント化するのに成功した。
5月29日、追記。
ここにいろいろ追記してきたけど、フロントとバックエンドで別エントリーを立てた。
このエントリーよりは分かり易くまとまってると思うんだけど。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180529a.htm
piCore7で作るPPAP Front
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180527a.htm
piCore7で作るPPAP Back-End
追記。せっかく作ってあったので構成図をアップ。

しかし、そもそも何で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の記載例。
4月9日、追記。
下記のmpd.confの記載例で、mixer_typeの設定について書き直した。
というのは、僕はずっとmixer_typeはalsaの設定だと思い込んでいたんだけど、mpdのユーザーマニュアルをよく読んでみたらそうではなかった。alsa以外のaudio_outputにも適用されるということらしい。mpdの更新履歴を読んでみたら、どうもv.0.16でそういう仕様になったようだけど、はっきりしない。
詳細は下記アドレスのUser's Manualを参照のこと。The following table lists the audio_output options valid for all plugins と記載がある。
https://www.musicpd.org/doc/user/config_audio_outputs.html
そのUser's Manualを読んで、replay_gain_handlerも設定しておいたほうがいいんじゃないかなと思われたので書き加えている。
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を起動させる仕様。自動起動にはしていない。
3月13日、追記。
フロントにRas pi2/piCore7を使った場合、アップサンプリングで使えるのは192kHzまでのようだ。300kHz台にすると音が出ない。
普段使いのノートPC、HP 6730b/Fedoraでは98kHzが上限だった。上の数値を設定してもなぜか98kHzで出力された(nano iDSD LEのLEDインジケーターで確認)。
どうなってるのかと調べたけどはっきりしない。
ただ、pipeの容量には上限があるということらしく、OSの実装により上限は異なるということらしい。
Man page of PIPE
https://linuxjm.osdn.jp/html/LDP_man-pages/man7/pipe.7.html
Linux 2.6.35 以降では、パイプの容量のデフォルト値は65536バイトだが、 パイプの容量を参照、設定を fcntl(2) の F_GETPIPE_SZ と F_SETPIPE_SZ 操作を使って行うことができる、とある。これがアップサンプリングに上限がある理由なのかどうか分からないけど、fcntlを使うというのも当方には難しく、これ以上は調べずにいる。
5月28日、解決したので追記。
aplayで扱う事ができるサンプリング周波数の上限が192kHzということだ。
Back-End
5月27日、追記。
ここにいろいろ追記してきたけど、読みにくくなったので別エントリーにした。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180527a.htm
piCore7で作るPPAP Back-End
バックエンドはraspberry pi B+/2、piCore7で組んでいる。
これは初期状態にalsaとnmapしかインストールしていないような状態で、それでもちゃんと動いている。
period-sizeの設定によってCPU使用率がかなり変わるようなので、うちでは256と多めに設定している。そのほうがCPU使用率が下がる。逆にbuffer-sizeは2048と少なめだ。どのくらいがいいのかは確かめていない。
追記。
raspberry pi B+でバックエンドを組んだ場合、USB出力だとプチノイズを生じることに気付いた。
period-sizeやbuffer-sizeの設定を弄る程度では解消しない。
しかし、i2s出力だと問題ないようだ。
USB/LAN周りが脆弱なRas piだと、シングルコアだとデータやタスクの管理に限界があるのかもしれない。piCore以外のディストリでどうかは分からない。
5月26日、追記。
以前にraspberry pi B+でバックエンドを組んだときにUSB出力でプチノイズを生じたのは、dmixで48kHzにリサンプリングする負担が影響していたようだ。これは、alsaのデフォルトで設定されている。
このリサンプリングをしないように設定にしたら、B+でも問題なくUSB出力が出来るようだ。ただし、period-sizeとbuffer-sizeは上げる必要がある。
どうやって設定するかは後述、追記している。
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出力はリサンプリングされずに出力されるようだ。
2020.06.16.追記。
上記の「-D plughw:0,0」は「-D hw:0,0」が使えなかったために採用した手法だった。なぜ使えなかったのか、-D plughw:0,0が何をしてるのかについて、エントリーをあげたので追記しておく。
PPAP back-Endの設定を考え直す(hwとplughw)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20200815a.htm
音質評価は未だしていない。追々、余裕があるときに。
Feb 05, 2018
ppap (piped pcm audio play)を試みるが、一筋縄に行かない、、、
昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが2つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。
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も、気付いたら1年もまともに触ってないのだ。
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にしながら養生しよう、、、
Jan 01, 1970
ppap (piped pcm audio play)を試みるが、一筋縄に行かない、、、
昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが2つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。
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も、気付いたら1年もまともに触ってないのだ。
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にしながら養生しよう、、、
ppap (piped pcm audio play)を試みるが、一筋縄に行かない、、、
昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが2つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。
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も、気付いたら1年もまともに触ってないのだ。
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にしながら養生しよう、、、
ppap (piped pcm audio play)を試みるが、一筋縄に行かない、、、
昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが2つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。
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も、気付いたら1年もまともに触ってないのだ。
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にしながら養生しよう、、、
ppap (piped pcm audio play)を試みるが、一筋縄に行かない、、、
昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが2つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。
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も、気付いたら1年もまともに触ってないのだ。
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にしながら養生しよう、、、
ppap (piped pcm audio play)を試みるが、一筋縄に行かない、、、
昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが2つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。
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も、気付いたら1年もまともに触ってないのだ。
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にしながら養生しよう、、、
ppap (piped pcm audio play)を試みるが、一筋縄に行かない、、、
昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが2つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。
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も、気付いたら1年もまともに触ってないのだ。
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にしながら養生しよう、、、
ppap (piped pcm audio play)を試みるが、一筋縄に行かない、、、
昨年末、Phile Webのコミュニティで「ppap」というデジタルトランスポート方式が提案された。
Ras Piのような小型ボードPCが2つあれば実装できる。
詳しくは下記サイトを参照。以下、引用。
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も、気付いたら1年もまともに触ってないのだ。
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にしながら養生しよう、、、