Current filter: »mpd« (Click tag to exclude it or click a conjunction to switch them.)
May 04, 2020
今更だがpiCore7を復帰させる
いろいろ世の中も生活も面倒な状況が続いている。
仕事柄、休んでばかりもいられない。それでもGWはそこそこ休みがある。休めるだけいい。
前回のエントリーで、PPAP方式で複数のサンプリングパラメータを使い分ける方法を書いた。
だけど、どうもPPAP 192/24、96/24で使っていると、クライアントの操作に音楽再生の追随が5、6秒ほど遅れる。まどろっこしくてストレスになる事がわかった。
最初にncmpcppから再生開始の指示を出すときは直ぐに反応する。しかし音量を調節したら反応するのに5秒ほどかかる。他の曲に変えようとして操作したら、やはりそのぐらい遅延が生じるのだ。
ちなみに、768/32 PPAPでは全くそんなことがない。遅延はあるかないか分からない程度としか感じない。快適そのものだ。
つまり処理能力の問題ではなく、何処かの設定だか何かによるものだと思う。
しかし、どうしたら直せるのかは分からない。
以前に使っていた時はこんなだったっけ?ハードやOSの違いによるのかな?とか思いながら使っていたが、だんだんPPAPではない他の方法を探そうという気持ちになってきた。だって低音質音源への対応に、そんなストレス抱えてちゃいかんでしょ。NASマウントによるmpd再生に回帰することにした。
最初に思いついたのは、raspberry pi2の再利用。
既存の音楽再生用ディストリビューションを利用できる。
lightMPD、Symphonic MPD、、、いや、それはなんというか、大根切るのに日本刀みたいでバランスが悪すぎる。
いっそのこと、VolumioとかMoodeぐらいでいいか、、、
Moodeをダウンロード、、、遅すぎる。昨今の時世のでネットが重いせいか2時間以上かかった上、DL失敗と表示された。
Volumio2は、、、設定がめんどう、、、やっぱりなじめない。
そういえば、以前開発終了していた頃に落としたArchphileがあったな、、NASをマウントしない。sshでログインしていじっても、設定が保存されない。
そんなこんなで、どうしようかと思案するうち、piCore7でいいんじゃないのかと気付く。
うちで使いやすい再生環境を作るとなったとき、簡便で手軽なのはこれが一番だったということを思い出した。
piCore7はmpdがtczファイルで用意されているので、簡単に環境構築ができる。
やり方は過去のエントリーほぼそのままで楽々。備忘録残しておいてよかった。
1時間ほどで完成する。
piCore7にmpdをインストールする方法
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20180103a.htm
以前の行程と違うのは、ip固定にしていないのと(最近は固定せずに使うことが増えた。DHCPサーバーまかせだ)、ディスクイメージ拡張の際にmicroSDカードいっぱいには拡張せずに200MBで納めておいたこと。せっかくなのでmpdをインストールしたmicroSDカードからバックアップのディスクイメージを作ることにしたのだ。
tc@box:~$ sudo fdisk -u /dev/mmcblk0 Command (m for help): p Disk /dev/mmcblk0: 3965 MB, 3965190144 bytes 3 heads, 8 sectors/track, 322688 cylinders, total 7744512 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/mmcblk0p1 8192 69631 30720 c Win95 FAT32 (LBA) /dev/mmcblk0p2 69648 93119 11736 83 Linux Command (m for help): d Partition number (1-4): 2 Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 2 First sector (8-7744511, default 8): 69648 Last sector or +size or +sizeM or +sizeK (69648-7744511, default 7744511): +200M Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy tc@box:~$ sudo reboot tc@192.168.1.77's password: ( '>') /) TC (\ Core is distributed with ABSOLUTELY NO WARRANTY. (/-_--_-\) www.tinycorelinux.net tc@box:~$ sudo resize2fs /dev/mmcblk0p2 resize2fs 1.42.13 (17-May-2015) Filesystem at /dev/mmcblk0p2 is mounted on /mnt/mmcblk0p2; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 The filesystem on /dev/mmcblk0p2 is now 195312 (1k) blocks long.
これで220MB強のサイズになった。
mpdインストールの工程が終わって出来たmicroSDカードから「dd」コマンドでバックアップのディスクイメージを作る。
これは普段使いのノートPC、Fedoraでの仕事。
若干余裕を見て、250MB程の大きさで指示する。
[ab@fedora1 ~]$ sudo dd if=/dev/sdb of=~/Downloads/z.img bs=1M count=250 status=progress 255852544 bytes (256 MB, 244 MiB) copied, 8 s, 31.9 MB/s 250+0 レコード入力 250+0 レコード出力 262144000 bytes (262 MB, 250 MiB) copied, 8.2029 s, 32.0 MB/s [ab@fedora1 ~]$
これで、262.1MBのディスクイメージが出来た。
何かあった時に焼いて使う。
以前に、大きくし過ぎたパーティション(SDカードいっぱいで8GBとか)を縮小してバックアップしようと試みたこともあったんだけど、動作しなくなったり何かと不具合があったので、やっぱり予め小さめに作った上でディスクイメージにした方がいいと考えた。
めったにこういうことはしないので、じきに忘れるので備忘録。
今回はせっかくなのでネットラジオもpiCore7で聴けるようにした。
NASにそれ用のディレクトリ「netradio」を作ってpls形式というネットラジオ用のファイルを置く。
mpdはこれらをプレイリストとして扱うので、ncmpcppで選択して再生指示すれば、ストリーミング再生が可能。
Linnのネットラジオとかを聴いている。
本当はらじるらじるとか聴けるようにしたいんだけど難しい。もっと簡単に聴けたらいいのに。
ただ、ネットラジオ再生中、ときどきncmpcppがエラー音を吐く。
コンポのほうは問題なく再生しているけど、クライアントpcから「ピコッ、、、ピコッ、、、」と音がするのだ。ncmpcppを閉じると消える。起こすとまた鳴り始める。
曲が変わると消えるので、音源由来で何かあるのかもしれないけど、よく分からない。
Ras pi2からの出力について。
usb出力はDACの追加が要るので扱いにくいし、i2s DACでアナログ出力もアンプに受け入れ場所がない。
そういうわけで、hifiberry Digi+で、SPDIF出力することにした。
出力先をSM-SX100やOdeon-liteにしたら、768/32 PPAPとの切り替えの際にSM-SX100の入力セレクターを弄らないといけない。
ずいぶん前からセレクターの反応が悪いので、なるべく触りたくないという事情がある。
ADI-2 DACにはusb、coaxial、optical、3つの入力端子があるんだけど、何れかからの入力があれば自動的に識別して再生してくれる機能がある。つまり、入力切替をDACがやってくれるということだ。
apu2d4からのusb-768/32と、ras pi2-Digi+からのoptical-96/24、両方をADI-2 DACに繋いでおけば、椅子に座ってノートPCからどちらのmpdを鳴らすか指示を出すだけで、ADI-2 DACが入力された音源を再生してくれて、SM-SX100のセレクターは触る必要がない。
問題は両方から同時に入力したらどうなるか分からないってことだけど、これはしないように注意するということで。
そういうわけで、現在はPCトラポは2本立てだ。

GWでのんびり過ごしていても、世界は大きく揺れている。
とにかく、暮々もみなさま、御自愛の程を。
Apr 14, 2020
700kHz台でPPAP 複数のFrontを使い分ける(2020.05.01、2023.06.22 追記)
2023年6月22日、追記。
久しぶりにこの手法を使ってみようとしたら、なぜか使えなくなっていた。
1つのシステムで2つ以上のncatを動かせなくなった、と言えばいいか。
使えない理由ははっきりしない。というか、こうなると、当時使えた理由も分からない。なんで動いたんだろう、というか。
しかし、あれこれやるうちに、当時のやり方を思い出してきて、何で出来たのか分かった。
当時は2つめのncatは、sshでログイン後にターミナルソフトからコマンドを打っていたのだ。
自動起動のncatと、ターミナルから起動するncatでは、ユーザーが異なる。要するに、其々のncatにユーザーが1つずつ必要なのだ。2つのncatを動かすには、2つのユーザーが要る。
このあたりの手法は、記録していなかった。
当時は、bootlocal.shから2つ起動させようとしなかったので、気付かないままになったらしい。
以上、追記。
768kHzのPPAPで聴き始めて1ヶ月程。
前回のエントリーで戻れないだろうと書いて、やはりその通りになっている。
音源の音楽的な情報を今まで以上に引き出していると思う。より生々しく、色彩、陰影豊かにという感じ。
ただ、この聴き方だとうまくいかない音源が散見される。
クラシック系や録音が良いとされている音源はたいてい問題なく、768kHzでより良く鳴ることが多い。
しかし、ポップミュージック系は録音の良し悪しの幅が大きく、良くないものは一層の違和感を生じるようになった。
以前にエントリーに上げていたボーカルの違和感というのではない。それはむしろ減っている。
それよりも、作品の音質全体がなんだか上手くいっていないというか、粗が目立つというか、聴き続けるのが苦痛になる。高域がきついとかノイズっぽいとか聴き疲れするとか、そういうのではなく、ただただ録音が悪いというのがはっきり分かっていやになる感じ。
そこまでひどいのは、そんなに多くはないのだけど。
精緻なオーディオ再生はもとから考えていないだろうなという音源の一部は、768kHzで聴かないほうがいい。
いっそのことと思って、そういう音源は768kHz以下の周波数、例えば192kHzでの再生を試みている。
そのぐらいに落としたら、違和感なく聴ける音源も増えてくる。
方法は、下図の通り。
うちのシステムの上流は最近はこんな感じだ。

