Current filter: »minidlna« (Click tag to exclude it or click a conjunction to switch them.)
Jan 02, 2017
VolumioをUPnP/DLNAで繋いでみた（１月４日、追記あり）
あらためて明けましておめでとうございます。
昨年末、UPnP/DLNAは難しいというエントリを上げたんだけど、早々にvolumio1.55を2台、upnpで繋げてしまった。
音質はノイズが多いと書いたけど、i2sDACに出力するようにしたら、かなり解消した。ras piのイヤホン出力で聴いてノイズが多いと思ったけどi2sは影響が少ない様子だ。
ちなみに使ってるのは、raspberry pi B+。
ということで、メモ書きにエントリに書いておく。
早々にあちこちに気付いたこと、足りないことを追記した。つうか、このエントリーそのまま読んでも何をしたのか分からない。新しいエントリーでとも思ったけど、追記したほうがいいと思った。
メインのコンポに継いでみたりしたけど、意外に悪くない感じだ。
もっと扱いやすかったらいいんだけど。
まず、前回のエントリの流れで記載。
ras pi、volumioを2つ用意。両方、/etc/minidlna.confを編集、前回のエントリーの最初のほうに書いた通り。
1つをサーバーに、もう1つをレンダラーに割り当てる。
サーバーの設定は、UPNP\DLNA IndexingとDLNA Library ServerをON。レンダラーの設定は、UPNP ControlとUPNP\DLNA IndexingをON。
サーバーの設定について、前のエントリーを引用。
次に、sshでrootでログイン。パスはvolumio。
/etc/minidlna.confを編集。
#media_dir=/var/lib/mpd/music
上記の行のコメントアウトを外す。
dlnaサーバを再起動するのに以下のコマンドを打つ。
service minidlna restartこれでvolumio1.55がDLNA serverになる。
もしもvolumioにマウントしたNASのデータだけをupnpクライアントに認識させたかったら、/etc/minidlna.confを以下のよう編集したらいい。
media_dir=/var/lib/mpd/music/NAS
で、今回はDLNAサーバーにNASをマウントしてレンダラーに送る。
サーバー化したvolumioにwebブラウザでアクセスし、音楽データベースであるNASのディレクトリをマウントしていく。
ということなんだけど、ここで問題は、DLNAでは大量のファイルを扱えないし（どうも10000程度が限界らしい？）、原因は分からないが認識できないファイルも出るらしいということ。
当初、NAS上の音楽データ用ディレクトリをそのままvolumioにマウント。
そしてminiDLNAのデータベースを構築しようとしたら（うちのデータは音声ファイルとカバーアート画像ファイルあわせたら、ゆうに10000を超える）、ハングした。その経過は前のエントリに書いたとおり。
そこで対策として、登録する音声ファイルを減らすために、音楽データ用ディレクトリの子ディレクトリを、一つ一つマウントしていった。
次に、画像ファイルをDLNAで管理する必要はなく音声ファイルだけ認識してくれたらいいので、/etc/minidlna.confの記載は以下の様に書き直した。これで音声ファイルのみ管理するようになる。
media_dir=A,/var/lib/mpd/music/NAS
で、複数の子ディレクトリをvolumioにマウントして、トータルファイル数1600強（音楽ファイルのみ）をminiDLNAのデータベースに登録してみたら、数10分かかる。
上記、前回エントリの引用で、service minidlna restart とコマンドを打つと書いてある。
打って数分待つと「 ok 」と表示されて、もういいのかな、と思うんだけど、実はこの時点でtopコマンドを打つと、minidlnaがCPUの50%以上を食って大忙しにしていたりする。
これが仕事を終えるまでは次のステップには進めない、ということ。
volumioにNASをマウントし、volumioのデータベースを構築するだけなら、ファイル数が相当多くても正確に取り込んでくれて登録ミスなどはない（問題を生じるのはこっちが何か間違えているときだけだ）。一方、DLNAのほうは、ファイル数が少なくてもデータベースへの取り込みミスがしばしばあり、原因がはっきりしない。
現時点では、そういうものと思うしかない。
さて、volumioDLNAサーバーのminidlnaが仕事を止めたのを、sshのtop画面で確認し、次はレンダラーだ。
レンダラーのvolumioにwebブラウザ、ncmpcpp、sshでアクセスしてみる。
webブラウザではUPNPは表示されないようなので、これ以上の操作はできない。
ncmpcppからレンダラーのvolumioにアクセスしたら、UPNPと表示されている。そこを選択すると、upnpサーバーのvolumioが表示される。
上の図では「root」と表示されているが「minidlna」と表示されるのが通常運用らしい。何回か再起動するうちに、今はうちでもそう表示されている。どうしたらそうなるかというのは、実はよく分からないんだけど、、、
あとは階層をたどって表示される音源を選択し再生を指示したら、レンダラーのvolumioから音が出る。
ということなんだけど、実はサーバー側でデータベースが再構築されていた場合、レンダラー側はこれに自動的に合わせてはくれない。レンダラーのほうで登録されているmpdのデータベースと、サーバーのデータベースをすり合わせる必要がある。
つまり、レンダラーのncmpcpp画面には、レンダラー側が作ったデータベースが表示されているということ。
サーバーの実体が表示されてるわけではないのだ。
ncmpcppのブラウズ画面で「u」キーを打つとアップデートできる。
サーバー側のminidlnaとかと、レンダラー側のdjmount、mpdとかで、データのやり取りを行い再構築が行われる。
これにも数10分かかる。
仕事が終わるのを確認するためには、sshでtopを打ち監視しておく必要がある。上級者なら仕事が終わったらビープ音を出すとかスクリプトを書けるんだろうけど、僕には無理。
top画面が落ち着いたら、お疲れ様です。
レンダラーvolumioからncmpcppを使って音が出せるはず。
そういえば、まだあった。
もしも、volumioを何かの事情でシャットダウンした場合、起動したらデータベースの再構築をしないと音が出ないみたいだ。
一旦切れたサーバーとレンダラーの繋がりを戻す必要があるらしい。再構築以外の手段はないのかな、、、
前回のエントリー追記で、問題は音にノイズが多いことと、インデックスの更新に手間がかかることと書いた。
まるでチューニングが合ってないラジオのように、ノイズが再生音に乗っている。
インデックスの問題はしょうがないとして、ノイズはなんとかできないだろうかと考えた。Phile webの記事では使えると書いてるんだし。
まず、サーバー側のmpdを止めてみた。
upnpサーバーなんだからmpdは要らないはずだ。sshからmpd --killで止める。問題なくサーバーとして機能している。しかしこうしたらwebブラウザからはアクセスできなくなる。
しかしさほどノイズは減らない。
追記。そういうわけで、その後はmpdを動かしている。
そのほうがNASをマウント、アンマウントするのにwebブラウザを使えて便利だから。
次にレンダラーの方、mpdのAudio buffer sizeとBuffer before playを増やしてみる。多少の違いはあるようだけど、やはりノイズは多い。
やっぱりイヤホン出力が良くないのかな、と考えてi2sDACを試すことにした。
結局、これで再生音に乗っかるノイズは消えた。これなら使えるレベルかな。
しかし試聴に使用したのはポータブルのアクティブスピーカー。本格的なオーディオシステムでの実力は不明だ。
ノイズは何とかなったとして、インデックスの問題が残っている。これが解消しないと実用に耐えないと思う。
これはUPnP/DLNAサーバーソフトの完成度によって決まると思うので、本気でUPnP/DLNAで音楽再生しようと思ったら、あれこれ探したり試行錯誤していくしかないだろうなと思う。
MinimServerのセッティングがうまくいかなかったのは、ちょっと無念。
個人的には、メモリ再生の方がよほど簡単で楽だと思ってしまった、この1ヶ月だった。
追記だ。
三が日の三日目使ってメインシステムで試聴した。
RCAケーブルを抜き差しして、NASマウント音源のvolumioと比較。
意外なことに、悪くない。
というか、NASマウント音源のvolumioよりいいような気がする。
UPnP音源のvolumio、i2sDACの音は、涼しげで見通しがいい気がする。いい意味で軽く、きめ細かくて陰影が深い。比べたらNASマウントのほうが平板な音に聞こえる。
UPnPを使う意味は、あるのかな、、、
メモリ再生との比較は出来ていないけど、、、
なんというか、、、聴いてみたら、なんとかなるもんならしてみたい、と思える音が出てしまった気がする。
でも、日常使用レベルにするにはそれなりのスキルは必要になりそう、という感じかな。