上にBack-endのapu2d4。
中央に2つのFront。1つはapu2c4、もう1つは新たに入手したHP Elitebook 2570p。
下に、mpdクライアントncmpcppを動かすHP compaq 6730b。
Back-endのapu2d4には2組のncat/aplayeraplayが動いていて、異なるサンプリング周波数、ビット深度を担当している。
異なるポートをあてがうことで、こういうことが可能になる。
ともに出力はusbで1つのDACに継いでいるので、同時に音出ししたらどうなるのかということはあるのだけど、怖くて試していない。
その点で注意は必要だが、Back-endの設定変更の手間をかける必要なく入出力を変更できるのは便利だし、スピーディに変更できるので音質の比較も容易になる。
コマンドが1つか2つかで音質の変化があるかどうかは、僕には聴き分けられなかった。
Front 1は以前から使っているapu2c4。
ずっと705.6kHzへのアップサンプリングで使ってきたんだけど(768kHzは限界を超える)、より高スペックのPCから出力する768kHzのほうが1割方、音がいい。そこで、低めのサンプリング周波数でのPPAPに対応してもらうことにした。今のところ192kHz/24bitだが、どのあたりが塩梅がいいか、追々検討していくつもり。
apu2c4の使用法を変更するにあたって、mpd.confの設定に多少戸惑った。
というのは、192kHzや96kHzで音を出すと、なぜか音が途切れるのだ。
アップサンプリングの負担は少ないはずなのに、、、以前使っていた時、どうだったっけ?
あれこれ試行錯誤したところ、どうもPPAP Frontには「buffer_before_play」を奢ってやる必要がある事が分かってきた。
この数値が足りないと、音切れが起きやすかったりクライアントからの操作への追随が遅れたりと、問題が起きる。
しかし、以前は気付かなかった。
もしかしたら、使用するハードによって何か違ってくるのかもしれない。分からないけど。
Front 2のHP Elitebook 2570pは中古で新規購入した。
HP ProBook 650 G1を使っていたんだけど、サイズが大きめなのと、将来的に子供がwindows10で使う役割が急にできてしまった。
どうしたものかと迷ったんだけど、結局、HPのノートにした。
まずモニターが付いていて折りたためること。1ボードPCで必要に応じて外部モニターやシリアル接続というのもあるけど、bios確認するのにいちいちモニターとか面倒だ。最終的にノートにすることにした。音質への影響は、多分それでも十分だろうと割り切った。
650 G1よりもう少し小型で、メモリの速度が十分で、というわけで、中古で1万3千円強だった2570pにした。たぶんwindows7でHDDにリカバリ領域がないから安かったのではないか。usb起動で使うのでHDDは外してしまった。こういう対応がしやすいのもこの機種を選んだ理由。
usbメモリにtiny core pure64 11.1で起動して、mpd 0.20.20をインストールしてFront化した。
768kHz/32bitを問題なく再生出来ている。
しかし、少し音が硬いんだな、、、
サイズが小さい割に3kgもあって、それで凝集した感じの音になってるのか?と思ったけど、徐々にほぐれつつある気がする。
あと、メモリが4GBと650 G1よりも少ない。これは追々、増やしてみようと思う。
5月1日、追記。
メモリを8GBにしてみた。意外にも、というとあれだが、かなり良くなった。
床に根を張ったような安定感がある音がする。大地に根を張るような、とまでいうのは気恥ずかしいので謙遜した。しかし床といってもグランドピアノを置いてある床のつもりなので、まあ、そういう感じだ。キレもいい。空気を貫いてくる音が貫く空気の感触がわかる感じ。どういう感じだ。
これだけ鳴ってくれたらもう十分かも、という音が出ている。過去にも繰り返しそんな事を言ってるけど。
しかし、そんな状態でも下記のようなエラーが出る事があった。
tc@box:~$ 768 Playing raw data 'stdin' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo Playing raw data 'stdin' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo underrun!!! (at least 6168.253 ms long) Playing raw data 'stdin' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo Playing raw data 'stdin' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo ^C
768というのはalias登録している短縮コマンドで、768khz/32bit PPAP back-endとして機能してるということだ。
「underrun!!!」とエラー表示されている。
このエラーが出たときは数秒間、音が途切れた。
6秒までは途切れなかったと思う。3、4秒だったんじゃないかな。1回きりで、その後はない。ないので、様子見ということに今はしている。
クライアントは普段使いのHP Compaq 6730bで、ncmpcppでFrontのmpdにアクセスし操作している。
図の通りなんだけど、アカウントを複数使うことで、設定が異なる複数のncmpcppを同時に運用できる。ターミナルソフトのウインドウが多くなると紛らわしいので、ワークスペースの切り替えで対応している(ワークスペースというのはlinuxの機能で、切り替えが効くデスクトップみたいなものだ)。
将来的には、2つのFrontを1つにまとめていくことも考えている。
つまり、Frontにアカウントを追加して、個々のアカウントでmpdを動かせば、1つのPCで複数のmpdを動かす事ができるということだ。
クライアントへのポートは6600がデフォルトだけど、他の使われていない数字を充てることもできるので、1つのPCで、複数のクライアント、複数のmpdを動かすことができるのではないか(つまり、過去のエントリー http://blown-lei.net/endive/blosxom.cgi/audio_diary/20161231a.htm に記載したようなことをやる)。
まあ、先の話だけど。
新型コロナウイルスが、日本中、世界中で僕達の生活を脅かしている。こんなことはSF小説で読んだ事があるばかりで、現代社会で実際に起きるという気構えは全くしていなかった。そして、ここまで政府が無能だということも、、、いや、無能というよりも怠惰で非情ということだ。予想してなかったとは言わないが、もう少しマシであって欲しかった。
それでも、この現実に向き合い、対処しないといけない。
協力できる人と協力し、できることを行い、1人でも多くの無事を祈るばかりだ。
とにかく、みなさま、御自愛の程を。
Oct 29, 2019
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その4:動作確認)
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その1:準備)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027a.htm
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その2:0.20 インストール)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027b.htm
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その3:0.21 インストール)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027c.htm
今回、Tiny CorePure64-10.1にmpd 0.20、0.21をインストールしたのでエントリーにした。
エントリーを分割して、これが最後、動かしてみてどうかという話を少しだけ。
テスト用に、700kHz台を受けることが出来るDACということでSMSL M100を入手して動作確認に使った。
tc@box:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: v10 [SMSL M100 v1.0], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 tc@box:~$ cat /proc/asound/card*/pcm0p/sub0/hw_params access: RW_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 705600 (705600/1) period_size: 32768 buffer_size: 131072 tc@box:~$
まず気付いたのは、768kHzにアップサンプリングしたら明らかに音が途切れるということ。
mpdのログを確認したら、下記の記載が多発。
Dec 07 05:21 : player: Decoder is too slow; playing silence to avoid xrun
デコードが追いついていないと。
705.6kHzだと今のところ問題ない。といっても、まだそんなに長く聴き込んだわけではない。
以前、現在のメインシステムであるTiny CorePure64-7.2、mpd 0.19.19で鳴らしていたときに、768kHzはごくごく稀にクリックノイズが聞こえるような気がする、と思ったことがあったけど、もしかしたら実際にエラーがあったのかもしれない。うっかり者で、そのときのログは確認していない。
新しいシステムの方が、原因はmpdなのかtiny coreなのか分からないが(v0.20、v0.21両方なので、tiny coreのほうだと思うけど)、データが大量になった時の処理が苦手なのかもしれない。これは今後どうなのかを確認しながら使っていく必要があるかな。tiny coreの処理能力については、インストールした環境に足りないものがあるかどうか調べる必要がある。
音質の比較はまだ出来ていない。
さらにリピーターハブの評価もしないといけないのだけど、暇もない。
SMSL M100の音は1万円しないDACだと思うと大したものだと思うが、さすがにadi2-DACには及ばない。
評価は、adi2-DACじゃないと出来ないと思うけど、新しいシステムをつないでみることすら、まだ出来ていない。今後、余裕ができたらということになる。
Oct 27, 2019
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その3:0.21 インストール)
ここでは「mpd 0.21.16」のインストール手順を記載する。つまり、現時点での最新バージョンだ。
これは下記エントリーから続く。
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その1:準備)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027a.htm
準備が出来たところで、mpdインストールを開始。
v0.21.16インストールの備忘録。
コマンドを時系列で羅列。
sudo ntpclient -s -c 1 -h ntp.nict.jp wget https://www.musicpd.org/download/mpd/0.21/mpd-0.21.16.tar.xz xz -dv mpd-0.21* tar -xf mpd-0.21* cd mpd-0.21* mkdir ../mpd
まず、ntpクライアントを動かして、時刻を現在に合わせる。
これをしていないと、コンパイル作業自体が途中で停止する。
続いて、mpdのソースをダウンロードして展開。
ディレクトリを移動し、ホームにmpdディレクトリを作って、そこにインストールする。
ここはv0.20以前と同じ。
meson . ../mpd --buildtype=debugoptimized -Db_ndebug=true ninja -C ../mpd sudo ninja -C ../mpd install Installing mpd to /usr/local/bin Installing /home/tc/mpd-0.21.16/mpd.svg to /usr/local/share/icons/hicolor/scalable/apps Installing /home/tc/mpd-0.21.16/AUTHORS to /usr/local/share/doc/mpd Installing /home/tc/mpd-0.21.16/COPYING to /usr/local/share/doc/mpd Installing /home/tc/mpd-0.21.16/NEWS to /usr/local/share/doc/mpd Installing /home/tc/mpd-0.21.16/README.md to /usr/local/share/doc/mpd
v0.20以前は、./configure、makeでインストールしていた。
v0.21は、meson、ninjaを使う。
こんなん初めて使う。
上記のコマンドは、ダウンロードしたmpdソースの「user.rst」ファイルに記載してある、そのまんまである。
mesonは、必要な環境さえできていれば順調に進む。
ninjaも、順調に進むかに見える。
何処に何をインストールしてます、と最後に表示される。
v0.20以前のmakeだったら、tcホームディレクトリに作った「mpd」ディレクトリにmpdがインストールされて、その「mpd」ディレクトリをtczファイルに加工してoptionalに保存したらよかった。つまり、tczファイルに加工できる形に、makeがインストールしてくれていたのだ。
しかし、ninjaはそうはいかないことが分かった。ninjaの場合、上記に表示されたインストール場所にファイルが、一時的に、インストールされるだけ。「mpd」ディレクトリはインストールに使われる場所だけど、これをtczファイルに加工してoptionalディレクトリに移しても、今までどおりには動いてくれない。というか、mpdが起動しない。起動しない以前に「そんなコマンドはない」と蹴られる。
つまり、従来どおりのやり方ではインストールしたはずのものが消えてしまう、ということだ。
そこで、下記のような操作を行う。
cd mkdir mpdx mkdir mpdx/usr mkdir mpdx/usr/local mkdir mpdx/usr/local/bin cp /usr/local/bin/mpd mpdx/usr/local/bin
ninjaによるインストール終了後、cdでtcホームディレクトリに移動。
ここで「mpdx」ディレクトリを作る。
つまり、これをtczファイルを作る元のディレクトリにするのだ。
何処に何がインストールされたのかは、ninjaが最後に表示している。
/usr/local/bin にmpd、/usr/local/share以下に書類とアイコンらしきもの。
ということで、「mpdx」ディレクトリ内に/usr以下の階層構造を構築、実際の構造を「mpdx」内にコピーする。
/usr/local/share以下にインストールされたものは、mpdの動作には関係ない資料で、捨ててしまっても問題ない。
だから、/usr/local/bin/mpd だけ、~/mpdx/usr/local/binにコピーする。
mksquashfs mpdx mpd-0.21.16.tcz md5sum mpd-0.21.16.tcz > mpd-0.21.16.tcz.md5.txt sudo mv *tcz* /mnt/*1/tce/optional sudo vi /mnt/*1/tce/onboot.lst (write : mpd-0.21.16.tcz)
mksquashfsコマンドで、mpdxディレクトリをtczファイルに加工する。tczファイルからmd5.txtファイルを作る。
これらを、optionalディレクトリに移動。
更に、onboot.lstを開き、一番下に「mpd-0.21.16.tcz」と記載。
これで、インストール完了、、、、
この手法は、v0.20以前のインストールでmakeが作る「mpd」ディレクトリの構造を確認して、思い付いた。うまくいくかどうかは分からなかったけど、やってみたら上手くいった。
早々、追記。こうしたやり方についてどこかに書いてないかというので確認した。
http://tinycorelinux.net/book.html
Tiny Coreのサイトから、解説pdfがダウンロードできる。
このファイルの85ページにtczの構造について記述がある。
間違ったやり方ではなかったということで安心した。予め読んでおけということなんだろうけど、英文でなかなか読めない。
vi .mpdconf 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" #auto_update_depth "3" mixer_type "software" # optional audio_output { type "alsa" name "My ALSA Device" device "hw:0,0" # optional # mixer_type "software" } filesystem_charset "UTF-8" resampler { plugin "libsamplerate" type "Fastest Sinc Interpolator" } audio_output_format "705600:32:2" mkdir .mpd mkdir .mpd/playlists sudo rm -rf mpd* filetool.sh -b sudo reboot
あとは、mpdの設定。内容は各自必要な感じで。
「samplerate_converter」の項目はなくなって、代わりに「resampler」の設定が追加になっている。これは使い方に注意が必要。
https://www.musicpd.org/doc/html/plugins.html#resampler-plugins
こちらmpdのサイトに設定法が書いてあるが、なんだか分かりにくい。
libsamplerateの場合、「type」で"Fastest Sinc Interpolator"等の設定をするようになっている。
設定ファイルに合わせて、必要なディレクトリを作成。
インストールに使って、いらなくなったファイルをまとめて削除。
設定保存のコマンド「filetool.sh -b」を打って、OSをリブート。
以上でmpd 0.21.16インストール終了。
meson、ninjaにはだいぶてこずったけど、なんとかなった。
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その2:0.20 インストール)
ここでは「mpd 0.20.20」のインストール手順を記載する。
下記エントリーからつづき。
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その1:準備)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027a.htm
準備が出来たところで、mpdインストールを開始。
v0.20.20インストールの備忘録。
コマンドを時系列で羅列。
sudo ntpclient -s -c 1 -h ntp.nict.jp wget https://www.musicpd.org/download/mpd/0.20/mpd-0.20.20.tar.xz xz -dv mpd-0.20* tar -xf mpd-0.20* cd mpd-0.20* ./configure --enable-pipe-output make mkdir ../mpd sudo make DESTDIR=../mpd install
まず、ntpクライアントを動かして、時刻を現在に合わせる。
これをしていないと、コンパイル作業自体が途中で停止する。
続いて、mpdのソースをダウンロードして展開。
ディレクトリを移動し、ホームにmpdディレクトリを作って、そこにインストールする。
cd mksquashfs mpd mpd-0.20.20.tcz md5sum mpd-0.20.20.tcz > mpd-0.20.20.tcz.md5.txt sudo mv *tcz* /mnt/*1/tce/optional sudo vi /mnt/*1/tce/onboot.lst (mpd-0.20.20.tcz)
cdコマンドでtcホームディレクトリに戻る。
mpdがインストールされているディレクトリ「mpd」をmpd-0.20.20.tczファイルに加工。そこからtcz.md5.txtファイルを作成。
これらのファイルを、貯蔵庫のoptionalディレクトリに移動。
onboot.lstを開き、一番下に「mpd-0.20.20.tcz」と追記。
これで、インストールされたmpdがSDカードに保存され、OS再起動後にも使えるようになった。
vi .mpdconf 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" #auto_update_depth "3" mixer_type "software" # optional audio_output { type "alsa" name "My ALSA Device" device "hw:0,0" # optional # mixer_type "software" } filesystem_charset "UTF-8" resampler { plugin "libsamplerate" type "Fastest Sinc Interpolator" } audio_output_format "705600:32:2" mkdir .mpd mkdir .mpd/playlists sudo rm -rf mpd* filetool.sh -b sudo reboot
mpdの設定ファイルを作成。内容は各自必要な感じで。
ただ、「samplerate_converter」の項目はなくなって、代わりに「resampler」の設定が追加になっている。これは使い方に注意が必要。
https://www.musicpd.org/doc/html/plugins.html#resampler-plugins
こちらmpdのサイトに設定法が書いてあるが、なんだか分かりにくい。以前のように「quality "Fastest Sinc Interpolator"」と設定したら読み込まれなくて、もしかして、と思って上記のように「type "Fastest Sinc Interpolator"」と書いたら機能した。
上記ページの設定法説明の記載、書いた人は分かりやすいつもりらしいが、ぱっと見、分からんよこれは。
フォーマットの指定をどこにしたらいいのかも書いていない。以前と同じにしていたら機能するみたいだけどさ。
設定ファイルに合わせて、必要なディレクトリを作成。
続いて、インストールに使っていらなくなったファイルをまとめて削除。
設定保存のコマンド「filetool.sh -b」を打って、OSをリブート。
以上でmpd 0.20.20インストール終了。
時間設定をしないとインストールできないこと以外は、tiny corePure64-7.2、mpd 0.19の場合と大差ない感じ。
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その1:準備)
Tiny CorePure64-10.1にmpd 0.20、0.21をインストールしたので以下、備忘録。
今回はエントリーを分割する。
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その2:0.20 インストール)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027b.htm
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その3:0.21 インストール)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027c.htm
まず、準備編。
といっても、ほとんどは以前のエントリーからの引用コピペだけど。
読み易くまとめておきたいというのはある。
SDカードにTiny CorePure64-10.1を焼き込むところから。
準備するものを列記。
1)CorePlus-current.iso:
Tiny Core Linuxのサイト(http://tinycorelinux.net/downloads.html)からダウンロードしたインストーラーOSのイメージファイル。「CorePlus」から落す。うちではCD-ROMに焼いたけど、条件が合うならusbメモリに書き込んで使ってもいい。
2)64bit PC:
インストールの母艦。
CorePlus-currentからの起動、SDカードへのOS書き込みと、SDカードにインストールしたTiny Coreからの起動を行う。だから、まず必要な機能はCorePlus-current.isoを書き込んだメディアからの起動と、SDカードからの起動ができること、だ。内蔵DVDドライブとかusb接続のカードリーダー、何でもいいから、使うことになるメディアから起動できる機械を用意する。且つ、CorePlus-currentから起動し、そこからSDカードに書き込みを行うので、2つのメディアを同時に使えるほうがいい(Tiny Coreはメモリ上で動くので、実はCorePlus-currentを起動した後はメディアは外せるんじゃないかと思うんだけど、試していない)。64bit OSを動かすから、当然64bit PCである必要がある。最近の機械なら大抵大丈夫だと思う。あと、sshで遠隔操作するのと、インストールするOSをダウンロードするので、ネットにつながる家庭内有線LANが使えること。無線で出来ないのかというのは、やってできないことはなさそうだけど、僕は面倒なのでしない。
うちではhp compaq 6730b、サブマシンのノートを使った。内蔵DVDドライブとusb端子4つとSDカード端子が付いていてSDカードからの起動もできて扱いやすい。usbカードリーダーからの起動も使おうと思えば使える。
3)sshクライアントPC:
ssh経由でOS、mpdのインストール操作からmpd起動までのほとんどを行うことになる。sshが使えたら普段使いのPCで構わないと思う。
4)apu2、SDカード:
apu2c4は現在は販売は終了しapu2d4が売られている。
準備ができたら、64bit PCを、CorePlus-current.isoを書き込んだメディアで起動する。
起動画面が表示されるので、下の方、「No X/GUI」と書いてあるのを選択し起動する。CUI画面で起動するので、以下、流れを羅列。
################## (boot 64bit PC CorePlus-current.iso CD-ROM No X/GUI : install openssh) sudo passwd tc tce s ssh 7 : 7. openssh.tcz q i q sudo /usr/local/etc/init.d/openssh start
CorePlus-currentが起動。ユーザーは「tc」になっている。
sshでログインできるように、passwdコマンドで「tc」のパスワードを設定。
tceコマンドで、opensshをインストールする。
「s」を打って「enter」、検索語入力になるので「ssh」、1からずらっと来て、7. openssh.tcz、と表示されるので「7」と打ち込むとopen.sshの説明が表示されるので「q」で閉じて、「i」でインストール。関連したものも含めてスイスイとインストールされる。「q」でtceを閉じる。
この「7」というのは、Tiny Coreのバージョンやリポジトリ?の状況で変るので、確認しながらインストールしていく。
「sudo /usr/local/etc/init.d/openssh start」と打ち込むと、sshサーバーとして起動する。
これで、他のパソコンからsshでログイン、コントロールできる。
2020.03.20. 追記。
上に、コマンドを打ち込むとsshサーバーとして起動すると書いたが、CorePlus-current.isoのバージョンによっては、それだけでは起動できないことが分かった。
このエントリーの下の方に書いているような、面倒な手順が必要になる。
sudo cp sshd_config.orig sshd_config sudo /usr/local/etc/init.d/openssh start
こんなコマンドを打ってsshd_configを作らないと、opensshを起動できない。
日本語キーボードには対応していないので「shiftキー」+「-キー」で「_」を入力してコマンドを打ち込む必要がある。
################## (change machine : ssh login 64bit PC : install tiny core OS installer) ssh tc@192.168.1.xxx tce-load -wi tc-install.tcz wget http://tinycorelinux.net/10.x/x86_64/release/CorePure64-10.1.iso cp `which tc-install.sh` . sed -e 's/vmlinuz/vmlinuz64/g' -e 's/core/corepure64/g' tc-install.sh > tc-install64.sh
おもむろに腰を上げて、sshクライアントとして使うPCに向かう。うちでは普段使いのノートPCを使った。sshでCorePlus-currentが動いているインストール母艦にログイン。ユーザー「tc」、パスは先刻設定したはず。ipアドレスは環境によって変わるので各個で確認のこと。
インストーラである「tc-install.tcz」をダウンロード、インストール。CorePlus-currentはインストールに使うOSなんだけど、なぜかインストーラをここでインストールしないといけないみたい。続いて、インストールするOSのイメージファイル「CorePure64-10.1.iso」をホームディレクトリに落とす。インストールスクリプト「tc-install.sh」をホームディレクトリにコピー。そのスクリプトの書き換え。これをしないと、インストールできないということらしい。
################## (insert SD card : OS install) fdisk -l sudo sh ./tc-install64.sh i :iso-file /home/tc/CorePure64-10.1.iso f :frugal 2 :partition 4 : 4. sdb1 y : Would you like to install a bootloader? Press Enter key : (Install Extensions from this TCE/CDE Directory) 4 : 4. ext4 y : Mark sdb1 active bootable? y/n vga=normal syslog showapps waitusb=5 : Enter space separated boot options y : Last chance to exit before destroying all data on sdb1 Installation has completed Press Enter key to continue. sudo poweroff
一旦、インストール母艦の64bit PCのところに戻って、SDカードを刺して、sshクライアントPCに戻る。「fdisk -l」と打つと、64bit PC上のメディアの状況が一覧表示される。その中からSDカードのデバイス名を確認(うちではsdb1だった)。この確認を間違えると、母艦のOSが上書きされたりする大事故につながるので要注意だ。
「sudo sh ./tc-install64.sh」で、インストールスクリプトを走らせる。
「i」で、isoファイルからのインストールを選択。次にファイルのアドレスを打ち込む。
「f」はfrugal。zipの「z」やHDDの「h」でもいいみたいだけど、今回は「f」。画面には説明が英文表示されている。
パーティションにインストールするかどうか訊いてくる。パーティションでいいので「2」と応答。
インストールするパーティションを選択。今回は表示された中からsdb1を探して「4」。この数字はどこにインストールするかによって変わる。
ブートローダーをインストールするかどうか訊いてくる。「enter」で先に進む。
ファイル形式を訊かれるので「4」でext4を選択。
インストールするデバイスで起動可能にするかどうか訊いてくる。起動しないと困るので「y(yes)」。
オプションを訊かれるので、提示された例をコピペ。
「Last chance to exit before destroying all data on sdb1」と訊かれる。OSインストールするのでsdb1のデータが消えるのは仕方ないので「y」。
10秒ぐらいでインストール終了。これでSDカードに「CorePure64-10.1」が書き込まれた。
「sudo poweroff」でインストール母艦をシャットダウンする。
################## (change machine : boot 64bit PC SD card : install openssh, nfs) uname -a sudo passwd tc tce s ssh 6 : 6. openssh.tcz q i s nfs 3 : 3. nfs-utils.tcz q i s i2s : i2c-4.19.10-tinycore64.tcz q i q cd /usr/local/etc/ssh ls sudo cp sshd_config.orig sshd_config sudo /usr/local/etc/init.d/openssh start
インストール母艦の64bit PCのもとに移動。SDカードのCorePure64-10.1から起動する(必要ならBIOSで起動ディスクの優先順位を調整する)。これからSDカードに書き込まれたCorePure64-10.1を使えるように設定していく。
sshでログインできるように、passwdコマンドで「tc」のパスワードを設定。
tceコマンドで、opensshをインストールする。「s」を打って「enter」、検索語入力になるので「ssh」、1からずらっと来て、6. openssh.tcz、と表示されるので「6」と打ち込むとopen.sshの説明が表示されるので「q」で閉じて、「i」でインストール。関連したものも含めてスイスイとインストールされる。続いて、うちではNASをマウントして使うつもりなのでnfsもインストールしておく。
CorePure64-7.2と違うのは、ここで「i2c-4.19.10-tinycore64.tcz」をインストールしておかないとipアドレスが振られなくなりsshでログインできなくなること。tceから「i2c」で検索すると説明表示されるので、「q」で閉じて、「i」でインストール。
最後は「q」でtceを閉じる。
sshサーバーとして動かすために、/usr/local/etc/sshディレクトリに移動。sshd_config.origをコピーしてsshd_configを作る。ここで問題になるのは「_」の入力が日本語キーボードの表示のままに出来ないこと。CorePure64は英語キーボード配列しか認識していない。日本語キーボードからだと「shiftキー」+「-キー」で「_」を入力できる。キーボードが英語キーボードだったら、こんな面倒はないかもしれない。コピーができたら、opensshを起動。
################## (change machine : ssh login 64bit PC : basic setting SD card) vi .ssh/k* ssh tc@192.168.1.xxx sudo vi /opt/bootlocal.sh /usr/local/etc/init.d/openssh start /usr/local/etc/init.d/nfs-client start mkdir /mnt/music mkdir /mnt/music/ariel mkdir /mnt/music/titan chmod -R 777 /mnt/music vi /opt/.filetool.lst etc/shadow etc/passwd usr/local/etc/ssh/sshd_config usr/local/etc/ etc/fstab etc/securetty etc/inittab sbin/autologin vi .ashrc alias titan="sudo mount -t nfs 192.168.1.80:/titan /mnt/music/titan" alias ariel="sudo mount -t nfs 192.168.1.120:/ariel /mnt/music/ariel" filetool.sh -b sudo poweroff ################## (change machine : boot apu2 SD card)
おもむろに腰を上げて、sshクライアントPCに向かう。sshでCorePure64-10.1が動いているインストール母艦にログインするんだけど、アクセスする前に「vi .ssh/k*」で.ssh/known_hostsファイルを編集する必要がある。母艦にはdhcpサーバーからipアドレスを割り振られているんだけど、CorePlus-currentとCorePure64-10.1に同じアドレスが割り振られた場合(そうなる場合が多いと思うけど)、CorePlus-currentからもらった鍵はCorePure64-10.1には合わないのでログインを蹴られるのだ。予めknown_hostsファイルに保存されているインストール母艦のアドレスの行を削除し、その上で母艦にアクセスする。ユーザーは「tc」。パスは先刻設定した奴。
ログインしたら「/opt/bootlocal.sh」の編集。
「openssh start」の設定は必須。これを設定しておかないと、起動したあとでログインできないSDカードが出来てしまう。
「nfs-client start」は、nfsなんて使わないという人には要らない。
「/mnt/music」ディレクトリに関する記載は、OS起動時にmpdのmusic_directoryとNASのマウントポイントを作るという当方固有の設定だ。music_directoryを他に設定する場合は不要な記載。
次に「/opt/.filetool.lst」の編集。シリアル接続できるようにする設定も保存できるようにしている。
sshで継がるなら必要ないといえば必要ないのだけど。設定方法は下記エントリーを参照のこと。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191010a.htm
(apu2d4でTiny CorePure64 10.1を動かす)
「.ashrc」の編集、これはうちに固有の設定。うちではNASのマウントやmpdの起動はsshから行うのがデフォルトなのでalias設定している。
「filetool.sh -b」でSDカードに設定を保存、poweroff。これでインストール母艦の役割は一応終了。SDカードを母艦から抜き、apu2に刺して起動する。
################## (change machine : ssh login apu2 : setting) ssh tc@192.168.1.yyy tce-load -wi \ libsamplerate.tcz libsamplerate-dev.tcz alsa-config.tcz \ alsa-plugins.tcz alsa-modules-4.19.10-tinycore64.tcz \ alsa-dev.tcz alsa.tcz lame.tcz \ lame-dev.tcz libmad.tcz libmad-dev.tcz \ flac.tcz flac-dev.tcz curl.tcz tce-load -wi gcc.tcz meson.tcz ninja.tcz boost-1.65.tcz \ pkg-config.tcz bison.tcz binutils.tcz autoconf.tcz \ libtool-dev.tcz bc.tcz cmake.tcz compiletc.tcz tce-load -wi boost-1.65-dev.tcz tce-load -wi squashfs-tools.tcz tce-load -wi ntpclient.tcz
SDカードをapu2に刺して起動、apuのipアドレスを確認、sshクライアントPCからユーザー「tc」でログイン。
libsamplerateやalsa、flacなど必要なライブラリやプラグインをインストール。ここの項目は各々ユーザーのニーズに合わせて選択。
続いて、mpdインストールに必要な環境をインストール。mpd 0.21は、インストールにautotools、makeの代わりにmeson、ninjaを使う。0.20以前とはやり方が違っている。0.20のインストールには要らないんだけど、今回は環境が同じの方が手間がかからなかったので一緒にインストールしている。
boostは、boost-1.65.tczだけで事足りるかと思ったら、boost-1.65-dev.tczも必要。しかしこれをインストールしたら一緒にXシステムもインストールされるんだよね。。。ヘッドレスなのにいらんのではないのかと思うけど、なしでは何でかmpdのインストールと起動自体ができないので入れている。
squashfs-tools.tczがないと、ソースからインストールしたソフトをtczに加工できないのでインストール。
さらに、システムの時間を合わせないままだと「インストールに使うファイルがコンピューターの時間より新しいよ」みたいな警告が出てインストール作業ができない。ので、ntpクライアントをインストールする。セキュリティか何かの関係なんだろうか。これはCorePure64-7.2と違うところ。
ここらで、準備完了かな、、、
この段階でSDカードをイメージファイルにバックアップしておくと、あとあとmpdのインストールで失敗しても大丈夫。
mpdインストールは続きのエントリーで。
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その2:0.20 インストール)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027b.htm
apu2で、Tiny CorePure64-10.1にmpd(0.20、0.21)をインストールする(その3:0.21 インストール)
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20191027c.htm
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運用の時でも音質改善する可能性がある。
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 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が働き、そうでないなら働かないとしたら、なんとなく音色が違うのも辻褄が合う。
どんなものだろうか。
Mar 25, 2018
今一度、44.1/16を聴き比べる
先日、リサプラーによって再生音の定位に違いを生じるかどうか、libsamplerate使用、SoX使用、アップサンプリングなしの音を比較試聴し、違いがあることを確認した。
DACは、nano iDSD LE。
このとき、libsamplerate、44.1/16へのリサンプリング有る無しで聴き比べたが、違いがあった。
libsamplerateを通した音はlibsamplerateの音になる。
同じ44.1/16でも、リサンプラーを通すとリサンプラーの音になるのだ。
SoXと比較して、libsamplerateのほうが音への影響が良くも悪くも大きいと思う。libsamplerateはDA-AD変換をシミュレートするので、言ってみれば元から全てデジタル信号を再構築するわけだから、音が違って当たり前と、言おうと思えば言える。
しかし、デジタル信号自体が違うから音が違う、でいいのか?
前回の記録から試聴結果を引用してみる。順序は変えている。
44.1/16、リサンプリングなし。(NAS original音源)
チェロは右、SoXの時ほどじゃないけど、目の高さより若干高いことに気付いた。
ボーカルは中央、正面やや上に上がった。1分20秒すぎのボーカル、高音の響きが上~左向きに。2分台後半、やや右、後方に揺れる。
バス、ほぼ中央。44.1/16 (NAS resample音源)
チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。2分台後半、響きが右、後方に向かう傾向が強い。 バス、ほぼ中央右。44.1/16、リサンプリングなしでCCモード (ppap original音源 DAC:fireface UCX)
チェロは右、目の高さ。nano iDSD LEのときよりやや内側に寄る。
ボーカルは中央、正面やや上。しっかり肌理細やかに鳴る。1分20秒すぎ、高音の響きは上~左右に広がる。2分台前半、定位はしっかりしている。後半、響きが右、後方に向かう。
バス、中央右。
なんというか、定位について書かれている文面だけ見たら、LEでのオリジナル音源再生より、リサンプリングした音源の再生のほうが、UCXによるオリジナル音源再生に近いように見えなくもない。そして実際、聴いた音色の感触はそう感じられた。
リサンプリングすることに優位性があるなら、それは何処から生じるのか。
オリジナルデータのほうが正確なのは当たり前だ。リサンプリングがジッター低下につながる理由を探さないといけないってことだ。
構成図を見ながら考えてみる。

オリジナルデータ再生の場合は、NASからnfs経由で送られるflacデータをmpdがデコードしてalsaに送っている。
リサンプリングする場合は、NASからnfs経由で送られるflacデータをmpdがデコードしてlibsamplerateでDA-AD変換シミュレートし、そのデータをmpdがalsaに送っている。
ここで考えたのは、DA-AD変換シミュレートに際してデータがどこかにバッファされるはずだ、ということ。バッファされたデータを送り出すほうが、ジッターが減るのではないか。もともとmpd.conf上にバッファを設定する項目はある。しかしlibsamplerateのDA-AD変換シミュレートに使われるバッファは、たぶん別に用意されるはずだと思う。
バッファされたデータを送り出すということなら、RAMメモリ再生に近いと言えるかもしれない。
RAMメモリ再生で44.1/16にリサンプリングしたら、どう聴こえるだろうか。
試してみよう、、、と思ってた矢先、、、
、、、
nano iDSD LEが壊れたみたいだ、、、
入力の認識はしているようでインジケーターの色も変わるんだけど、音が出なくなった。
i2s DACでやってみようか、、、
聴こえ方がどうか、最初からしないといけないのか、、、
ppapのUCXと定位に差がなかったら、比較できないってことだな。
そういうわけで、piCore7でi2s DACを鳴らす環境をさっさと構築する。
というか、nano iDSD LEに繋がっていたras pi2からmicroSDを抜いて、config.txtを設定して、i2s DACを刺したras pi2に刺し直し、起動させるだけだ。
USBターミネーターは刺すけど、面倒なのでケースなしだ。
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 1862 1 tc S 133m 14.3 0 15.5 mpd PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 1894 1 tc S 133m 14.3 0 7.5 mpd PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 1879 1 tc S 133m 14.3 0 0.6 mpd PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 1911 1 tc S 133m 14.3 0 0.6 mpd
これはlibsamplerateによるアップサンプリングを行っている時のtop表示。
上が順に、192/24、96/24、44.1/16、44.1/16リサンプリングなし、だ。
サンプリング周波数が高いほど、CPU使用が多くなる。44.1/16はリサンプリングしようがしまいがCPU使用率が変わらない。それでも先日、聴き比べた時には確かに音は変わって聴こえたわけで、どこかで何かが何かしてるんだろう。
試聴だ。
音源は前回と同じ、幸田浩子「カリヨン」1曲目、カッチーニのアヴェ・マリア。
まず、リサンプラーなしの44.1/16、NAS音源。
チェロは右、目の高さ。、、これはUCXよりも中央寄りか?
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上向きに広がる。2分台前半、定位は比較的安定。後半、響きが上、右、後方に向かうけど、、定位自体は安定感がある。
バス、ほぼ中央右。
次、リサンプリングありの44.1/16、NAS音源。、、柔らかくなる。
チェロは右、目の高さ、、、だけどリサンプラーなしのNAS音源より、さらに内側に聴こえる。右中央?
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは広がるが、、そんな上にいかない。2分台前半、定位は安定。後半、響きが横には向かわない、やや後ろに向かうことあり、、、定位は安定感がある。
バス、ほぼ中央右。
次、リサンプリングありの44.1/16、RAMメモリ音源に替える。
チェロは右、目の高さ。あれ、、NASよりも外に。
ボーカルは中央、正面やや上。NASより少し低め。1分20秒すぎのボーカル、高音の響きは少し上に広がる。2分台前半、定位は安定。後半、響きは横には向かわない、やや後ろに向かうことあり、、、安定感がある。
バス、ほぼ中央右。
リサンプラーなしの44.1/16、RAMメモリ音源。
チェロは右、目の高さ。NASよりも少し外で変わらず。UCXと比べてどうだろう、、、
ボーカルは中央、正面やや上。NASより少し低め。1分20秒すぎのボーカル、高音の響きは少し上に広がる。2分台前半、定位は安定。後半、響きは横には向かわない、やや後ろに向かうことあり、、、やはり安定感がある。
バス、ほぼ中央右。
リサンプリングのあるなしで、ほとんど変わらない。
リサンプラーなしの44.1/16、NAS音源に戻る。RAMと比べると少し硬いかな。
チェロは右、目の高さ。RAM音源のときよりも5度ほど内側にいるみたい。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上向きに広がる。RAMより広がりは大きい。2分台前半、定位は比較的安定。後半、響きが上、右、後方に向かうけど、、定位自体は安定感がある。
バス、ほぼ中央右。
UCXで聴いてみる。リサンプラーなしの44.1/16、ppap方式。
チェロは右、目の高さ。NASよりも少し外。RAMメモリ音源と同じ位置。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは上に広がる。2分台前半、定位は安定。後半、響きは右からやや後ろに向かう。
バス、ほぼ中央右。
さて、、、図にしてみよう。

チェロの位置が変わるけど、どう評価したものやら。
本来は、リサンプルされたNAS音源の位置が正しいんだろうけど、より高性能なはずのDAC、fireface UCXの再生に近いのはRAM音源再生だ。そもそもコントラバスが中央で、本来の位置の右側から大きく外れているので、正確な再生はできていない中での試聴なので仕方ないかも。
ソプラノは、今回は前回よりも安定して鳴った。
定位のぶれが少ないのだ。
i2s DAC、侮れない。
数千円で買えるHATだから高級な音は望むべくもないので、普段はテスト用やサブシステムで使ってるけど、基本を押さえた音がする印象が以前からある。しかし空間を表現する音が少ないという弱点が逆に良い方向に作用したのかもしれない、のかな?
音色は、リサンプラーを通した音はRAMメモリ再生に近づくと言えば近づく。ソプラノの聴こえ方、響きの出方も似ている(試聴記録の文面、全く変えてないのは我ながらどうかと思うね、、)。
しかしチェロの定位が全く違う。これは、前回の結果と逆になったということだ。
そんなわけで、簡単に結論が出るもんじゃないんだろうけど。
今回はこのくらいにしておく。
Mar 18, 2018
MPDのアップサンプリングによる音への影響を確認してみる(SoXとLibsamplerateを比較する)
piCore7をpiped pcm audio playのフロントにしたので、最近はこれで鳴らしていることが多い。mpd出力も使うんだけど随分減った。
いろいろあるんだけど、整理がてら書いていく。
まず、ppapだとsoftwareボリュームが使えない(4月8日、追記。これは間違い。mpd.confで設定したら使える)。
以前なら音が大きすぎるなと思ったら、ncmpcppを操作してサッと音量を下げることができたが、ppapだとアンプまで歩いて行かないといけない。出力がpipeだからデジタルで調節できないのだ。
まあ、歩けばいいんだけどさ。
何か手立てはないかと思ってるんだけど、できていない。
フロントでalsaからncatに送るようにしたら出来るのかしれないけど、まだ十分に試みていないのだ。
そういうわけで現状、RAMメモリ再生だったらsoftwareボリュームで音量調整ができるけど、ppapならフロントにNASをマウントできるので好きな音源をさくさく選べるという、それぞれの優位性がある状況。両者の音質を比較しないといけないんだけど、これもできていない。
昨年の秋にノイズ対策でUSBターミネーター、LANにフィルターなどを追加し、USB-029H2-RPを導入したところ、音の出方がずいぶん変わった。更にppap方式も追加なので、短期間にほんとにあれこれ変わったので、途中経過が分からないんだけど、どうなってるのか簡単にまとめておく。
まず、素の44.1/16flacファイルの再生音がかなり底上げされた。
ppapで聴く44.1/16は、何しろ堅実でまっとうな再生という印象で、今まで聴いたことがなかった安定感がある。
くっきりした鮮度が高い感触は、以前よりも好ましい方向に強まっている。アップサンプリングした音の方が当たりが優しくて聴きやすいというのはあるんだけど、以前と比べたら差が少なくなった。44.1/16の特徴と思っていた若干肌理が荒い感じは減って、アップサンプリングした時の滑らかな感触に近づいている。
考えてみたら、これってRAMメモリ再生では感じなかったことなのだ。
しかし素の44.1/16でRAMメモリ再生をしたのは随分昔のことで、最近はアップサンプリングしてばかりだった。だから、再生方式による違いなのか、ノイズ対策の方が効いているのか、正確を期すなら確認する必要がある。
アップサンプリングのほうは、改善しているようなんだけど、そこまで大きな変化はない。
以前だったら、44.1/16は384kHzにアップサンプリングしたほうが情報量が多いと言えたんだけど、今は軽々しく言い難い。ちゃんとソースを選んで本腰入れて比較しないと、実際のところがどうなのか分からない。
じゃあ両者の再生音は近づいたのかというと、聴いた感触の違いはむしろ今の方が大きい。
オーディオ的にどちらが優位かがはっきりしなくなり、素の44.1/16の安定感とアップサンプリングの感触の良さ、そういう聴こえ方の嗜好のほうがむしろ、選択に影響する度合いが大きくなったのではないか、という感じ。
そういうところで、nano iDSD LEでアップサンプリングの音を確認することに、どれだけの意味があるのかな、と思うようになった。DACによって違うってことは当たり前にあるってことはあるんだろうけど、じゃあ、アップサンプリングの優位性があるかどうかはDACによる、ってことになるのかな。
以前だったら、明らかに384kHzにアップサンプリングしたほうが良くて、リサンプラーによる違いも明白だったので、ここは突き詰める必要があると思っていたんだけど、現在の音は、そこまでやる意味が減っているような。好みの問題に帰着するならするで、いいんじゃないの?という。
以前の音は、ジッターを生じやすい環境だとアップサンプリング(ハイレゾ)が有利というのに当てはまっていたのかとも思うけど。
今はそうじゃなくなった、のかなあ、、、どうなのか?
かたや、fireface UCXのほうはどうかといえば、これもあれこれあってCCモードのUSB入力になった。
SPDIF入力の時は192kHzにアップサンプリングする優位性があるように感じていた。
CCモードは96/24までなんだけど、これはアップサンプリングした方がいいのかどうか、音色はかなり違うけど分からない。どっちもどっちでいいので選択に迷う。これも先々きちんと比較する必要があるんだろうなと思う。
ああ、、、ひょっとしたら音色の感触が違いすぎるので逆に比較が難しくなってるのかな、、、
アップサンプリングについては、下記アドレスのような問題?も指摘されている。まさか定位に影響するとは。
http://community.phileweb.com/mypage/entry/2408/20180123/58315/
A:44.1KHz/16bit、44.1KHz/24bit、88.2KHz/24bit、176.4KHz/24bit
ボーカルは中央に安定 チェロは右中央 コントラバスは右
B:48KHz/24、96KHz/24、192KHz/24bit
ボーカルの定位はあいまいで不安定 チェロは中央、コントラバスは中央右
というように2分されます。AとBの中でも微妙な差はあります。例えば、16bitよりも24bitの方が滑らかで耳障りがよく感じる…とか、ボーカルの安定度は48KHzよりも96KHz、192KHzの方がよい…などです。ただし、その差はAグループとBグループとの音像定位の差ほどではなく微妙です。
アップサンプリングはトラポですることができる一方で、DACチップでも行われる。このへん、兼ね合いはどうなのか。DACチップ内で行われるアップサンプリング自体で定位が変わるということは、なにしろ製品なのだから有り得ないと、思っていいんだよね?、、、
あと、リサンプラーによって違うんだろうかとか。
そんなこんなで、これからどうしようかと思ってたけど取り敢えず、nano iDSD LEで自分なりにアップサンプリングの位置付けを明確にしよう、というところから始める。つまり、素の44.1/16から384/32までのアップサンプリング、をきちんと聴き比べてみようということ。リサンプラーも変えて。
これはppapではやりにくい。たびたびバックエンドを再起動する必要があるからだ。
あと、前回のエントリーに追記したけど、フロントにRas pi2/piCore7を使った場合、アップサンプリングで使えるのは192kHzまでのようだ。うちのppapでは、300kHz台へのアップサンプリングは聴けない。384kHzまでは確認したいので、そういう意味でも使いにくい。
だからNASマウントのmpdで設定を変えながら聴くことになる。
せっかくなので試聴に使うのは前述アドレスのサイトで話題になっている幸田浩子「カリヨン」1曲目、カッチーニのアヴェ・マリアにする。
まず、44.1/16を聴いてみる、、、
さっそく、前述のサイトで説明されているのとは聴こえ方が違う。
ボーカルは中央に安定 チェロは右中央 コントラバスは右、ということなんだけど、うちではチェロが右でコントラバスが中央あたりに聴こえる。ボーカルは中央なんだけど、歌い始めはこもり気味。数秒で落ち着いたと思ったら、その後は上を向いたり右を向いたりしてるような。録音現場の反射を多く捉えているような聴こえ方。というか、後ろ向いてるの?、、、
そういう録音なの?と思っていたら、聴き込んでる人の解説がアップされていた。
http://community.phileweb.com/mypage/entry/3255/20180127/58351/
一時は右を向いたり左を向いたりしながら歌っているためと、録音のせいにしたりしていたんです。ですが、再生側を追い込んでいくとボーカルは前に出てきて、かつ歌声もぶれなくなりました。
追い込みきれていないということらしい。なんという恐ろしいソフトか、、、
確かにうちの環境は全く反論できない状態にあるが、そうそう追い込む暇はないんだな。
しかたない。
この状況でどう聴こえるかでやってみようか、、、
実際に試聴した時系列に沿って書いていく。
まず、リサンプラーなしの44.1/16。
チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上~左向きに。2分台後半、やや右、後方に揺れる。
バス、ほぼ中央。
ボーカルは1分20秒すぎと2分台後半の定点観測と、他に気付いたことを書いていく。
リサンプラーにSoXを使用。
88.2/24
チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きが上に向かう。2分台後半、定位がやや右、後方に揺れる傾向あり。
バス、ほぼ中央左。
ソプラノ、口元が正面に向かない感じの時が多い。そんな聴こえ方だ。基本的にそういうソースなんだけど、それでもあれこれやってみた結果、安定して再生出来た時は比較的前を向いて歌っているように聴こえる時間が多かったように思った。
96/24
チェロは右に定位。なんと、目の高さより高くなった。
ボーカルは中央、正面やや上、やや響きが広がりぎみ、かつ響きが固い。1分20秒すぎ、高音の響きが上向き、さらに後方、左にも。2分台後半、やや右、後方に揺れる傾向あり。
バス、ほぼ中央。
176.4/24
チェロは右、目の高さ。
ボーカルは中央、正面やや上。響きが固い印象。1分20秒すぎのボーカル、高音の響きが上向きに。2分台後半、響きが右、後方に揺れるように聴こえる。
バス、ほぼ中央左。
194/24
チェロは右、目の高さよりやや高い。
ボーカルは中央、正面やや上、やや響きが広がりぎみ、やや硬い。1分20秒すぎのボーカル、高音の響きは上向き。2分台後半、響きが後方に揺れる。硬い響き。
バス、ほぼ中央。
352.8/24
チェロは右、目の高さ。
ボーカルは中央、正面やや上。1分20秒すぎのボーカル、高音の響きは上~右向き。2分台後半、響きが右、後方に伸びるように聴こえる。
バス、ほぼ中央左。
384/24
チェロは右、目の高さよりやや高い。
ボーカルは中央、正面やや上、やはり、やや響きが広がりぎみでやや硬い。1分20秒すぎのボーカル、高音の響きは上~右。2分台後半、定位が右に揺れる。硬い響き。
バス、ほぼ中央。
SoXで聴いてきて、どうも44.1xのほうが伸びやかで聞きやすい印象。コントラバスの位置がなぜか44.1xで左に寄る。
48xだとチェロがやや上に上がるのと、ソプラノなど音色の響きが固くて聴き辛い印象。300kHz台となればましになるような気はしたけど、、、あんまり変わらないかな、、、
リサンプラーをlibsamplerateに変更。
一気に音色がやさしくなる!
これは違いすぎる。ここまでちょっと辛い試聴だったことに気付かされた。
88.2/24
チェロは右、目の高さ。
ボーカルは中央、正面(やや下がった)。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上向き。やさしい響き。2分台後半、響きが前にでる。3分前、後方に揺れる傾向あり。
バス、ほぼ中央右。なんとまあ、SoXとは逆になった。
96/24
チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上~左右向き。2分台後半、やや右による傾向。
バス、ほぼ中央右。
176.4/24
チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上~左右向き。2分台後半、響き、定位ともに右による傾向。
バス、ほぼ中央右。
194/24
チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。やや左右に揺れる。1分20秒すぎのボーカル、高音の響きは上~左右向き。2分台前半、定位は右に傾きがち。2分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。
352.8/24
チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。2分台前半、定位はやや右に傾く。2分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。
384/24
チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。2分台前半、定位はやや右に傾く。2分台後半、響きが右、後方に向かう傾向。
バス、ほぼ中央右。
libasmplerateの場合は、サンプリング周波数による差異がSoXほど大きくない。
それと、サンプリング周波数を上げていくと順当に音が良くなっていく感触があったので、何となくいい気分で試聴できた。まあ、アルゴリズムの有り様から考えれば、サンプリング周波数での変化は少ないはずだという予測はしていた。
ものは試しと、libsamplerateで44.1/16にリサンプリングしてみた。
44.1/16
384と変わらない?w
チェロは右、目の高さ。
ボーカルは中央、正面(前と同じ)。響き成分多め。1分20秒すぎのボーカル、高音の響きは上向き。2分台後半、響きが右、後方に向かう傾向が強い。さすがに384よりも硬い響き。
バス、ほぼ中央右。
聴き始めは違いがないのかと思ったが、やはりボーカルなどの響きはアップサンプリングした方がいい。
ここでリサンプラーなしと聴き比べる。
44.1/16、リサンプリングなし。
チェロは右、SoXの時ほどじゃないけど、目の高さより若干高いことに気付いた。
ボーカルは中央、正面やや上に上がった。1分20秒すぎのボーカル、高音の響きが上~左向きに。2分台後半、やや右、後方に揺れる。
バス、ほぼ中央。
一言で言うと響きが硬い。
libsamplerateをアップサンプリングなしで通した音の方がずっと聴きやすくなるようだ。これは化粧した音と考えた方がいいのかな、、、しかし聴きやすいほうがいいよな、、、というか、最近はnano iDSD LEで聴くことは減ってきているので、この結果にあまり神経質になる必要はないのだけど。
2021.03.23. 追記。
今更だけど、libsamplerateを通すということ(というか、どんな方法にせよリサンプリング処理を行うということ)は、高域が減衰するということらしい。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20160724a.htm
「SRC_SINC_FASTEST」でもbandwidthは80%であり、サンプリング周波数を仮に192kHzとしたら、3dB減衰するのは、、、 192 x 0.8 = 153.6(kHz)
つまり、44.1kHzだと、44100x0.8= 35.28(kHz)で、3dB減衰。
可聴領域への影響は、むしろ300kHz台、700kHz台にアップサンプリングするよりもずっと大きい。
音が変わるのは当たり前か。
当たり前と言いながら、リサンプリングに際してサンプリング周波数が高くなるほど可聴領域への悪影響は小さく音質改善への寄与は大きくなるというのは、そんなに広く言われてはいないことだと思う。
気付いていたけど、ついつい忘れて放置していたけど、追記しておく。
2021.05.02. 遅ればせながら追記。
3月に追記した内容自体が間違ってるということなので訂正。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20160724a.htm
このエントリーに追記した内容をそのままこっちにも以下にコピペする。
2021.04.27. 追記。
Phile Webへの書き込みにレスをいただき、上記削除した内容について間違っていることが分かった(いや、書き込んでみてよかった!)。
リサンプリング後の周波数ではなく「前後どちらか、低い方のナイキスト周波数からみた帯域幅」について、説明されているということだ。低い方のナイキスト周波数を目安にして、ノイズが含まれる高域にフィルターをかけないといけないから、そういうことになるということらしい。
言われて考えてみたら、なるほど、という感じだ。あとで気付いたが、この件についてSRCのサイト、FAQに記載がある。
引用する。http://www.mega-nerd.com/SRC/faq.html
Q3 : If I upsample and downsample to the original rate, for example 44.1->96->44.1, do I get an identical signal as the one before the up/down resampling?
The short answer is that for the general case, no, you don't.The long answer is that for some signals, with some converters, you will get very, very close.
In order to resample correctly (ie using the SRC_SINC_* converters), filtering needs to be applied, regardless of whether its upsampling or downsampling. This filter needs to attenuate all frequencies above 0.5 times the minimum of the source and destination sample rate (call this fshmin). Since the filter needed to achieve full attenuation at this point, it has to start rolling off a some frequency below this point. It is this rolloff of the very highest frequencies which causes some of the loss.
The other factor is that the filter itself can introduce transient artifacts which causes the output to be different to the input.
ここのあたりは昔、目に通したことはある筈なんだけど、、、たぶん当時は意味が分からなくて、そのままになったのだと思う。
ちょっと今回、記載があるのをみて驚いた、、、ということは、bandwidth:80% というのは、44.1kHzをアップサンプリングする場合、17640Hzで3dB低下ということになる。もっと低い周波数から減衰は始まるはずなので、若い人なら高域が低下していると気付く人は、、、いるのかな、どうなんだろう。
音楽の楽音自体はピアノの高域が4000Hzぐらい。15kHzになると、僕には聴こえない。
最近、今回の指摘を受けて、MEDIUM_QUALITYの設定で聴いてみたのだけど、高域の違いというよりも、音楽全体の陰影、階調が深まったように聴こえる。ハードのスペックが数年前よりも上がっているので、いつの間にかMediumでも768kHzで再生できるようになっていたのだ(BEST_QUALITYでは、音が途切れて再生できない)。
これに気付いたことも今回の収穫だ。
そういうわけで、fireface UCXでどんな鳴り方になるか聴いてみる。
44.1/16、リサンプリングなしでCCモード、ppap。
チェロは右、目の高さ。nano iDSD LEのときよりやや内側に寄る。
ボーカルは中央、正面やや上。しっかり肌理細やかに鳴る。1分20秒すぎ、高音の響きは上~左右に広がる。2分台前半、定位はしっかりしている。後半、響きが右、後方に向かう。
バス、中央右。
こんな感じ。
しかし定位がどうとかよりも音色の格が違う。
NASマウントのLEとppapのUCXの比較だから当たり前だ。
UCXでアップサンプリングも聴いてみるべきか、、、と思ったけど、、、もういいか。
うちでは使うならlibsamplerateと決まっているし、UCXとLEの結果が知れたからといって、だからどうなのかということもあるし。
ともかく、リサンプラーによって良くも悪くも音が変るし、リサンプラーの種類やサンプリング周波数によって変わり方が違うのも確認した。多分、DACによっても違うんだし。きりがないっちゃきりがない。
自分の納得がいくように、気持ちよく聴けるようにやれたら、それでいいと思う。
僕は、一種のゲームのような感覚でオーディオをやってるんだと思う。ひとつクリアしたら次の課題に移るという感覚。
そして幸か不幸か課題には事欠かない。
2021.04.16. エントリーの主旨が分かりやすくなるようにタイトルに追記した。
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 03, 2018
piCore7にmpdをインストールする方法
このたびサイトのログを眺めていたら、意外にアクセスが多いのが下記のエントリーだと気付いた。
Raspberry Pi でメモリ再生を試みる(piCore7にmpdをインストールする)-いろいろ追記あり
音質向上を追及した多くのディストリビューションが公開されている中で、正直、piCore7にどの程度のニーズがあるのか分からないんだけど、なるべく分かりやすい形に書き直して、まとめておこうと思った。しかし、結果的に長くて分かりにくい。
毎度のことで、今回もあちこちに訂正とか追記、改訂を入れている。 1月9日、sshについて追記訂正した。rebootする前にfiletool.sh -bで鍵を保存してしまえば再ログインで蹴られることはない。こんな当たり前のことに気付くのに1年半かかっているということで、我ながら呆れてしまう。
piCore7をダウンロード。
以下、tiny core linuxのサイト、piCore7関係のソース。
raspberry pi B/B+ | piCore OS | http://tinycorelinux.net/7.x/armv6/releases/RPi/ |
TCZ | http://tinycorelinux.net/7.x/armv6/tcz/ | |
raspberry pi 2/3 | piCore OS | http://tinycorelinux.net/7.x/armv7/releases/RPi2/ |
TCZ | http://tinycorelinux.net/7.x/armv7/tcz/ |
piCoreはv.9まであるんだけど、mpdを簡単にインストールできるのはv.7しかない。
v.9用TCZとして用意されているライブラリにはDoxygenはないし、Boostはインストールしてもうまく機能しない。v.7のTCZは機能するようだ。
TCZというのはtiny core linux系のOSで扱いやすいようにソフトウェアやライブラリをパッケージ化したようなもので、基本的にはTCZの一覧表に載っているソフトなら簡単なコマンドを打つだけでインストールできる。ときにソフト間の依存性の関係によっては出来ないこともあったり、前述のようにインストールしたのに使えないこともあったりする。
1月末、追記。数日前に気付いたんだけど、v.6にもmpd.tczが追加されている。 いつの間に、、、記憶違いでなければ、前はなかったと思うんだけど、、、 当方で使ってみるには至っていない。
まず使用するras piに合わせてOSを落とす。
落としたらmicroSDに書き込む。
microSDの準備。
microSDにはPICOREというボリュームができているので、その中のconfig.txtを編集する。
うちではi2s出力とusb出力以外は使わないので、もとからある設定について下記のように記載変更している。HDMIやイヤホン出力を使う場合はこんな設定ではいけないらしいけど、どこをどうしたらどうなるかは調べていない。
dtparam=i2c=off,spi=off,i2s=on,i2c_vc=off
i2sデバイスを使用するなら、そのデバイスに合わせた設定を記載する。
例えばhifiberryのデバイスなら、以下のような感じ。
https://www.hifiberry.com/guides/configuring-linux-3-18-x/
DAC/DAC+ Light dtoverlay=hifiberry-dac DAC+ standard/pro dtoverlay=hifiberry-dacplus Digi/Digi+ dtoverlay=hifiberry-digi Amp/Amp+ dtoverlay=hifiberry-amp
例えばうちで使っているi2sDACはLINUXCOMのRBD-02+なので「dtoverlay=hifiberry-dac」と書き込む。
http://linuxcom.shop-pro.jp/?pid=79120318
piCore7を起動しsshでログインする。
microSDカードをRaspberry Piに刺して起動する。
余裕のある電源を使うこと。
sshでログイン。userはtc、パスワードはpiCore。
ログインに必要なipアドレスは環境によって変わるのでユーザー各自で確認のこと。ちなみにうちでは、いちいちDNSDHCPサーバーにアクセスして新たに割り振られたipを確認している。
sshでは最初のログインで(yes/no)?と訊かれるので、yesでログインする。
filetool.sh -b について
ログイン直後にfiletool.sh -b コマンドを打つことで、sshの鍵が保存される。
tc@box:~$ filetool.sh -b Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz\ Done. tc@box:~$
piCoreでは、上記タイトルのコマンドで、適宜、変更した設定などを保存しておく必要がある。
全てRAM上で動くOSなので、コマンドを打ってmicroSDに保存するのを忘れていたら、電源を切ると同時に設定していたはずの内容が消失してしまう場合がある。OSを再起動したら設定前の状態、以前に保存した状態に戻っている。
そういう理由で、一通り設定が終了するまでの間にしばしば使用することになるコマンドなので予めここに記述しておく。
filetool.sh -bを打たないまま、下記の行程のパーティション拡張を行なったら、piCore7上にsshの鍵が保存されないので、sshで再ログインしようとした際に蹴られる。もしもそうなったらどうしたらいいかは下の方に記載している。
パーティションディスクイメージを拡張。
以下の流れでパーティションディスクイメージを拡張。もともとは最低限の大きさなので、拡張しないと後で諸々のインストールに支障を生じる。
tc@box:~$ sudo fdisk -u /dev/mmcblk0 Command (m for help): p Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes 3 heads, 8 sectors/track, 646826 cylinders, total 15523840 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/mmcblk0p1 8192 69631 30720 c Win95 FAT32 (LBA) /dev/mmcblk0p2 69648 93119 11736 83 Linux Command (m for help): d Partition number (1-4): 2 Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 2 First sector (8-15523839, default 8): 69648 Last sector or +size or +sizeM or +sizeK (69648-15523839, default 15523839): 15523839
上記は、端末画面に表示されたものをそのままコピペしている。
適宜、表記されているpとかdとか2とか、打ち込んでenterキーを押していくと、物事が進行していく。
気を付けないといけないのは、どこからどこまで拡張するか指示するための数字。
Command (m for help): p でパーティションボリュームの状態が表示される。
上記の例では /dev/mmcblk0p2の startが69648、endが93119、ということだけどこれを拡張することになる。
First sectorは、startの69648のまま指示。Last sectorは93119以上にしないといけない。いっぱいに拡張するなら「default 15523839」と表示されているので、15523839と打ち込んで、enterキー。
以降、下記のように続ける。
Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy tc@box:~$ tc@box:~$ sudo reboot tc@box:~$ Connection to xxx.xxx.xxx.xxx closed by remote host. Connection to xxx.xxx.xxx.xxx closed.
ここでリブート。
注意しないといけないのは、パーティション拡張の指示をしたからだと思うんだけど、この時点でsshのkeyが無効になっている。そのままログインしようとしたら撥ねられるので、.ssh/known_hostsに保存されているipアドレス:xxx.xxx.xxx.xxxの行を削除しないといけない。削除したら再度、初回のログインの処理をしていけば、以降はkeyをなくすことはない。
うっかりして、filetool.sh -bコマンドを打ってsshの鍵を保存するのを忘れていた場合、リブートしたらsshの鍵が無効になっている。ログインしようとしたら撥ねられる。そうなったら、sshクライアントとして使ってるパソコンの.ssh/known_hostsに保存されている鍵、ipアドレス:xxx.xxx.xxx.xxxの行を削除する。削除したら、初回ログインと同じ行程でログインできる。
filetool.sh -bコマンドでsshの鍵を保存するのを忘れないこと。
再度、ログインして以降の流れは以下の通り。拡張作業の最終段階。
tc@xxx.xxx.xxx.xxx's password: ( '>') /) TC (\ Core is distributed with ABSOLUTELY NO WARRANTY. (/-_--_-\) www.tinycorelinux.net tc@box:~$ tc@box:~$ sudo resize2fs /dev/mmcblk0p2 resize2fs 1.42.13 (17-May-2015) Filesystem at /dev/mmcblk0p2 is mounted on /mnt/mmcblk0p2; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 30 The filesystem on /dev/mmcblk0p2 is now 7727096 (1k) blocks long. tc@box:~$
この流れは http://tinycorelinux.net/7.x/armv6/releases/RPi/README にも書いているが、ちょっと不親切。
コマンドの使い方を調べる必要があった。
うちの記述も分かりやすいとは言えないと思うけど、実際に触ってやってみたら分かるんじゃないかと思う。
filetool.sh -b について
piCoreでは、上記タイトルのコマンドで、適宜、変更した設定などを保存しておく必要がある。
全てRAM上で動くOSなので、コマンドを打ってmicroSDに保存するのを忘れていたら、電源を切ると同時に設定していた内容が消失してしまう。OSを再起動したら設定前の状態、以前に保存した状態に戻っている。
そういう理由で、一通り設定が終了するまでの間にしばしば使用することになるコマンドなので予めここに記述しておく。
ipアドレスを固定。
これも下記のような流れで。
まずifconfigで確認。
tc@box:~$ ifconfig eth0 Link encap:Ethernet HWaddr B8:27:EB:36:8A:DF inet addr:192.168.1.116 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:775439 errors:0 dropped:92 overruns:0 frame:0 TX packets:250166 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1123681152 (1.0 GiB) TX bytes:24070244 (22.9 MiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
上記の例では、192.168.1.116となっている。これはDNSDHCPサーバーから割り振られたもので、ネットワークの状況次第でこっちの知らぬ間に変わる可能性がある。うちでは変わられては困るので、固定している。
以下、流れを記載。
eth0.shを作る。
tc@box:~$ cd /opt tc@box:/opt$ ls bootlocal.sh bootsync.sh shutdown.sh tcemirror tc@box:/opt$ vi eth0.sh
/optディレクトリに移動。
ここには設定ファイルを置く場所で、ここにeth0.shを作ることでipを固定できる。
viでファイルを作成。
下記のように記載。
#!/bin/sh pkill udhcpc ifconfig eth0 192.168.1.82 netmask 255.255.255.0 broadcast 192.168.1.255 up route add default gw 192.168.1.1 echo nameserver 192.168.1.1 > /etc/resolv.conf
上記の例では、192.168.1.116だったアドレスを192.168.1.82に変更している。
bootsync.shを編集。
引き続き、流れを記載していく。
chmod +x コマンドで実行権限を変更。
さらに、bootsync.shファイルを編集。
tc@box:/opt$ ls bootlocal.sh bootsync.sh eth0.sh shutdown.sh tcemirror tc@box:/opt$ chmod +x eth0.sh tc@box:/opt$ ls -aFl total 28 drwxrwsr-x 3 root staff 200 Jun 4 12:46 ./ drwxr-xr-x 17 root root 380 Jan 1 1970 ../ -rw-rw-r-- 1 tc staff 403 Jun 4 10:53 .filetool.lst -rw-rw-r-- 1 root staff 145 Dec 31 2014 .xfiletool.lst -rwxrwxr-x 1 root staff 360 Jan 20 2015 bootlocal.sh* -rwxrwxr-x 1 root staff 272 Dec 31 2014 bootsync.sh* -rwxr-xr-x 1 tc staff 179 Jun 4 12:46 eth0.sh* -rwxrwxr-x 1 root staff 613 Dec 31 2014 shutdown.sh* -rw-rw-r-- 1 root staff 31 Dec 31 2014 tcemirror tc@box:/opt$ sudo vi bootsync.sh
bootsync.shに「/opt/eth0.sh &」の一行を下記のように書き加える。
起動時にeth0.shに記載した設定を読み込んでくれる。
#!/bin/sh # put other system startup commands here, the boot process will wait until they complete. # Use bootlocal.sh for system startup commands that can run in the background # and therefore not slow down the boot process. /usr/bin/sethostname box /opt/bootlocal.sh & /opt/eth0.sh &
.filetool.lstの編集。
tc@box:/opt$ vi .filetool.lst
.filetool.lstファイルは、前述した「filetool.sh -b」コマンドでデータを保存する場所を設定している。
これに「opt/eth0.sh」を追記する。
追記しなかったら、再起動したら設定が消えてしまうということ。
同時に、いくつか他にも保存して欲しい場所やファイルがあるので、これも追記する。
usr/local/etc/
opt/bootlocal.sh
以上を追記して、以下の通り。以前はetc/fstabも追記していたけど、うちでは使わないので。使うようなら記載を。
opt home etc/passwd etc/shadow etc/group etc/gshadow usr/local/etc/ssh/ssh_host_dsa_key usr/local/etc/ssh/ssh_host_dsa_key.pub usr/local/etc/ssh/ssh_host_ecdsa_key usr/local/etc/ssh/ssh_host_ecdsa_key.pub usr/local/etc/ssh/ssh_host_ed25519_key usr/local/etc/ssh/ssh_host_ed25519_key.pub usr/local/etc/ssh/ssh_host_rsa_key usr/local/etc/ssh/ssh_host_rsa_key.pub usr/local/etc/ opt/bootlocal.sh opt/eth0.sh
いきなり追記。
上の内容を眺めていて、今更一番上に「opt」とあるのに気付く。
これって、/optディレクトリの内容は保存されるってことじゃないだろうか。
試しに、
opt/bootlocal.sh
opt/eth0.sh
の2行を削除して動かしてみる。、、問題ないみたいだ。
.filetool.lstに追記しなくても、bootlocal.shもeth0.shもfiletool.sh -bで保存される。
ということで訂正。
usr/local/etc/のみ追記でいいようだ。
/usr/local/etc/にはalsaのファイルもあるようなので、追記しておいた方がいいんじゃないかな。たぶん、、、
忘れないように「filetool.sh -b」を打って、設定が失われないようにする。
tc@box:/opt$ filetool.sh -b Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz\ Done. tc@box:/opt$ sudo reboot
これで再起動したら、指定したipアドレスに固定される。
当然、sshでのログインも新たに固定されたアドレスで行うことになる。
再起動の前に、filetool.sh -bを打ち忘れたら、また最初からやり直しになるので注意。
bootlocal.shを設定。
tc@box:/opt$ vi bootlocal.sh
再起動、ログインして作業を継続。
bootlocal.shは、起動時に実行するコマンドを記載するファイル。
うちでは、下記のようなコマンドを追加で書き込んでいる。mpdの動作環境設定に関係してくる指示で、人によっては要らなかったり、もっと他の内容が望ましい場合もあるだろう。個々の環境や状況に合わせて設定することになる。
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
僕の場合、/home以下にNASのマウントポイントを作る気になれなかったので(間違ってfiletool.sh -bを打ったら、NASのデータをmicroSDに保存するようなことになりかねないので困ると思った)、/mnt以下に起動のたびに作ることにしたということ。
一番下の行のコマンドでNASをマウントさせるようにしている(/etc/fstabに記載するよりも簡単)。
敢えてコメントにしているのは、各種設定の途中ではマウントする必要がないから。一通り作業が終わってmpdの環境が完成したら、コメントアウトしてを外して、filetool.sh -bで保存し、再起動したらNASがマウントされているという塩梅。
各種ライブラリをインストール。
mpdをインストールしたり動かすためのライブラリなどをインストールする。
以下、コマンドのみを羅列。
tce-load -wi gcc.tcz glib2-dev.tcz ncurses-dev.tcz make.tcz automake.tcz compile-essentials.tcz squashfs-tools.tcz bash.tcz bc.tcz pkg-config-doc.tcz pkg-config.tcz tce-load -wi python-dev.tcz python-doc.tcz python.tcz boost-dev.tcz boost.tcz doxygen-doc.tcz doxygen.tcz tce-load -wi alsa.tcz alsa-config.tcz alsa-doc.tcz alsa-dev.tcz alsaequal.tcz alsa-locale.tcz
tce-load -wiというコマンドは、TCZライブラリから指定したソフトをダウンロード、インストールしてくれる。
上記のコマンドでmpdなどのインストールに必要な環境と、alsaをインストールした、つもり(本当は、不要なものが混じってるかもしれない)。
この時点でalsaの状況を確認したら下記のような感じ。
接続しているi2sDACの設定ができている。
tc@box:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: sndrpihifiberry [snd_rpi_hifiberry_dac], device 0: HifiBerry DAC HiFi pcm5102a-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 tc@box:~$ tc@box:~$ ls /opt alsa/ bootlocal.sh bootsync.sh eth0.sh shutdown.sh tcemirror
こんな感じで、/optにalsaのディレクトリができている。
つまり、この時点でfiletool.sh -bを打たずにシャットダウンしたら、このディレクトリが消えることになるのかな。詳細は調べてないから正確なことは言えないけど、いろいろとインストールしていく合間に適宜保存のコマンドを打つ必要はありそう。
続いてflacなどの再生デコーダー関係をインストール。コマンドのみ羅列。
tce-load -wi libsamplerate-dev.tcz libsamplerate-doc.tcz libsamplerate.tcz tce-load -wi flac-dev.tcz flac.tcz flac-doc.tcz libcue.tcz libcue-dev.tcz icu-dev.tcz icu.tcz tce-load -wi libmad.tcz mpg123.tcz lame-dev.tcz lame-doc.tcz lame.tcz faad2-dev.tcz faad2-doc.tcz faad2.tcz tce-load -wi libmpdclient-dev.tcz libmpdclient-doc.tcz libmpdclient.tcz
tc@box:~$ filetool.sh -b Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz\ Done. tc@box:~$
忘れず、保存、、、
mpdをインストール。
今回、以下の2通りのやりかたをまとめておく。
- (1)tce-load -wiコマンドでmpdをインストール。
- (2)ソースからコンパイルしmpdをインストール。
(1)tce-load -wiコマンドでmpdをインストール。
tc@box:~$ tce-load -wi mpd-doc.tcz mpd.tcz
上記コマンド一つでmpdのインストールが始まる。
しかし同時にインストールされるものが次々に出て来て、そんなに要るの?と思うほどだ。
インストール終了後は下記のような感じ。
tc@box:~$ mpd -V Music Player Daemon 0.19.9 Copyright (C) 2003-2007 Warren DukesCopyright (C) 2008-2014 Max Kellermann This is free software; see the source for copying conditions. There is NO warranty; not even MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Database plugins: simple proxy Storage plugins: local smbclient Neighbor plugins: smbclient Decoders plugins: [mad] mp3 mp2 [mpg123] mp3 [vorbis] ogg oga [oggflac] ogg oga [flac] flac [opus] opus ogg oga [sndfile] wav aiff aif au snd paf iff svx sf voc w64 pvf xi htk caf sd2 [dsdiff] dff [dsf] dsf [faad] aac [ffmpeg] 16sv 3g2 3gp 4xm 8svx aa3 aac ac3 afc aif aifc aiff al alaw amr anim apc ape asf atrac au aud avi avm2 avs bap bfi c93 cak cin cmv cpk daud dct divx dts dv dvd dxa eac3 film flac flc fli fll flx flv g726 gsm gxf iss m1v m2v m2t m2ts m4a m4b m4v mad mj2 mjpeg mjpg mka mkv mlp mm mmf mov mp+ mp1 mp2 mp3 mp4 mpc mpeg mpg mpga mpp mpu mve mvi mxf nc nsv nut nuv oga ogm ogv ogx oma ogg omg opus psp pva qcp qt r3d ra ram rl2 rm rmvb roq rpl rvc shn smk snd sol son spx str swf tgi tgq tgv thp ts tsp tta xa xvid uv uv2 vb vid vob voc vp6 vmd wav webm wma wmv wsaud wsvga wv wve [pcm] Output plugins: null fifo alsa ao oss pulse jack httpd recorder Encoder plugins: null vorbis opus lame twolame wave flac Archive plugins: [bz2] bz2 Input plugins: file alsa archive curl ffmpeg smbclient Playlist plugins: extm3u m3u pls xspf asx rss cue embcue Protocols: file:// http:// https:// gopher:// rtp:// rtsp:// rtmp:// rtmpt:// rtmps:// smb:// alsa:// tc@box:~$
ffmpegとかdsd関連もインストールされている。
mpdの設定を行っていく。mpd.confファイルはどこにあるんだろう。
デフォルトは~/.mpdconf、~/.mpd/mpd.conf、/etc/mpd.confなので、そこにないかと探しても見つからない。
findコマンドで探したら、下記にmpdconf.exampleがみつかった。
/usr/local/share/doc/mpd/mpdconf.example
/tmp/tcloop/mpd-doc/usr/local/share/doc/mpd/mpdconf.example
これらをコピーして使うよりか、viで設定ファイルを作って、どこかから設定をコピペしたほうが簡単だと思う。
記載例は後述。
(2)ソースからコンパイルしmpdをインストール。
tc@box:~$ wget https://www.musicpd.org/download/mpd/0.19/mpd-0.19.9.tar.xz tc@box:~$ xz -dv mpd-0.19* tc@box:~$ tar -xf mpd-0.19* tc@box:~$ cd mpd-0.19* tc@box:~/mpd-0.19.9$ tc@box:~/mpd-0.19.9$ ./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.9$
今回、ダウンロードしたmpdは0.19.9。これはTCZで用意されているmpdに合わせた。
ソースからコンパイルするメリットは、システムを小さくできることだ。
1分かそこらでconfigure終了。うまく行ったかに見えた。
tc@box:~/mpd-0.19.9$ make -j4 (ひたすら文字が並ぶ) src/decoder/plugins/MadDecoderPlugin.cxx:37:17: fatal error: mad.h: No such file or directory compilation terminated. Makefile:7346: recipe for target 'src/decoder/plugins/libdecoder_a-MadDecoderPlugin.o' failed
上記のように、エラーでmake終了。configureが通ったのにmakeで止まるという経験は初めてだ。
libmadをアンインストールしないといけないらしい。
tc@box:~/mpd-0.19.9$ cd /mnt/*2/tce tc@box:/mnt/mmcblk0p2/tce$ ls mydata.tgz onboot.lst ondemand/ optional/ tc@box:/mnt/mmcblk0p2/tce$ vi onboot.lst tc@box:~$ sudo reboot tc@box:~$ cd /mnt/*2/tce tc@box:/mnt/mmcblk0p2/tce$ rm optional/libmad.tcz* rm: remove 'optional/libmad.tcz'? y rm: remove 'optional/libmad.tcz.md5.txt'? y tc@box:/mnt/mmcblk0p2/tce$ sudo reboot
/mnt/mmcblk0p2/tce/onboot.lstの記載から、libmad.tczの1行を削除し保存(ここはfiletool.sh -bを使わなくてもいい)、reboot。
さらに、/mnt/mmcblk0p2/tce/optionalから、libmad.tcz関連を削除して、reboot。
これでアンインストールできる。
アンインストールしてconfigureしてmakeしたら、エラーなく終了。
tc@box:~/mpd-0.19.9$ make -j4 (ひたすら文字が並び10分で完了) tc@box:~/mpd-0.19.9$ mkdir ../mpd tc@box:~/mpd-0.19.9$ sudo make DESTDIR=../mpd install tc@box:~/mpd-0.19.9$ cd tc@box:~$ mksquashfs mpd mpd-0.19.9.tcz tc@box:~$ md5sum mpd-0.19.9.tcz > mpd-0.19.9.tcz.md5.txt tc@box:~$ ls mpd/ mpd-0.19.9.tar mpd-0.19.9.tcz.md5.txt mpd-0.19.9/ mpd-0.19.9.tcz tc@box:~$ sudo mv *tcz* /mnt/*2/tce/optional tc@box:~$ ls mpd/ mpd-0.19.9/ mpd-0.19.9.tar tc@box:~$ tc@box:~$ sudo vi /mnt/*2/tce/onboot.lst
tiny core linux系では、ひとまとめにインストールしてtczファイルを作って管理する。
今回の場合、コンパイルしたデータからtczファイルとtcz.md5.txtファイルを作る。
これらのファイルを/mnt/mmcblk0p2/tce/optionalディレクトリに移動させて、onboot.lstの末尾に、mpd-0.19.9.tczと記載を追記する。
これでインストール終了。
しかしlibmadをアンインストールしたので、mp3は聞けない。
ところで、GCCの最適化をしてコンパイルしmpdをインストールする方法がある。
最適化について参考にさせていただいたサイトは下記のとおり。
みみず工房
http://mimizukobo.sakura.ne.jp/index.html
2017/10/21(PC_Audio) gccの最適化オプションnew_western_elec
http://nw-electric.way-nifty.com/blog/2016/08/mpdpi-2-pi-3-5a.html
MPDをソースコードからコンパイルしてPi 2 Pi 3に最適化する方法
僕には最適化について知識はないので、上記サイトでPi2とPi3用に紹介されているコマンドを打った。
./configure CFLAGS="-O2 -march=armv7-a -mtune=cortex-a7 \ -mfpu=neon-vfpv4 -mfloat-abi=hard" \ CXXFLAGS="-O2 -march=armv7-a -mtune=cortex-a7 \ -mfpu=neon-vfpv4 -mfloat-abi=hard" \ --with-systemdsystemunitdir=/lib/systemd/system
これも一見、問題なくconfigure終了したかに見えたけど、やはりmakeの段階でエラーになった。
libmadをアンインストールして再度configureしたら、make、installできた。
本当はalsaなどのインストールもソースから最適化してコンパイルを試みるべきだったかもしれないけど見送った。ちょっとそこまで試行錯誤する余裕がなくて、、、
mpdの設定を行っていく。mpd.confファイルが必要だ。
tc@box:~$ ls mpd/ mpd-0.19.9/ mpd-0.19.9.tar tc@box:~$ ls m*9/doc developer.xml doxygen.conf.in mpd.conf.5 protocol.xml doxygen.conf mpd.1 mpdconf.example user.xml tc@box:~$ cp m*9/doc/mpdconf.example .mpdconf
ダウンロード、解凍したファイルの中にmpdconf.exampleがある。
それを、/home/tcディレクトリにコピーして.mpdconfを作り編集。ここに置くのが一番簡単かな。
しかし素のmpdconf.exampleを編集するより、viで作って既存のmpdサーバーから設定をコピペして編集したほうがいろいろ早いだろうと思う。
この時点で、インストールの作業場として使ったmpdディレクトリや落として解凍したファイルなどが残っている。
これらは、もう要らないので削除していい。
残していたら、filetool.sh -bに際して無駄に時間がかかる。
mpd.confのdb_fileの設定場所によっては、保存するのにfiletool.sh -bを使うことになるので、削除しておいたほうが快適になる。
tc@box:~$ ls mpd/ mpd-0.19.9/ mpd-0.19.9.tar tc@box:~$ sudo rm -rf mpd*
.mpdconfの編集例。
tc@box:~$ vi .mpdconf 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" #auto_update_depth "3" audio_output { type "alsa" name "My ALSA Device" device "hw:0,0" # optional mixer_type "software" # optional ## mixer_device "default" # optional ## mixer_control "PCM" # optional ## mixer_index "0" # optional } samplerate_converter "Fastest Sinc Interpolator" audio_buffer_size "8192" buffer_before_play "20%" audio_output_format "192000:24:2" filesystem_charset "UTF-8" id3v1_encoding "ISO-8859-1"
上記は一部で一例。各自で自分の環境やニーズに合わせて編集する必要がある。
tc@box:~$ mkdir .mpd tc@box:~$ mkdir .mpd/playlists
.mpdconfのplaylist_directoryなどの設定に合わせて、.mpdディレクトリなどコマンドで作成。
mpdを起動しmpd clientでアクセスする。
sshからmpdコマンドで起動。最初の起動に際してはライブラリファイルがないと警告がでるけど無視していい。
好みのmpd clientでアクセスして、コントロール。
ざっとこんなところ。 mpdのインストール方法によって音の違いを比較しようかとも思ってたんだけど、そのうち、余裕があるときに。
Mar 13, 2017
mpdからmpdにflacをHTTPストリーミング機能で配信する
前回、mpdをhttpサーバーにしてflacをストリーミングするというエントリーを上げた。
vlcかmplayerじゃないと聴けないみたいと書いたんだけど、mpdでストリーミングを受けることができた。
内容は薄いので前エントリーへの追記で済まそうかとも考えたけど、新規にした。
使用したのは、サーバーに日常使いのhp 6730b Fedora25にインストールしたmpd。
レンダラーはraspberry pi2にインストールしたMoode Audio。
Moode Audioは384kHzへのアップサンプリング出力をi2sDACに送ることが可能。最近これにlibsamplerateをインストールしてBGM用に使っている。ちゃんと音質を確認したわけでは無いけど、いい感じじゃないかな。
普段はNASをマウントして使っているんだけど、httpストリーミングではどうかという考えもあった。
まず普段使いの6730bの、.mpdconfを設定。
audio_output { type "httpd" name "My HTTP Stream" encoder "flac" # optional, vorbis or lame # port "8000" # bind_to_address "0.0.0.0" # optional, IPv4 or IPv6 ## quality "5.0" # do not define if bitrate is defined # bitrate "128" # do not define if quality is defined #format "44100:16:2" # max_clients "0" # optional 0=no limit }
こんな感じで。
ちなみに"flac"が"wave"だと上手くいかなかった。もとのファイルがflacだからなのかどうか分からないが。
操作は普通にmpdクライアントから行う。
次にレンダラー。
参考にしたのは下記、Arch Linuxのサイトの説明。
https://wiki.archlinuxjp.org/index.php/Icecast_%E3%81%AB%E3%82%88%E3%82%8B%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC%E3%83%9F%E3%83%B3%E3%82%B0#MPD
https://wiki.archlinuxjp.org/index.php/Music_Player_Daemon/Tips_and_tricks#HTTP_.E3.82.B9.E3.83.88.E3.83.AA.E3.83.BC.E3.83.9F.E3.83.B3.E3.82.B0
使うのは、既にインストールされている「mpc」。
これはcuiモードで使用するクライアント。
当初はpiCore7でやろうと思ったんだけど、考えてみたらmpcをインストールしていない。
そこでインストールというのも面倒になってraspbianの使用も考えたけど、ありもののMoodeを使うことにした。
Moode Audioにsshでログイン。ユーザーはpi、パスはraspberry。
サーバーの6730bを操作してストリーミングを開始しておく。
Moode Audioのsshに戻って以下のコマンドを打つと数秒待って音が出始める。
mpc add http://192.168.1.24:8000/mpd.flac | mpc play
http://192.168.1.24 というのは6730bのアドレス。8000はポート番号で変更設定していなければこれで固定。
「mpc add http://192.168.1.24:8000/mpd.flac」だけだと、ストリーミングがmpdのplaylistに登録されるだけで音はでない。
パイプ「|」を使って「mpc play」を追加することで、再生される。
「mpc play」を続けて打っても別に構わないんだけど、1行のコマンドで済む方がいいよね。
ちなみにmpcのマニュアルは「man mpc」でも読めるけど以下のリンクにもある。
https://linux.die.net/man/1/mpc
マニュアルを読んで、今回初めて上手く使えたように思う。
要するに普段使っているncmpcppでしていることをコマンドでやるソフトということ。
ncmpcppは端末上で動くけど、実際の操作感覚はかなりguiな感じで、マウスも時には使ってみたりと感覚的に使える。
mpcはそれを剥ぎ取った感じで、すべてcuiだ。mpcを使いやすくしたのがncmpcppという感じだ。ncmpcppはマニュアルを熟読しなくても使える。まあ、操作キーの確認ぐらいは必要だけど。
さて、音はめでたく出たのだけど、音が出るまで数秒以上かかるのと、どうも安定しない。
ぽつぽつ途切れる感じだし音色もよくない。
top画面で見た限りでは、Moodeの負担が増えたようにも見えないんだけど、どこかで上手くいかないんだろう。
結局、Moodeの設定でアップサンプリングを止めたら解消した。
コマンドを打つとすぐに音が出るし(出音の直後は少しだけ不安定だけど)、途切れるような感じもない。
音質の比較はしていないけど、まあ、現時点ですごく良くなったという驚きは感じない。普通にいい音だね、といいう感じだ。
upnpでは普通にアップサンプリング出来ていたのでそういうものだと思っていたんだけど、httpストリーミング受信では勝手が違うらしい。upmpdcliのような連携して補助するソフトの有無によるのかな。
以上、備忘録。