Download v0.8.1 Image ZIP (351MB)symphonic-mpdをインストールしたんですが
何をどうやってもHPの説明どうりブラウザではつながらないので
sshで...何とか繋がるんですが上手く設定出来ない様で
sambaのcifs mountでmusicディレクトリー下の曲名が見えないためても足も出ません((泣))
もちろんアップデートも出来ないのですが何かヒントはないですか?
sshで余計なことはしないで「ブラウザでsmpd.localを開き、設定画面でNASのパス、ユーザ、パスワードを設定してSAVEボタンを押下する。」すれば、上手くいくはずですが。
今の状態でSSHで
df
するとどうなりますか。
🎧 symphonic-mpd
pi@smpd:~ $ df
Filesystem Size Used Avail Use% Mounted on
/dev/root 944M 928M 0 100% /
devtmpfs 490M 0 490M 0% /dev
tmpfs 491M 0 491M 0% /dev/shm
tmpfs 491M 13M 478M 3% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 491M 0 491M 0% /sys/fs/cgroup
tmpfs 32M 0 32M 0% /var/log
/dev/mmcblk0p1 42M 17M 25M 40% /boot
//192.168.11.3/music 917G 892G 25G 98% /var/lib/mpd/music
tmpfs 650M 0 650M 0% /var/lib/mpd/music/RAM
tmpfs 99M 0 99M 0% /run/user/1000
なまじ、MPDの設定方法を知っていると嵌まるワナです(^^;;;。
//192.168.11.3/music 917G 892G 25G 98% /var/lib/mpd/music
が問題です。
//mintc.local/music 3.7T 2.8T 884G 77% /var/lib/mpd/music/NAS
とならないとまずいです。
「ブラウザでsmpd.localを開き」-> 画面右上端の歯車みたいなボタンを押す->
settingsをクリック -> NAS Setting
でNASの設定をおこなって下さい。パスはネットワーク名も使えます(...localってやつ)。あと、いまの状況は/var/lib/mpd/musicが変なことになっていますからrmdirしないとまずいです。というか、シンプルには、もう一度SDカードの作り直しから再開した方がいいです。
それから、/rootに殆ど空きがないですから、拡張しておいた方がいいです。詳しくは僕の最新の記事を参照して下さい。
挑戦しましたがやはりsmpd.localにアクセスできません。
192.168.11.16でもブラウザではアクセス出来ません。
ssh -l pi smpd.local or ssh -l pi 192.168.11.16 は可能なのに??
root@smpd:/lib/systemd/system# lsof -i:80
root@smpd:/lib/systemd/system# lsof -i:8080
サーバーは何だろう??
apache2 とか lighttpd は動作していないようですが?
横から失礼します。
とりあえずmpdとymapdが起動しているかどうかを確認された方が良いんじゃないかと思います。
とりあえずsshでログインしてroot権限でympdを
実行するとHPの表示が出来るようになります。
その後にsambaの設定をしましたが
相変わらずフォルダーは見えて曲が見えません??
dfは
//192.168.11.3/music 917G 892G 25G 98% /var/lib/mpd/music/NAS
調査の結果、この問題はsambaサーバー側の曲のパーミッションの問題でしたm(_ _)m
Failed to restart ympd.service: Unit ympd.service failed to load: Invalid argument. See system logs and 'systemctl status ympd.service' for details.
systemctlでympdの起動に失敗している様です。
/etc/rc.localで起動してるのかな...
とりあえずympdを諦めて
# for any other MPD Client
port "6600"
bind_to_address "any"
ここを有効にして愛用のquimupで音出し成功しました。
アドバイスありがとうございましたm(_ _)m
ところでオンラインアップデートと思われるSWが押せないのは?
何でだろうか...まだ先が長そう('~`;)
パパリウスさんのブログ
http://community.phileweb.com/mypage/entry/4787/20190412/62219/#cmTop" target="_blank">http://community.phileweb.com/mypage/entry/4787/20190412/62219/#cmTop
のコメント欄にここのアドレスを書き込み、状況を簡単に報告しました。向こうもご覧ください。
恐らく自分の環境の何かの設定が原因で
標準的な操作が出来ない状態なのかと考えています。
その上で現状を報告させていただきます。
※情報集約という事で向こう側にも同じ内容で書き込みました。
1.現状RaspberryPiの電源SWをONにしてLED消灯後
sshでログインして
# ympd
のコマンドを手動で実行すると
Running as unit run-16457.service.
connection is nothing. stop ympd.
となりアクセス待状態となります。
2.自分の環境ではhttp://smpd.local" target="_blank">http://smpd.localではアクセス出来ません。(firefox)
http://smpd.local:8080/" target="_blank">http://smpd.local:8080/ で何回かアクセスすると接続出来ます。
というわけで
たかじんさんのDAC基板が今のところ
最高の組み合わせだと思うけど
皆んながやっているんで(笑)
I2S信号取り出しとHDMI変換基板を取り付けて
色々接続して楽しもうかと考えています。
天邪鬼...
何と、5年前(2014年)にこの掲示板で「RasPiからのI2S直接入力」とか「BBBのI2S interface」とかいった議論をしています(多分、グローバルにみて世界最先端ですね。komaさんのコメントも発見)。検索機能で探すことが出来ますので、よろしければどうぞ。当時ご活躍だったsyuさんはお元気なのですかね。
なんというタイトルだとお考えの方も多いと思いますが、ちょっと過激に。
JPLAYfemtoはJRIVERでコントロールするのが一番だと言う意見が多いですね。僕はJRIVERユーザではないので、この意見に対して適切なコメント出来ないのですが、「アルバムの整理がきちんと出来たライブラリを持っていれば、その通りかな」と思います。
というわけで、このスレッドは怨念(^^;;;)のJPLAY-JRIVER対決に決着をつけるべく、この二つを組み合わせてベストの音質と操作性を求めるためのテクニカルな意見交換の場にしたいと思います。
まず、とっかかりに、「JPLAY FEMTO」スレッドでmoriさんの「jriver24をコントロールポイントとして、レンダラーにfemto、サーバーにfemtoserverを選択して、普通に再生できています」という質問(No6020)に対して、僕の回答(No6021)「JRiverを別のPCに置くと、femtoServerの中身が見えなくなります」というのは誤りというご報告から。
JRiverを別のPCに置いても、femtoServerの中身が見えるし、再生することも出来ますね。こうすると、シングルPC側ではJRiverを動きませんので、オーディオ的には有利になりそうです。
やり方ですが、JRiverの使い方には慣れていないので、これで正しいのか、皆様方に確認して頂きたいと思います。よろしくお願いします。
①JRiverをインストール(僕の持っているのは21.0です)。
②Tools -> Options -> Media Network
③Use Media Network to share this library and enableb DLNA をマーク。Access Key(KzySeN)を入力。
④これで、JPLAYfemtoとJPLAYfemtoServerが立ち上がっていれば、それぞれPlayerとPlaying fromから見えるようになるはずです。
⑤見えるようになったJPLAYfemtoServerをクリック、Load Libraryをクリック。DLNAフォーマットがおかしいとか文句をいってくるが、無視してOK。ロードさせる。
⑥ロードが完了したJPLAYfemtoServerを右クリック。Media Importというダイアログが表示されるので、Import a single folderを選択、Nextをクリック。Please select the folder to searchにfemtoServerで使用しているNAS or Diskを指定する(NASはホスト名を使って指定できます)。Finishをクリック。
後は、ひたすら待つ。僕の場合はNASがバカでかい(4T)ので、36分04秒かかりました。
終了すると、めでたく、femtoServerが普通(?)のDLNAサーバのようにアルバム名やアーティスト名で取り扱えるようになります。
⑥の部分のやり方がよく分かっていなかったのですよね。moriさん、失礼しました。訂正してお詫びいたします。
初めまして。
タイトルに惹かれどの様な内容なのか拝見させて頂きました。
私はfemto serverのNAS設定が上手くいかずにJMCに流された者です。一度同じ事を実行しましたが、ライブラリ設定でアラートが出てこれはダメだと諦めていました。
今回yo様の方法でfemto serverにライブラリを設定出来て音出しにも成功致しました。素晴らしいです。
player>audio pathを見るとinput もoutput もnot using JRiver audio engineと表示されておりますのでfemto serverが稼働して音が出ている事に間違い有りません。音も駄耳ですが透明感が増した様に思います。
また、JRemoteからもコントロール出来ました。完璧です。私にとっては「有難やJMC」です。
お詫びだなんて、とんでもありません。本件については、意外に情報が無くて、不安でしたが、お陰様で安心できました。
Jriverをコントロールポイントにすると、アルバム名やアーティスト名で扱える他、プレイリストも簡単にでき、Jremoteも使えて、操作性は大変よろしいかと思います。
新しいスレッドの立ち上げたいへんありがとうございました。
yoさんの実践された方法で普通にやりますと確かに読み込めますしタグ情報からたどる選曲ができるのですが、実はここに疑問があったのです。まてよ、、何か変だな、どうしてこれができるのかと。(FEMTOサーバーはタグ情報を提供しない(推測)はずなので。またminim serverでは読み込み時にSingle Folder選択は不要のはず、、、)
この状態でJRMCに音源ファイルの情報を表示させると、指定したフォルダーのファイル名を表示してきます。(本来ここは同一シングルPCであってもサーバーのIPアドレスとサーバー名がPrefixとなるはずです。minim serverではそうなります)
で、いろいろと確認してみたのですが、JRMCのメディアネットワーク設定で「DLNAサーバーを有効」としていれば再生可能ですが、これを停止させると再生できなくなります。
minim server利用時は当然ながらDLNAサーバー機能を停止しても再生できますが、FEMTOサーバーでは不可です。ということは、上記の音源情報などとも照らし合わせると、JRMCのサーバー機能が生きていてこれで再生してるのではないか、と疑っています。(JRemoteからは現在のサーバーが何かは見えません。JRMC上は確かにFEMTOサーバーが選択されていますが)
また、DLNAサーバー機能を停止した状態でFEMTOサーバーから再生させようとすると、単に再生できないだけではなく、JPLAY FEMTO全体がおかしくなってしまい、再インストールしないと以後何の再生もしなくなります。
現在のところこの程度で問題の切り分けもできておらず、正直五里霧中です。
いやこれでいいんだよ、という当方の勘違いなのかもしれませんし、あるいはJRMCとJPLAYの間にはやはり深くて暗い河があるのか、、、皆様の貴重なアドバイスをお待ちしておりますので、よろしくお願いいたします。
(注記)
本件の狙いは、FEMTOサーバーでは普通フォルダー検索しかできないという制約をクリアーし、使い勝手とFMETOサーバーの音質的メリットの良いとこ取りができるのでは、というものです。
私がplayer>audioを見て確認した内容はJriver をplayerとした場合の経路でした。
ゴンザエモンが仰る通りJriverがserverとして動いている可能性も考えられました。そこで、services & plug-inのmedia networkの項目を確認したところ、Soucesの項目がfemto serverのIPアドレスになっておりました。Jriver serverの場合はJriverをインストールしたPCのIPアドレスとなります。
と言うことは、femto serverが働いていると考えられます。
また、間違っていたら申し訳ございません。
早速のアドバイス、深謝です。
ご指摘の項目当方も確認してみましたが、同一PCでのテストではIPアドレスが同じなので、これでは判別できませんでした。
もう少しいろいろとやってみますね。
なお、メディアネットワークの詳細の項目にあります「DLNAサーバー」機能のチェックを外しても問題なく再生できますでしょうか?
また、JRMC起動時に以下のようなメッセージはでませんか?
選択されたDLNAサーバーからファイルを回収する時に問題が起こりました。
検索する時に接続しているサーバー名とその稼働状況が正常かを確認してください。
問題を解決し再度読み込みをするまでに、ライブラリが未完成の可能性があります。
上記は、FEMTOサーバーのロード時にも出ますし、再生のためには音源場所を指定してインポートが必要になります(ちなみにMinim Serverではそもそもインポートが不要です)。総合的に考えると
「JRMCがメディアサーバーの機能によって、FEMTOレンダラにPUSH再生している」
のでは? と思えてしまうのです。
皆様、是非お知恵を拝借させてください。
ちょっと気になって早起きしてしまいました(笑)ので、実験してみました。
1.JRMC上のFEMTOサーバーへの(強制)インポートを別のテスト用音源にしてみました。
2.この結果、JRMC/JRemoteではテスト用の音源が見えてきます。(再生可能)
3、mconnectから確認すると、
(1)JRMCのメディアサーバーが生きていて、
(2)選曲すればこのテスト用音源が再生されます
4.FEMTOサーバーで指定していたはずの音源は見えません。
5.JRMCのDLNAサーバー機能をオフるとmconnectからJRMCメディアサーバーが見えなくなります。
minim serverでは
1.ライブラリに接続した段階で中身が見える(インポート不要)
2.DLNAサーバー機能をオフしても、JRMC/JRemoteで再生できる。
という状況です。FEMTOサーバーとminim serverではDLNAサーバーとしての仕様が違うのかもしれませんが、まだすっきりできていません。
テスト用音源に対する動きから単純にたどれば、やはりJRMCがメディアサーバーとして音源を読み取り、FEMTOレンダラにPUSHしているようにも見えます。(ライブラリの名前はFEMTOサーバーにはなっていますが)
お尋ね頂いていたのに、気が付かなくて、申し訳ありませんでした。その件については、このスレッドにて解決済みですね。このスレッドでのお尋ね、御疑問の点については、私も同様の思いを持っていました。まず、DLNAサーバのチェックを外すと再生できない、例のメッセージが出る件は、同じ状況です。
私も、JriverのDNLAサーバである、main libraryとfemtoserver の内容に差異を設けて、Jremoteでの表示を試してみましたところ、PCでmain libraryを選択しているとJremoteもmain libraryの内容を、PCでfemtoserverを選択しているとJremoteもfemtoserverの内容を表示しました。
素人考えですが、DLNAコントロールポイントからは、JriverのDNLAサーバ機能をオンにしないとDNLAサーバであるmain libraryもfemtoserverも見えなくなるのではないでしょうか。
僕が確認したことを書き込みますが、その前に確認のために使用した環境について。
サーバ : Atom機を使った自作NAS Linux Mint Samba
音楽PC : i5 3470専用機、OS Window10 Home 1803版、JPLAYの最新版をインストール
コントロールPC : MS Surfaceノート(常用しているノートです)、OS Window10 Pro 1803版、JRiverの最新版をインストール
コントロール端末 : Androidタブレット BubbleUPNP
DAC : SoulNote D-2 USB接続
ネットワーク構成は僕のサイトを参考にして下さい。
http://mimizukobo.sakura.ne.jp/articles/articles023.html#001" target="_blank">http://mimizukobo.sakura.ne.jp/articles/articles023.html#001
サーバ、コントロールポイント、レンダラー全て独立させ、コントール部分は更に操作(Andeoid)と管理(というのかな、MS Surfaceノート)という形で分離しているのが特徴です。JRiverに詳しくないので、ひたすら外側から攻めて、確かめようということです。
この構成で、僕の最初の書き込みの⑤⑥を行いました(前日の内容が保存されていなかったので)。
その後、Andoid端末BubbleDSで④を実施。
レンダラーはJPLAY FEMTO
サーバーはSurface(Generiv DLNA)
を選びます。
この時、BubbleDSのサーバーの選択ですが、選択肢は次のように表示されます。
Bubble Local and Cloud
Surface (Audiophile 24-bit DAC)[192.168.0.6]
Surface (Audiophile 24-bit DAC)[192.168.0.6]
Surface (Generic DLNA)
Surface .....@......
JPLAY femtoServer
MinimServer[mintc]
mintc: minidlna
一番上はBubbleをサーバとして使う時のローカルな接続のためなので無視。
2番目から4番目までがJRiverと接続してコントールするためのものなので、femtoServerと接続用らしい4番目を選択。
5番目はMSのMedia Player用なので無視。
6番目以降が自作NASのDLNAサーバとなります。
従って、6番目を選択すれば、普通にfemtoServerを使うことができます。
さて4番のGeneric DLNAを選択、再生させます。
ここで乱暴ですが、Surfaceノートで起動したJRiverを終了させます。
驚いたことに、再生は継続し、Bubbleの時間表示も更新され続けます。
曲の終わりまで来ると、Bubbleは次の曲に移ろうとしますが、再生は停止します。
ここでSurfaceノートで終了させたJRiverを起動します。
再び驚いたことに、再生が再開できます。
以下、同じことを何度も繰り返すことが出来ます。
いかがでしょうか。再生中はfemtoServerとJPLAYレンダラーが同期して動いていることは間違いないと思います。
念のため、自作PSツールで動作プログラムの負荷を、リソースモニターでネットワーク負荷を確認しましたが、ちゃんと動いているように見えました。
ありがとうございます。
何だか、「証明合戦」みたいになっちゃってますね。(これもまた楽しいかも、ですが、、、)
JRMC、JPLAYの内部仕様は当方も全く解りませんので結局状況証拠で追うしかないかもですが、謎だな~と思っているのは以下の3点です。
①JRMCの「DLNAサーバー機能」のオフ(注記)の件、minim server(とFEMTOレンダラ)での組み合わせではこれで動きますが、FEMTOサーバーの場合はここをオンにしてあげないと何故か動かないようです。
(注記)DLNAコントロールポイント機能のみオン
②FEMTOサーバーでは音源の「場所を指定して」のインポートがなぜ必要となるのか。(本来は不要? ここで明示的にインポートすることによって、名前はFEMTOサーバーのままでも実態はJRMCサーバー機能が肩代わりしている可能性はないか? 今朝の実験から全然関係ない音源もFEMTOサーバーの名称に紐付けできてしまうこともあって)
③FEMTOサーバーはタグ情報を提供していないはずなのに、JRMC上でなぜこれがハンドリングできるようになるのか。
この辺りを突き詰めて議論を噛み合わせる必要がありそうですね。
なお、コントロールポイントが途中停止しても、再生中の音楽は継続されるという経験がありますが、yoさんの実験ではJRMC本体を止めてしまっていますので、JRMCのDLNAサーバーも止まっているはずですよね。ここはminim serverのケースでも同様に止める実験ができそうなので、やってみます。(本日は出かけちゃいますので、明日以降となります)
重ねて皆様ありがとうございます。当方ケチをつけるつもりは毛頭なく、真にJRMC/JPLAYの連携ができているという望外の状況を確固たるものにしたいという意図ですので、この点ご理解をいただくとともに引き続きいろいろとご教授いただければ大変幸甚です。
---------------------------------
JPLAY日本語デスク
> yo さんへ
> 再生中にコントロール管理部分のMS SurfaceノートのJRiverを無理矢理終了させるという実験を
> 行ってみました。驚いたことに、再生は継続し、曲の終了部分でストップ。更に驚いたことに、
> この状態で終了させたJRiverを再起動したら、再生は再開しました。
JPLAY FEMTOレンダラーにバッファリングされているデータが再生され続けます。DLNAレンダラーは今再生中と次のトラックの情報を持っています。
Android端末上のBubbleUPnPをコントロール・ポイントとして再生を開始し、再生が始まったらWi-Fi接続を切ってください。再生は続きます。JPLAY FEMTOレンダラーは既に再生に必要なURLを知っているので、コントロール・ポイントが消滅しても影響はありません。
SoundgenicのTwonkyメディア・サーバーのライブライリーをJPLAY FEMTOレンダラーで鳴らしてみました。再生が始まってすぐにSoundgenicの再起動をかけます。再起動中は設定画面につながりませんが、再生は続いています。これは、再生データの先読みをしてある程度バッファーに蓄えているからです。これが尽きた時点でサーバーにアクセスできないと、当然再生は止ります。
JRMCでfemtoServerライブラリーのタグ情報が全て見えるようになるというのは、インポート時に別途音源ファイルの場所をユーザーに指定させて独立して読込んでいるからで、femtoServerのライブラリーから引出しているわけではありません。
それが証拠に、インポート時にDLANのフォーマット異常のようなメッセージがでるとお書きになっています。MinimServerのようなfemtoServer以外の「普通」のUPnPメディア・サーバーでは、JRiverが想定している方法でインポートできるので、エラーは出ません。しかし、femtoServerが持つ個々のファイルのURLは独自フォーマットのため、JRMCは読込みに失敗するわけです。
現時点でまだ理解できていない点が1つあります。JRMCのDLNAサーバーをオフにし、コントロール・ポイント機能だけを使う場合、MinimServerのライブラリーは見えてfemtoServerは見えないという点です。
DLNAの仕様に準拠したコントロール・ポイントであれば、両者で挙動が変ることはありません。従って、JRMCは独自仕様であると筋が通ります。どの部分が独自であるかは、当然開示されていません。
以上から、JRMCのDLNAサーバー機能をオンにしてJRMCのコントロール・ポイントでfemtoServerを指定した場合、実際はfemtoServerの名を語るJRMCのDLNAサーバーが動いているというのが当デスクの判断です。この仮説で矛盾点があれば、ぜひお知らせください。
このスレッドに関しては、例外としてyoさんの掲示板での引用をOKとしますから、引用はご自由になさってください。
これはJRMCを使わせないためでは無く、femtoServerを使っていると誤解する人が出てくるのを防ぐためです。そうしないと、femtoServerの本来の音質が正当に評価されなくなります。
---------------------------------
yo
> JPLAY日本語デスク さんへ
丁寧な解説ありがとうございます。とても参考になります。
10分以上かかる曲を再生してみれば、切り分けられるかなと考え、試してみました。
確かに、7~8分位で中断されますね。最初のバッファ読み取りで、その位のデータを読み込んでいるということでしょうか。
ちなみに同じことをminimserverで試したら、演奏は曲の終わりまで再生は継続しました。こちらはサーバとしてのminimserverの機能が正しく働いているということだと思います。
ということで、ご明察の通り、importで行う方法はJRiverのサーバー機能を使うことになり、問題有りのようですね。
直前のメッセージとこのメッセージをそのまま僕の掲示板に掲載しますので、よろしくお願いします。
残りの疑問点も引き続き、僕の掲示板で議論するつもりですので,よろしくです。
---------------------------------
ということです。残念ながら決着はつけそこなったようですが、まあいいかという感じですかね。
既に結論が出ているころで、かめレスで申し訳ありませんがyo様が外攻めていうことなので私は先に報告したDLNA serverの稼働を確認すると言う内攻めで検討してみました。
結論としては当初よりゴンザエモンさんが言わていた通り、「Jriver Media Center(JMC)母艦又はJRemoteからのJplay Femto Server(JFS)ライブラリ再生指示でJFSを飛び越して直接JMC母艦が指定されたファイルデータをJPlay Femto Player(JFP)に送り込んで楽曲が再生されている。」でした。
yo様のJMC上でのJFSにライブラリを登録する操作時のアラートおよびゴンザエモンさんが指摘されておられた起動時にJFSにライブラリの読み込み時のアラートとが出た時点でJMCは隠れてデータを送信する優等生になることまたは替え玉DLNAserver(全く関係ないServerアドレスが生成されたことが有った)を立てることを決意する。そして、JMCはユーザがJFSのデータからJFCで再生指示した時に如何にもユーザの指示通りに動いているかのように振る舞い再生する。
また、dualPCとJMCPCの構成ですが、再生途中でLANケーブルを抜いたところ約20秒間はそのまま再生を続け、後にこの約20秒間を1回だけリピートして停止しました。
活発な議論をいただき大変ありがとうございました。また日本語ヘルプデスクの分析情報の提供(ならびに掲載の許可)についても改めて各位に感謝申し上げます。
当方が希求していたJPLAY FEMTO/JRMCの「美しく理想的?」な連携はどうやら夢物語になってしまいそうですが、音質のJPLAY FEMTOと操作性のJRMCの良いとこどりは完全ではなくてもJRMCサーバー(+JRemote)とJPLAY FEMTOレンダラーの組み合わせで「結構イケル」という共通認識には至ったと思います。本音ではFEMTOサーバーの音質的な優位点も享受したいところなのですが、、、
なお、FEMTOサーバーからのロード時に「選択されたDLNAサーバーからファイルを回収する時に問題が起こりました。」という要となる部分の本質が突き止められればこれはブレークスルー出来そうな気もします。ただこの辺りは開発に携わっている方でないと仕様なのかそれ以外の問題なのか切り分けは難しいかもですね。JPLAYとJRMC、今回は深くて暗い河ではなくて、もう一息で渡れそうな浅瀬だと改めて認識いたしました。
私は、一抹の不安がありながらも、femtoserverからのストリーミングではないかと思っていたので、このような展開で、
驚きましたが、真実が分かって大変すっきりしました。皆様のご議論がなかったら、誤解したままだったと思います。ありがとうございました。
moriさん
今回のJriver Media Center(JMC)とJplay Femto(JF)との連携については期待を抱かせる様な誤った見解を発言してご迷惑をお掛けしました。
結論は残念な結果となりましたが、個人的には少しはJMCとJFの関係が理解出来ましたので良い経験となりました。
今回の検証を行うにあたり、JMCのDLNAサーバ機能を確認する目的で、このyo様の掲示板でも一世を風靡したlightMPD/upnpgwを久々に持ち出して比較していました。かめレスになってしまったのこの為です。
lightMPD/upnpgwとJFで一番大きく異なると感じたのは、データ送信にありました。
JRemoteまたはJMC母艦からの再生指示で
lightMPDにおいては、JMCのDLNAサーバが1曲分のデータを約20秒間でlightMPDに送り込み、その後はDLNAサーバ活動を休止する。次曲に移行る直前で、DLNAサーバは再開してまた1曲分のデータを約20秒間でlightMPDに送り込み休止する。これをプレイリストの終曲まで繰り返す。
一方、JFではDLNAサーバは延々とデータをJFアドレスに向かって送信を続ける。次曲に移行してもDLNAサーバはまたゼロからデータを送り続ける。これをプレイリストの終曲まで繰り返す。
lightMPD/upnpgwとDLNAサーバの連携過程は予想通りでしたが、JFとDLNAサーバの働きは意外でした。
このことから、ゴンザエモンさんの見解とは異なり、私はJMCとJplayの間には、なかなか超えられない深い溝があると感じました。
それでも私は、しばらくは使い勝手を優先させてJMCとJplayの連携で使ってみるつもりです。
DLNAプロトコルは500ドルを支払わないと開示されないので、詳細を知ることが出来ないのですが、再生中のデータの受け渡し方がある程度分かって面白かったです。渡し方はmotomoto さんが書かれている通りだと思います。
意外だったのは、JRiverのサーバが最初に5分以上のデータをまとめてレンダラー側に送っていたこと。flac圧縮しているとしても100MBを超えるデータ量になるはずで、まさかそんなことをしているなんて夢にも思いませんでした。ネットワーク速度を考えると、数秒で送れるわけだから、無理はないのですが、ビックリです。
可能性はJPLAY日本語デスクさんの
> 現時点でまだ理解できていない点が1つあります。JRMCのDLNAサーバーをオフにし、コントロール・ポイント機能だけを使う場合、MinimServerのライブラリーは見えてfemtoServerは見えないという点です。
DLNAの仕様に準拠したコントロール・ポイントであれば、両者で挙動が変ることはありません。
という部分ですね。つまり、JPLAYfemtoServeerとJPLAYレンダラーの再生中の動作はそのままで、DLNA関連の情報は自力で取得し、操作性を改善したコントロールポイントを開発することは出来ないか。
「JPLAYfemtoServeerとJPLAYレンダラーの再生中の動作はそのままで」という部分はJRiver以外のコントロールポイントはそういう作りのはずです。「DLNA関連の情報は自力で取得し」という部分は今回のJRiverのやり方を参考にすればいいし、「操作性を改善」は前の二つがクリアできれば、どうにでもなるでしょう。
てっとり早いのは既存のコントロールポイントに機能追加してもらうことです。適当な作者を物色し、Marcinさんと連絡をとらせる一手じゃないだろうか。提案してみますかねぇ。
いろいろな考察、ご意見とても参考になります。
当方も多分に仮説・推測を含めてJRMCOとFEMTOサーバーの連携を紐解いてみました。
①JRMCから見て、FEMTOサーバーは正しくDLNAサーバーとして認識されている。
・サーバーリストにFEMTOサーバーはちゃんと現れる。
(DLNA機能を有効としておけばDLNAサーバ機能はオフでも現れる)
・音源情報をFEMTOサーバーからロードしようとする(がエラーとなる)
・JRMC再起動時にもFEMTOサーバーからロードしようとする (がエラーとなる)
②FEMTOサーバーをターゲットにして強制的にインポートした音源は(おそらく)
FEMTOサーバーを使用せずにFEMTOレンダラーに送ろうとする。
・このためにはDLNAサーバー機能が「オン」でなければならないが、この場合は
再生可能。
・DLNA機能が「オフ」でも一応再生を試みる(が結果失敗してだんまり)
③minim serverとFEMTOレンダラーをコントロールポイントとしてのJRMCから利用する
ことは問題ない。(コントロールポイント機能のみオン)
前提として、ここまでは今までのやり取りからほぼ「共通認識」と思います。
では、なぜFEMTOサーバーの音源ロードに失敗するのか、ということですが、
仮説:
(1)FEMTOサーバーがタグ情報をJRMCに提供しない、ということによる問題か?
(2)JRMC、FEMTOサーバー間の情報受け渡しにおける何らかの問題か?
仮説(1)を確認するために④の実験
④実験:
タグ情報が提供されず、フォルダー情報のみ提供されていたらJRMCはどう動くか確認するため
全くタグ情報を持たない音源のみJRMCに読み込ませてみました。インポート問題なく終了。
・JRMC本体では「ファイル」という項目からフォルダー階層を追って選曲可能。
・JRemoteではこの「ファイル」という検索手段はなく全音源トラックの一覧が
表示されるのみ。(実質的に選曲は結構困難です)
このことから、JRMC自体はタグ情報がなくても、フォルダー階層情報が提供されていれば
フォルダー階層をたどることができるようになる。
(これは通常のコントロールポイントの機能でできていることと同じ、ということに
なりますね。一方でJRemoteからの選曲操作は極楽操作ではなく、全くの地獄操作に
なっちゃいますが)
上記から仮説(1)は「否」となったので、仮説(2)を検証するために⑤の実験
⑤実験:
上記と同じタグ情報を持たない音源をFEMTOサーバーのライブラリに指定した場合、
JRMC上ではFEMTOサーバーは存在として現れる(DLNAサーバー機能オフでも)が、
音源ロード時にエラーになる。(①の状況と同じ)
「選択されたDLNAサーバーからファイルを回収する時に問題が起こりました」ですね。
このことから、仮説(2)が実証的には正しく、音源情報の連携・受け渡しに
何らかの齟齬が起きているものと推測します。ただし、これは整合性が取れていない、
というだけでもともとDLNAの仕様自体が結構「やわ」だと感じていますので、
仕様の解釈ならびに実装上の違い、ということだけかもしれません。
(追記)
motomotoさんのFEMTOサーバーとFEMTOレンダラー間のデータ受け渡しの件、大変
興味深く拝見いたしました。
JPLAY6.2ではStreamerからJPLAYサービスに送り出された以後かなり細かく刻んで
トラフィックの負荷変動を均一化していましたが、minim serverなどからの読み込みは
ご指摘の通り、現在の曲の終わる少し前にがばっと読み込んでいますので、平準化
されていませんでした。
おそらくですが、FEMTOサーバーが登場した背景はここにもあって、このサーバーでの
読み込みならびにFEMTOレンダラーに受け渡す処理を極めて平準化することによって
負荷変動を抑えつつ正確なタイミングを刻む、ということを全体にわたって適用しようと
しているのではないでしょうか。そうであれば、サーバーの違いによってこの音の差が
生まれる理由が何となく納得できるような気がします。
すみません。重要な情報を引用しわすれいました。
-------------------------------
JPLAY日本語デスク
yoさんのサイトをのぞきに行って来ました。
femtoServerはタグを読込まない、との投稿がありますが、これは正しくありません。
C:\JPLAY\MusicLibraryをメモ帳で開いてみてください。タグ付きファイルであれば、タグ情報も書かれているはずです。
当デスクでも今確認しました。タグ情報らしきものが全く無いので、最初は本当に読込んでいないかと焦りましたが、手持ちのライブラリーは全てタグ除去済みなので、これは当り前でした。
-------------------------------
ということですので、タグ情報は送られているようです。
従って、
> このことから、仮説(2)が実証的には正しく、音源情報の連携・受け渡しに
何らかの齟齬が起きているものと推測します。
という検証結果はこの点でも確認できます。
femtoServerからのload時のJRiverのエラーメッセージの全文ですが
There was a problem retrieving files from the selected DLNA server.
Please ensure that the server you are connecting to supports seach, and that it is running properly.
Your library may be imcomplete until you correct the problem and reload the library.
となっています。二行目の「supports seach」という部分が気になりますね(僕の持っているのは英語版なので、日本語版はここがどうなっているのですかね)。
これがどういう意味なのかは、多分 C:\JPLAY\MusicLibrary を解析すれば、分かるのではないかと思います。
とすれば、これをJRiverが納得するように変換するプログラムを作れば両者の仲違い(^^;;;をとりもつことかできるのではないかと邪推します。
どんなものですかね。
おはようございます。
JRMCからの日本語のエラーメッセージは以下の通りです。
----------------------------------------------------
選択されたDLNAサーバーからファイルを回収する時に問題が起こりました。
検索する時に接続しているサーバー名とその稼働状況が正常かを確認してください。
問題を解決し再度読み込みをするまでに、ライブラリが未完成の可能性があります。
-------------------------------------------------------
タグ情報についてですが、
「コントロールポイントに情報を提供していない」
というところがミソですね。読んでいるのであれば、せっかく読んだその情報をコントロールポイントに提供しないというのには何らかの理由があるのかもしれません。
おそらくそれも「音質」に関する影響を考慮した上でのこだわりなのかも、、、
タグ情報が提供されない状態であれば先の④の実験から、JRemoteでの操作性には全く貢献しない状況なので、当方的には
もし本件の取り込みエラーが解消されたとしても、ちょっとな~という感じではありますが。
引き続き、JRMCとのコラボでの操作性を維持しつつの音質向上策など探ってみようと思います。また、foobar2000(+MonkeymoteHD)ではどうなんだろうか、という興味も湧いてきてしまいました(笑)
XMLで書かれているようですが、これは多分DLNAのプロトコルで規定されているフォーマットなのでしょう。
僕の場合、femtoServerには自作NASにある音楽ライブラリを指定しているのですが、全体でフォルダー(CDアルバム)数が5549、ファイル(曲)数が78000以上あります。
[G:\cd]dir /AD /S /B | find /c /v ""
5549
[G:\cd]dir /S /B | find /c /v ""
83602
G:\cdというのがCDをリッピングしたバックアップフォルダーです。
MusicLibraryは1295行。最低限、フォルダーは二行、ファイルは一行が必要なようなので、全体の情報は持っていないようです。実際、中身を調べると、最近アクセスした(聴いた)フォルダーの情報だけ保存されていました。
これに対して、JRMCのタグ情報を利用した操作性を可能にするには、全ファイルのタグ情報が必要となります。
JRMCのloadというコマンドはこのためのものだと思います。従って、「全ファイルのタグ情報頂戴」と要求しに行ったのに、「これだけだよ」というつれない返事が返ってききて、怒り心頭、「こいつのサーチ機能はおかしいぞ、相手にしてやんねぇ」とエラーにして、以降は自身のサーバ機能を使っているということのようですね。
minimserverの場合は全体ファイルのタグ情報を持っていて、それで返事するから、JRMCは「ういやつじゃ、お前はサーバーとして認めてやるぞ」となり、以降、minimserver側のサーバ機能が使われるということになっているようです。
DLNAプロトコルの詳細が分からないので、JPLAYとJRMCのどっちの言い分が正しいのか分かりません。ただ、JPLAYが音質優先で今のやり方をしているとすると、回避策はタグ情報は自力で読み出すというやり方しかなさそうですね。
怨念の対決は続くだなぁ(^^;;;(^^;;;。
「爆笑!」にて拝読させていただきました。
怨念の対決、あるいは深くて暗い河、、、真にその通りでしたね~ (取り急ぎレスまで)
追記します:
Music LibraryのXMLを見てみました。単純にするために1フォルダー、1曲、カバーアートのみという
構成です。また、見やすくするためにタグで括られている部分などに改行をいれてあります。
この解析が正しいかどうかは自信が持てませんが、タイトル、アルバム、アーチスト、トラックに
ついてはタグ情報を読み込んでいます。不思議なことにジャンルの情報は見当たりません。
---(ビジーな内容なので、ご興味とお暇のある方用)----------------------------------
c:\JPLAY\femto.png
<DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/"" target="_blank">http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">
<container id="r-3" parentID="$femtoRoot$" restricted="1" searchable="0">
<dc:title>D:\JIKKEN\</dc:title>
<upnp:albumArtURI>http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/0</upnp:albumArtURI>" target="_blank">http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/0</upnp:albumArtURI>
<upnp:class>object.container.album.musicAlbum</upnp:class>
</container>
</DIDL-Lite>
c:\JPLAY\femtoS.png
c:\JPLAY\femtoR.png
D:\JIKKEN\
r-3
D:\JIKKEN\Message\Folder.jpg
http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/4" target="_blank">http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/4
D:\JIKKEN\Message\
f-5
"D:\JIKKEN\Message\01 - 僕の海.flac" <-- ファイルへのパスとファイル名
<item id="6" parentID="f-5" restricted="1">
<dc:title>僕の海</dc:title> <-- タイトル名(タグ情報)
<upnp:album>Message</upnp:album> <-- アルバム名(タグ情報)
<upnp:artist>アグネス・チャン</upnp:artist> <-- アーチスト(タグ情報)
<upnp:originalTrackNumber>1</upnp:originalTrackNumber> <-- トラック(タグ情報)
<upnp:albumArtURI>http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/4</upnp:albumArtURI>" target="_blank">http://192.168.1.145:48167/JPLAY192.168.1.145femtoServer/Upnp/resource/4</upnp:albumArtURI>
<res duration="00:04:50.08" sampleFrequency="44100" bitsPerSample="16" protocolInfo="http-get:*:audio/flac:*">http://jplayfemto/6</res>" target="_blank">http://jplayfemto/6</res> <-- FLAC音源の情報
<upnp:class>object.item.audioItem.musicTrack</upnp:class>
</item>
------------------------------
JPLAY日本語デスク
yoさんの掲示板では議論続行のようですね。
MusicLibraryの中身を解析すれば、コントロール・ポイントで表示可能なタグ情報をfemtoServerからの情報より増やすことはできます。但し、単純なテキスト・ファイルとはいえプログラムの解析行為は使用許諾契約違反になりすますから、議論される際には留意してください。
フォルダー・ビューの情報だけから、femtoServerのライブラリーがどこのどのファイルを参照しているかはわかります。これを知ることは許可された使用法でできるので、問題ありません。しかし、それらのファイルを直接読んでタグ情報を抽出しようとしても、抽出プログラムが同一PC上に無い場合には参照権限があるとは限りません。
同一PC上であれば、femtoServerに頼らず、JPLAY FEMTOインストーラーで指定したMusic Libraryのパスをレジストリーに見に行けばわかります。
そしてコントロール・ポイント側で抽出結果と実際のfemtoServerからの情報をマッピングさせると、yoさんの掲示板で議論している方々が目指す状態になります。
抽出プログラムの作成とfemtoServerと同一PCでの常駐、およびコントロール・ポイントの大幅変更が必要ですね。
もし本当にやるつもりなら、proxyサーバー的アプローチがスマートでしょう。中身はfemtoServer、タグ情報やサーチを受付ける機能を付加します。そうすれば、どのコントロール・ポイントでもMinimServerと同じタグ情報や検索機能が実現できます。
-----------
yo
> JPLAY日本語デスク さんへ
フォローありがとうございます。
白状すると、僕はフォルダーの階層構造でリッピングしたCDアルバムを管理していて、フォルダービューさえあれば十分で、タグによる操作性の向上はどうでも良いのですが、まあ、なりゆきで(^^;;;、頑張っています。
このメッセージも大変に参考になりますので、ありがたく転載したいと思います。問題があるようなら、教えて下さい。
-----------
JPLAY日本語デスク
> yo さんへ
あちらに転載していただいても問題の無いように最初から書いていますからOKです。
しかし、JPLAY開発チームがせっかく音質優先のために落した機能を別途追加したのでは、本末転倒どころかMinimServerを素直に使うより音が悪くなるでしょう。
-----------
yo
> JPLAY日本語デスク さんへ
あちらに書いたのですが、「JPLAYfemtoServeerとJPLAYレンダラーの再生中の動作はそのままで、DLNA関連の情報は自力で取得し、操作性を改善したコントロールポイントを開発することは出来ないか」ということが出来ませんかね。
つまり、BubbleUPNPに外付けでタグ情報を処理するプラグインを付けるという感じです。
音楽ライブラリがどこにあるかという情報はJPLAYと同じようにユーザに指定されるという方法で取得し(これはご指摘ようにJPLAYのレジストリ情報でも取得できますね)、その情報をベースに直接内蔵ディスクなりNASからタグ情報を読み込み、適当なGUIを構築する。再生に入ったら、何もしないということは出来ると思います。
まあ、結局
> もし本当にやるつもりなら、proxyサーバー的アプローチがスマートでしょう。中身はfemtoServer、タグ情報やサーチを受付ける機能を付加します。そうすれば、どのコントロール・ポイントでもMinimServerと同じタグ情報や検索機能が実現できます。
ということになりそうで、DLNAプロトコルの開示が前提になりますので、素人には無理ですが。
-----------
JPLAY日本語デスク
> yo さんへ
少なくともJPLAY開発チームは手掛けないでしょう。
DLNAを熟知している人がボランティアでやるか、カンパを集めてアルファシステムズなどプロに開発委託でしょうね。ソフトウェア開発は1人・年で1500万円ぐらいだと思います。
-----------
yo
> JPLAY日本語デスク さんへ
ひとつだけ開発費用がほとんどかからない方法があるのですよね。
「JRMCに対応させる」です。むこうの掲示板をご覧になっている方にはお分かりのように既に動いている機能の組み合わせを変えるだけで出来るのだから。特に、一番大変なGUIの部分がそのまま使えるのは大きいです。
この方法はJRMCのビジネスからみてもメリットのあるはずで、JPLAYユーザを操作性をダシに取り込む&囲い込むことができるのだから。次期バージョンアップの目玉の一つにすれば、それなりの訴求力があるのじゃないだろうか。
むこうの掲示板でやった真相解析の寸劇の続きをやれば、JRMC親分の取り巻きの一人が「旦那、ここは思案のしどころ、我慢のしどころですぜ。そんなに怒り狂っちゃ、折角の儲け話が消えちゃいます。むこうのしまの客を取り込み、こっちのしまの客を囲い込むには、いい話ですぜ。ここは一番、昔のケンカはとっとと忘れて、J何とかに詫びを入れましょう。同じJ仲間、うるさい客どもを黙らせるには、あいつもサーバと認めてやって、ここから再生しろと教えてやれば、三方(客、JPLAY、JRMC)丸くおさまりますぜ」と説得すれば、よいのではないでしょうか。
あっちで、「JRMCフォーラムに提案してみたら」と教唆煽動してみるかなぁ。
-----------
JPLAY日本語デスク
> yo さんへ
JRiverはJPLAYの関連スレッドを当時全部消去して、JPLAYを使う場合のサポートは提供しないと明言しました。
提案されるのはご自由ですが、yoさん自身がbanされる可能性があります。
-----------
yo
> JPLAY日本語デスク さんへ
参考になる情報ありがとうございます。JRiverのフォーラムは読んでいないので、「JRiverはJPLAYの関連スレッドを当時全部消去して、JPLAYを使う場合のサポートは提供しないと明言しました」とは知りませんでした。
「あっち」と書いたのは僕の掲示板のことですが、そちらで、この情報と「JPLAYチームとしては開発することはない」という情報をベースに作戦を立てたいと思います。
一連の書き込みを引用しますが、よろしいですか。駄目なら僕のメッセージだけで対応いたします(著作権は僕にあるはずなので)。
-----------
JPLAY日本語デスク
> yo さんへ
引用は構いません。
前回も書いたように、JPLAYが提供するものはたとえテキスト・ファイルであっても中身の解析は使用許諾契約違反なので、くれぐれもよろしくお願いします。
-----------
以上です。
「JRMCに対応させる」という案は技術的、経済的には最善の案だと思っているのですが、問題はJPLAY vs JRMCの確執ですね。さて、どうしたものだろうかというところなのですが、皆様方のご意見を頂ければ幸いです。
JPLAY側のスタンスは上記やりとりで大体お分かりになるかと思います。問題はJRiver側ですね。JPLAYの新バージョンに対してどんな反応なのだろうか。
http://upnp.org/resources/documents/UPnP_AV_tutorial_July2014.pdf" target="_blank">http://upnp.org/resources/documents/UPnP_AV_tutorial_July2014.pdf
Open Connectivity Foundation(https://openconnectivity.org/" target="_blank">https://openconnectivity.org/)というサイトでDLNAというキーワードでサーチしたら出てきました。
これで見ると、JPLAYのMusicLibraryは音楽データの情報をこのフォーマットでそのまま保存しているみたいですね。特別なことはしていないように見えます。
seach機能に関しては、JRMCの言い分が正しいようですね。JPLAYは音質優先でプロトコルで規定している全てのサーチ機能をサポートしていないということでしょう。
というわけで、「あるな」と分かったので、捜したらボロボロ出てきました。
DLNA library survey
https://qiita.com/rchu207/items/a3015522b0b316c96efb" target="_blank">https://qiita.com/rchu207/items/a3015522b0b316c96efb
How a UPnP Search works
http://buildingskb.schneider-electric.com/view.php?AID=15197" target="_blank">http://buildingskb.schneider-electric.com/view.php?AID=15197
A super simple UPnP control point client for Ruby
https://github.com/sidoh/easy_upnp" target="_blank">https://github.com/sidoh/easy_upnp
最後のやつはrubyの簡単なスクリプトですが、これを使えば、femtoServerの機能と動き方をチェック出来ると思います。誰かやってみませんか。
難攻不落の秘密の要塞だと思っていたのですが、意外に穴だらけのようですね。誰かボランティアを募って攻略に臨む一手ですかね。
>従って、「全ファイルのタグ情報頂戴」と要求しに行ったのに、「これだけだよ」というつれない返事が返ってきて、
>怒り心頭、「こいつのサーチ機能はおかしいぞ、相手にしてやんねぇ」とエラーにして、以降は自身のサーバ機能を
>使っているということのようですね。
私もJRMCとJPLAYとの関係はユーモアたっぷりにyo様からご説明頂いた内容の通りと感じていました。
先に報告させて頂いた通り、JRMCはJplay Femtoレンダラーに延々とデータを送り続けます。yo様が言われる通り、5分間で100MBと言う量のデータを送っています。「何を送っているのか?」と考えた場合、Jplay Femtoレンダラーで再生中のプレイリスト(フォルダー又はアルバム)の全データを送信していると推測しています。レンダラー側では全テータの送信をJRMCに要求しておいて、必要な再生中の曲データだけを取り込み、残りの送信データは破棄している状態かなと考えています。
この状況は、JRMCとJplay Femtoレンダラーシステムの音質低下の1つの要因になっていると思います。
仮に、Jplay Femtoが扱う最小単位がフォルダー単位から曲単位となれば、Jplay Femto側から見ると余計なデータ受信が無くなる可能性が有り、少しは高音質になる様にも思います。
これ以外の対処方法として、これまたyo様と同じ様に「JRMC側にお願い」とも考えました。JRMCにしてみると「相手の首根っこを抑える」メリットは有るかもしれませんが、そうなれば「怨念」では済まなくなって「戦争」になってしまうでしょうから、実施しないと考えます。
また、今回バージョンアップしたJplay7.0はJplay Femto+Jplay Femto Serverと言った単独機能の集合体ではなく、Jplay Femto/Jplay Femto Serverと1つのプログラムとして働いて初めてDLNA機能を発揮し、高音質化されていると認識することが、機能を理解する上で重要だと思います。
以下、余談で「怖い話」を2つ
第1話
既に結論が出て不要になったJRMCが生成したJPLAY femtoServerライブラリを削除しようと思い、JRMCのライブラリマネージャーの「削除」ボタンで削除致しました。
この時点では、左カラムのライブラリ一覧からもJPLAY femtoServerライブラリは無くなりました。
しかし、JRMCを再起動するとライブラリ一覧にJPLAY femtoServerライブラリが復活しておりました。再試行してもこの現象に変化は有りませんでした。(背筋が凍りつきました。)
そこで、JRMCのアンインストール(当然ライブラリー削除オプションを選択)、再インストールを実施しました。これで完璧と思っておりましたら「ニョキッ」とJPLAY femtoServerライブラリが現れた時には、心臓が止まりそうになり、その後「怨念」を感じました。
第2話
JRMCの再インストール前の事ですが、ライブラリ一覧を見ると「名無しのライブラリ」が有りました。JRMCのライブラリマネージャーで情報を確認すると
「""is a local library located at C:.\..(省略)\AppData\Roaming\JRiver Media Center 24\DLNA Library\uuid_JPLAY10.0.0.1femtoServer\」
と表示されていました。最後の部分の「10.0.0.1」はJplay FemtoコントロールPCの2次側のIPアドレスです。何故、1次側ではなく2次側のアドレスなの?
しばらく、この問題は放置しようと思います。「触らぬ神に祟りなし」ですから。
今は、久々にlightMPD/upnpgwを引っ張り出して来ましたら、変な所でスイッチが入りLinuxの世界にワープしております。
> 今回バージョンアップしたJplay7.0はJplay Femto+Jplay Femto Serverと言った単独機能の集合体ではなく、Jplay Femto/Jplay Femto Serverと1つのプログラムとして働いて初めてDLNA機能を発揮し、高音質化されていると認識することが、機能を理解する上で重要だと思います。
同感です。
一つ前のメッセージで紹介したDLNAプロトコル案内ドキュメントを読んでみたのですが、結局、Jplay Femto Serverというのは、Femto専用の特殊な音質優先サーバで、他のレンダラーと組み合わせることは考えていないのではと思います。
コントロールポイントと繋いだ時はフォルダービューだけのサポートなので、これに対応したコントロールポイントを使う必要があります。また、レンダラーとしてFemto以外のものが使えるかなと、MS MediaServerを試してみまたが、動きませんね。コントロールポイントとの相性以外にレンダラーもえり好みするみたいです。
このあたりは前回紹介したRubyのDLNA機能テストツールを使えば、確認できるでしょう。
しかし、いろいろググったら、この呆れたページはまだ残っているのですね。
https://jriver.com/jplay.html" target="_blank">https://jriver.com/jplay.html
関連するページも全部残っているようです。困ったものです。
ちょっと和解を提案するという雰囲気ではなさそうですね。逆に、Femto Server仕様をめぐって、「JPLAY vs JRMC 仁義なき戦い」第二幕を開演しかねないという感じです(^^;;;。
> しかし、JRMCを再起動するとライブラリ一覧にJPLAY femtoServerライブラリが復活しておりました。
JPLAY femtoServerはサーバとして認知される必要があるので、その部分はキッチリと作り込まれているということだと思います。でないと、BubbleとmConnectに認めて貰えませんから。
レスを頂きありがとうございます。
怖い話で肝心な事が抜けておりました。この数日jplayを聴いておらず、JRMCの再インストールした時も現在もjplay femto PCはネットワークからも外しダンボール箱に入れておりました。この様な状態でも「ニョキッ」とJRMCのライブラリ一覧に現れております。
> 怖い話で肝心な事が抜けておりました。
femtoServerのDLNAネットワークにおける管理情報の管理の仕方は何か怪しいですね。効率化(音質アップ)のためにDLNA規約をかなり自由に拡大解釈して利用しているように感じます。いずれ、このあたりを発端にして、JPLAY vs 規約遵守連合軍で第二次「仁義なき戦い」が起きる可能性はありますね。
サイトに書いた僕の経験ですが、JPLAYインストール時のNAS登録で入力ミスをしたのですが、どうやっても入力エラーの内容を訂正出来なかったことがあります。
http://mimizukobo.sakura.ne.jp/articles/articles023.html#001" target="_blank">http://mimizukobo.sakura.ne.jp/articles/articles023.html#001
結局、OSのインストールし直しで対応しました。その時は謙虚に自分でやったチューニングが原因と思っていたのですが、今となってみると、femtoServerが「エラー内容を不死身とさせていた」可能性もありますね。全ては闇の中ですが。
ブログ再開をお待ちしていました。しかし、”arch linux でUPnP(6)”でイメージをダウンロードしようとしたらできません。ダウンロードの指示が間違っているように思うのですが・・・。ダウンロードできる方法をお教え下さい。
続きをよろしくお願いいたします。
ps yoさんがDC-ARROWを購入されたとお聞きしたときは私が
余計なことを書き込んだばかりに散財させてしまったのでは
ないかと、申し訳ない気持ちだったのですが、実際に音を
聴かれた感想を拝見し安心いたしました。
製作日記、楽しみにしております。
「arch linuxでUPnP(2)」についてのコメントをこのスレッドをお借りして入れさせていただきます。
当方も最近raspi3とUSB-DACを購入しました。yoさんが購入されたものとは月とスッポンですが、貧乏サラリーマンには精一杯のものです。
それはさておき、再度掲示していただいたこれらの手順により躓きながらも無事稼働させることができました。mpdの入れ替えはまだ行っておりませんが、取りあえずこの状態で聴いてみました。ノーマル・カーネルながらやはりarchと思える良い音ですね。ちなみに、当方でもrc.local方式でないとmpdを起動させられませんでした。
あと、Archphileでの導入事例の説明があり同様にやってみたのですが、pacmanの際mirror.archlinuxarm.orgで404エラーとなりました。なので当方はatom機に入れたubuntuで処理しました。
今後の続編を期待しております。
「arch linuxでUPnP(2)」へのコメントありがとうございます。
arch linux はローリングリリースなので、タイミング次第ですが、最近のリリースは非常に音がいいですね。
arch linux のインストールはたいして難しくないのに、Volumioや Moodeといった音の悪いディストリビューションばかりが人口に膾炙するのは変だなぁと思って、arch linuxの記事を書いています。よろしくお願いします。
archphile(これは素晴らしいディストリビューションだと思います)ですが
pacman -S p7zip
wget https://sourceforge.net/projects/archphile/files/rpi2/archphile-0.99.4c-beta-rpi2.zip" target="_blank">https://sourceforge.net/projects/archphile/files/rpi2/archphile-0.99.4c-beta-rpi2.zip
7z x archphile-0.99.4c-beta-rpi2.zip
dd if=archphile-0.99.4c-beta-rpi2.img of=/dev/sda
でインストールできませんか(はずしているかもしれませんが)。
書き方が簡略し過ぎで分かり難かったですねm(_ _)m
archphileはWindows PC側で解凍、SDへの書き込みを行いました。raspi3でarchphileを起動後、sshで「pacman -S dosfstools」を実行したら、404エラーとなり先へ進めなかったということです。
記事にライブラリのアップデート(apt-get update 相当)を書き忘れていました。
pacman -Syy
最初の起動直後にこれを実行する必要があります。記事も直しておきます。
「Galvanic変換」興味深く拝見させていただきました。
私もUSBに関して何もしていない訳ではないのですが次の一手を考えているところにこの記事で、背中を押されているような感じがします。
私の環境はRpi2を2台使用した「UPnPのアダプター+プレイヤー(Rpi2はオンボードのLAN同士を1本で接続)」の構成です。プレイヤー側へのIntonaの組み込みでどこまでの変化があるのか非常に興味があります。
記事ではAPUらしきものの上にIntonaが置かれた写真でしたが、Rpi(例のケース付き)とIntonaの組み合わせについてのご感想などいただければと思います。
また、私なりのupnpプレイヤーを作成しましたのでこの場に公開させていただきます。このスレッドにはふさわしくないとは思いましたが、アダプターに対するプレイヤーというこじつけの下ご了承願います。
【特徴】
・USB-DAC専用
・lightMPDをベースに極限状態までスリム化
設定変更にはinitrd.romfs.gzの再構築が必要
telnet接続不可
(既にlightMPDの体は成していません)
・ネットワーク設定は、lightMPDのupnpplayerに準拠
・カーネル: 4.12.10 (Low-Latency)
・MPD: 0.20.9
・起動アプリはmpdとpolipoのみ
dop="yes"
polipoはプレイヤーとアダプターをカスケード
【格納先】
https://drive.google.com/file/d/0B9LSJY9xM01jVDdXQ3JyWDhWMW8/view?usp=sharing" target="_blank">https://drive.google.com/file/d/0B9LSJY9xM01jVDdXQ3JyWDhWMW8/view?usp=sharing
【ファイル名】
rpi2-upnpplayer-usb-20171001.zip
はじめまして。お世話になります。
大変興味がありましたので、ダウンロードさせてもらって解凍したところ中身はboot系のファイルのみで、mpd本体や設定ファイル(conf)等はありませんが、lightMPDのいずれかのバージョンにアドオン(上書き)するものでしょうか。
ダウンロードしていただいた物がすべてです。
SD関連すらも外したくこのような形としています。
UPnPプレイヤーとの割り切りのためこれもありかなと。
解凍して出来た「rpi2-upnpplayer-usb-20171001」フォルダの中身をSDへコピーしてご利用ください。
それでは背中を押してしまいましょう(^^)。
Intonaですが、接続形態(タンデム vs スタンドアロン)や接続機種(APU vs R-PI)と関係なしに間に入れると解像度を高めるという効果があります。
donuts.shop73 さんが公開されているソフトを使ってみての判断ですが、間違いなくこの差を聞き分けられる耳をお持ちだと思いますので、Intonaが235ドルでgetできるのであれば、お勧めします。
upnpプレイヤーの公開ありがとうございます。試してみます。lightmpdの掲示板で公開された版の進化系と考えてよいのでしょうか。
Intonaのコメントありがとうございます。先ほどポチってきました。届くのが楽しみです。
upnpプレイヤーですが進化しているか退化しているかの判断はお任せします。他を参考にしつつ手を入れて来ました。しかし公開後はupnpアダプター側に対して主に手を入れていましたのでupnpプレイヤー側の変化量は少ないと思います。
digififanさんが先月公開されたraspberry pi 2 用のlightMPD v1.0.4にpolipoとupmpdcliが実装されたのはご存知かと思います。
それをベースに自前ビルドしたカーネル(USB-OTG(host)と所有しているUSB-LANアダプタを加えたもの)に差し替えると共に、
lightmpd.conf を upnpgwアダプター用に書換えることで
RP3(v1.0.4ベースupnpgwアダプター) <-> RP2+SabreBerry32(v1.0.4b xenomai版upnpプレーヤー)シングルライン接続で動作させることができました。
(BBGとのダブルライン接続はまだ試していません)
変更したファイルは下記の通りです。
boot/zImage
自前ビルドしたものをコピー
config.txt
kernel=/boot/zImage ←自前ビルドしたカーネルファイル名を設定
dtoverlayは全てコメントアウト
lightMPD/lightmpd.conf
[network] にhomeネットワークと接続するethポートの設定
[network:player] にupnpプレーヤーと接続するethポートの設定
[upmpdcli] や [polipo] は upnpmode の lightmpd.conf を参考にしつつ、digififanさんのlightmpd/upnpgw解説ページの lightmpd.conf-upnpgw に合わせました(polipoのメモリサイズ設定に注意)
nasやmpdの設定は削除
lightMPD/mpd.confやmpd本体は削除(アダプターとして使うので)
面白い情報ありがとうございます(「Boticized lightMPD UPnP版を公開しました(4)」への書き込みは紛らわしいので、削除しておきました)。
raspberry pi 2 用のlightMPD v1.0.4 を使って、カーネルをビルドすれば、upnpgw化することが出来てしまうということですね。
シングルラインモードであれば、kens さんが設定されたように、lightmpd.confの修正で対応出来るはずです。ダブルラインモードになると、アダプター側の3回線目とプレーヤー側の2回線目をどうやって認識刺せ、接続同期させるかという問題があるので、lightmpd.confの修正だけで対応するのはちょっと大変かなと思います。僕がBBのUPnP版でやったように、外出しにしてしまえば、簡単に出来ます。ただ、Initrdの再構築は必要となりますので、ハードルはあります。
もともとRaspberry版やBB版のlightmpdはzImageとuInitrdを着せ変え人形方式でいろいろ組み合わせられるようになっています。「Boticized lightMPD UPnP版を公開しました(4)」に書き込んだdigififanさんの評価用4.9版Boticを僕のUPnP版で動かせるのも同じ理屈です。とても便利ですね。
まあ、このあたり、いろいろ試して頂いて、どんどん新発見を書き込んもらえば、ますまろ面白くなるなと思っています。
raspberry pi 2 用のlightMPD v1.0.4を使ってシングルラインモードのアダプターは比較的簡単に実現できるようになりましたが、
もう少しカスタマイズしたい場合など、initrd.romfs の分解再構築方法を勉強しておくと色々役立ちますね。
私はupmpdcliでアイコン指定をしたかったので S00setupvar を弄って /var/lightMPD/etc/ にアイコンファイルをコピーするようにしました。
lightMPDのinitrd.romfs.gzはgenromfsコマンドさえ用意できればlightMPD上で再構築可能です。
私が上で公開していますRpi2用のupnpプレイヤーですが、設定変更可能なように手を加えました。
その際initrd.romfs.gzの再構築も盛り込みましたので興味がおありでしたらのぞいてみてください。
【主な変更点】
・セットアップ用のカーネルを別途用意(zImage.setup)
SDマウントとtelnet接続が可能なようにモジュール追加したもの
・セットアップ時のみmpd、mpd.conf、polipo.confを外部から取込可
・initrd.romfs.gzにinitrd.rofms.gzの再構築用モジュールとスクリプトを追加
・一部ライブラリの入替
・busyboxの入替(使用可能なコマンドを追加)
【initrd.romfs.gz再構築手順】
(1)config.txt変更 (#を付け替える、以下は変更後の内容)
#kernel=/boot/zImage.player
kernel=/boot/zImage.setup
(2)confディレクトリのupload.lstを変更
mpd、mpd.conf、polipo.confの内取り込みたい行を有効化(#を外す)
※'='の右に取り込みたいファイル名を指定
(3)起動&接続
アダプター経由でtelnet接続(root/パスワードなし)
(4)/var/bin/mkimage.shを実行
/var/tmp/imgディレクトリを作成し、initrd.romfs.gzに必要な情報を収集
※(2)の内容も反映される
(5)/var/tmp/imgの内容を変更(任意)
SD経由でPKG、LIBの追加も可
(6)/var/bin/mkinitrd.shを実行
/var/tmp/imgの内容からgenromfsとgzipによりinitrd.romfs.gzを作成
※SDのconfディレクトリへコピー
※SDへのコピー前後でSDのmount/umountを実施
(7)bootディレクトリ(SD内)のinitrd.romfs.gzを置き換え
※元のファイルは念のためバックアップを残してください。
(8)起動確認
(9)config.txtの戻し
※(7)のバックアップが不要なら削除
【格納先】
https://drive.google.com/file/d/0B9LSJY9xM01jOUc1MlFCMlkwUmc/view?usp=sharing" target="_blank">https://drive.google.com/file/d/0B9LSJY9xM01jOUc1MlFCMlkwUmc/view?usp=sharing
【ファイル名】
rpi2-upnpplayer-usb-20171014.zip
「面白いアイディアだなぁ」と思い、試してみました。
/var/bin/mkinitrd.shスクリプトでエラーになります。理由は /mnt が / に存在しないので、sdのファイルがinitrdに反映されないのですが、簡単な直しで対応出来そうです。このままで、lightMPD上でinitrd再構築の練習問題として使えますね。また、/var/tmp/imgを弄れば、いろいろ遊べそうです。
ところでupnpプレイヤーの音を初めて聴きました。素晴らしいですね。
symphonic-mpdにもビックリしましたが、傾向は違いますが、こちらはとてもリアルな音で感心しました。アダプタはlightMPD apuを使いましたが、相性は抜群です。
公開ありがとうございました。
/mntが存在しない件、確認しました。
大元のイメージには存在していたのですが、問題のあるスクリプトで作成した
initrd.romfs.gzを公開してしまったため今の状況となってしまいました。
修正のアプローチとしては2通りあると思いますが、
ご提案の通り練習問題としてこのままとさせていただきます。
symphonic-mpdはかなり賑わってますね。
私は音出しまではしていないのですがエッセンスは参考にさせていただきました。
上記 /mnt が存在しない件も対応しています。
【格納先】
https://drive.google.com/file/d/0B9LSJY9xM01jTG4yZDNmWVJyTzg/view?usp=sharing" target="_blank">https://drive.google.com/file/d/0B9LSJY9xM01jTG4yZDNmWVJyTzg/view?usp=sharing
【ファイル名】
rpi2-upnpplayer-usb-20171015.zip
前スレで私がbuildrootで自前ビルドして構築したRPi2/3 lightMPDベースのupnpgwアダプターですが、DSD256等の大きなサイズのファイルを再生すると曲の途中で勝手に次の曲へジャンプするという不具合が発生することに気付きました。
digififanさんのRPi2用lightMPD v1.0.4bベースでカーネルを差替えて構築したupnpgwアダプターを使用すると不具合は発生しません。
polipo.confやpolipo本体をdigififan版と合わせたりして試行錯誤しましたが結局不具合は解消できなかったので、デキの悪い自前ビルド版は捨ててdigififan版に乗り換えることにしました。
ダブルライン接続用の3回線目にはusb0を使いたかったので、initrd.romfsを再構築する際にはyoさんのmyscriptの実装(※)を参考にさせていただきました。
※関連情報スレ
Boticized lightMPD用のmpdのビルド
http://mimizukobo.sakura.ne.jp/cgi-bin/read.cgi?mode=all&list=topic&no=5508" target="_blank">http://mimizukobo.sakura.ne.jp/cgi-bin/read.cgi?mode=all&list=topic&no=5508
何処かに長期出張の報告を最後に音沙汰が無いのですが
管理人様 健康面等大丈夫ですか?
元気にやっています。いろいろ次のネタを仕込んでいるところなのですよね。最近、メインのオーディオシステムはWindowsになっているのですよね(^^;;;。
お元気でのようで何よりです。
7月31日だそうですが、こんなボードが発売されるとか。
https://developer.sony.com/develop/spresense/#overview-content" target="_blank">https://developer.sony.com/develop/spresense/#overview-content
ARM Cortex-M4F(6コア、156MHz)、SRAM:1.5MB、フラッシュメモリ:8MB、標準でGPSとGLONASSに対応、最大8chの音声入力と192kHz/24bitのオーディオ録音/再生に本体ボードのみで対応。
不要なものも乗ってますが、I2S出力が標準装備です。
ただし、外部クロック入力の可否は不明。SONYだから、もしかしたらMQAも?
仕様次第ではネタになるかもですね。
では、では、またいつか。
最近、ブログの更新をする気にならない理由は、TEAC NT-505、IOデータ Soundgenicといったネットワーク関連の新製品が登場してきて、これらを使えば十分という感じになってきたのが大きいです。苦労して、Linuxと格闘するより、金で解決という安易な方法ですが、まあそれなりに使えそうなネットワーク機器が次々と登場。楽を出来そうというのは歓迎ですね。
もっとも、これらの新製品、僕はまだgetしてはいないのですが・・・。
「Soundgenicなんて、あんなチャチなハード、自作すれば確実にもっとよく出来る」と考えてしまうのですよね。
同意しますが(笑)お値段を見ると....
同じ金額をかけて自分で作ったら見栄えは負けるけど
音の良さは同等かそれ以上にはなるのでは(^_^;)
スケベ根性で夜な夜な弄っている訳で(笑)
Windows10とUSB-DACの相性は自分の経験では良くないので
音楽再生に関してはすべてlinuxを使っています。
PCとOSにもお金をかければ快適になるのかな(笑)
> Windows10とUSB-DACの相性は自分の経験では良くないので
同感です。
ただ、僕の居間のメインシステムは Windows10+TurboBrowser で鳴らしています。
usb対策としてノートパソコンとDAC(SoulNote D1)の間にintonaを入れています。
APU2台のLinux のシステムと比較すると、音は多少レベルダウンしますが、安定性と操作性はWindows10+TurboBrowserの方が断然上です。怠惰な身、普段はWindowsを使い、気合を入れて聞くときだけ linuxを使うという感じですね。
JPLAYはデュアルモードがDACドライバとあまり相性がよくないので、最近はあまり使っていません。
miniPADのiOSの更新などをしていて気が付いたのですが、MPD用のクライアントであるmPOD、mPADがAPP Storeから消えてしまっています。最近ほぼ更新はなかったのですが、まさかもうダウンロードできなくなっているとは思いませんでした。もしかしたら何か勘違いしているのかもしれませんが、、、
この二つのクライアントアプリがないと、MPD系の操作性がガクッと低下してしまうので、とても気になっています。VoyageMPDも0.11.0はサイレントリリースですし、時代の変遷とは云えとても寂しいものがありますね。
LightMPD関連は今後も発展していって欲しいのでこれらのクライアントアプリは必須だと思うのですが、、、
この辺り何か情報をお持ちでしょうか?
> miniPADのiOSの更新などをしていて気が付いたのですが、MPD用のクライアントであるmPOD、mPADがAPP Storeから消えてしまっています。
さすが apple、素早い対応ですね。僕は最近 iPad Air を入手したのですが、インストールしたアプリはLUMIN、Kinsky、KazooなどUPnP対応のコントロールポイントアプリばかりですね。書き込みを拝読して、「そういえばMPD用のクライアントアプリを入れてないなぁ」と気が付き(^^;;;、APP Storeに捜しにいきましたが、何もありませんね。
Androidの方はまだMPDroidなどダウンロード出来るようなので、appleは凄いですねぇ。
まあ、昔、Windows3.1が登場した時、ファイラーソフトなどWindowsで動くものは遅いのと操作性が悪いので、dosアプリが使われ続けるということがあったけど、それと同じですかね。しかし、Windows98位になるとさすがにdosソフトを使っている人は誰もいなくなったから、MPD用のクライアントアプリもそれと同じ運命をたどるのでしょうね。
ブラウザを使ってympdで操作するというのじゃ駄目ですか ? 操作性はだいぶ悪くなるかもしれませんが。
新規ユーザーが減り、APP Storeに載せておく費用あるいはiOSのバージョンアップに追随するコストが捻出できない、などの理由があるかもしれません。
この状況では新たなMPDユーザーの誕生には悲観的になりますが、ラズパイやAPUのユーザーも減少しているのかな?
当面はiPOD、iPAD、miniPADのいずれにもインストール済なので問題ありませんが、買い換えは不可ですね~
itmedia1706/07/news056.html
mpdjs/id965553250
soundirok
yoさん
こんにちは。Takeshichです。
記事にコメントを残そうと思ったのだけど、ここでいいのでしょうか???
>このページで不思議なのは git clone のコマンドの表記が画面右中央にありますが、そ
>の通り操作してソースをとりにいってもパッチのかかっていないオリジナル(?)の 1.1.5
>のソースになることです。しかし、その上にあるdownload snapshotというボタンをクリ
>ックして、長いサフィックスが付いたzipファイルをダウンロードすると、パッチ修正の
>かかったソースコードがgetできます。このあたり、どうなっているのだろうか。不思議
>です。
forkしたmasterは、オリジナルの追従のためにそのままにしてあり、ブランチを切って
対応していたので、git cloneした後にgit checkout AddSupport4DSDとするとおそらく
目的のソースコードを得ることができると思います。
世の中狭いようで、
https://sourceforge.net/p/minidlna/discussion/879956/thread/816fde51/" target="_blank">https://sourceforge.net/p/minidlna/discussion/879956/thread/816fde51/
のスレ主のBob Willcox さんに2015年の夏にFreeBSDで試してみたけど、ちょっとうまくいかないんだけど
と相談を受けて、酷いバグとかに気づいて修正して、採用されていたところにお知らせしたりしました。
https://bitbucket.org/pl_shibby/tomato-arm/issues/9/bugs-in-my-source-code-minidlna-add" target="_blank">https://bitbucket.org/pl_shibby/tomato-arm/issues/9/bugs-in-my-source-code-minidlna-add
Bob Willcox さんはYAMAHAのレシーバーで聴けたと回答をくれましたし、
sourceforge のDiscussionでは、メインストリームにマージされないの?みたいな意味だったと思いますが、
yellow monkey さんが回答した意図は不明でしたが、上手く聞けない環境だったら記述されているように修正したら
聞ける場合もあるよなぁと思っておりました。
linux mpd+upmpdcli では修正しないと再生できないとのことですが、
2年ほど前確認したことろ、デフォルトのtwonky media sever でも
http-get::audio/dsdとしていましたから、個人的には再生側でなんとかしてほしいと思っております。
MPDでaudio/x-dsdもしくはaudio/dsdで受け取っても再生できるようにという意味です。
デフォルトのtwonky media severでもmpd+upmpdcliで再生できない場合もあるのではないかとも思います。
gitの件は謎がとけました。サイトの記事に追記で訂正しておくつもりです。
確かに、あのスレッドは内容が食い違っていて、不思議だなぁとは思っていたのですが、ようやく事情がよく分かりました。
僕も回答者のyellow monkey(donuts.shop73)さんも linux mpd+upmpdcli ですので、この環境だと回答内容の対応をしないと駄目だということだと思います。ちなみに、この環境で MinimServerやassetでは DSDファイルは問題なく再生出来るので、規格への対応が二派に分かれているということですかね(twonky は試したことがありません)。linuxの世界のdlna対応では mpd+upmpdcli はそれなり使われているので、メインストリームにマージされる場合はどう対応するか検討が必要でしょうね。
donuts.shop73 さんのパッチは当面linux mpd+upmpdcli派に必要ですし、takeshichさんのコピーライト表示はそのまま残されていますので、このまま公開を継続しておいて、問題はないかと思います。ご了解よろしくお願いします。
パッチが二つ発生した経緯は僕のサイトの記事とこの掲示板の書き込みで理解されると思います。
全部入りをdownloadして
ubuntu16.04(32bit)環境で普通にコンパイルして
lightmpd/upnpgw でDSD再生をしてみました。
問題なく再生出来ました!!
Takeshichさん、donuts.shop73さんyoさん感謝です!!
minidlnaのdsd対応ですが、1.1.6でビルドするのが一番簡単で効果的なようですね。
最新版(1.2.1)にパッチをかけたものと比較して音の差はなさそうです。僕の環境では感じられません。気のせいだと思いますが(^^;;;、むしろ1.1.6の方がクリアな音すると思います。MinimServerよりこちらの方がクリアな音なので、僕は自作のサーバをこちらに入れ換えました。
楽にビルドするにはライブラリがそろっていることが必須要件ですが、サイトでの書き込みのリンク先の先に必要なライブリは紹介されていますので(下記url)、そちらを読んでから、とりかかった方がいいでしょう。
https://github.com/mimizone/minidlna-dsd/blob/master/Dockerfile" target="_blank">https://github.com/mimizone/minidlna-dsd/blob/master/Dockerfile
多分mpdを自前でビルドする環境であれば、問題はないと思います。
確かにそう思います。
ただ私の環境の問題なのか?
MinimServerでは出ない曲間ノイズがこのサーバーでは
発生するようになって?原因不明です。
もちろんプレーヤー側はデジファイさんのノイズ対策パッチが当たっている
カーネルなんですが(^_^;)
>多分mpdを自前でビルドする環境であれば、問題はないと思います。
そうですね。私の環境では何も追加インストールする必要が無かったです。
ubuntu16.04のカーネルとalsaのバージョンだと
最新のmpdがうまくビルド出来ないんですが
私だけで何か良い方法があるのでしょうか?
バージョンだけでなくalsaのライブラリーが他のディストリと違う
ものがあってその辺も原因の様にも見えます??
sourceforgeの Discussionへの回答は、はずかしながら単なる英語の読み違いからです。その時は、「パッチを当てても再生できないのは自分と同じ」と解釈しあのような回答をしてしまいました。DSDの状況も知らず早計だったと反省しています。しかしそれが人の役に立てたことについては複雑な気持ちです。
komaさん
私もRpi2ではありますが、ubuntu16.04(minimal server)でmpdをビルドしています。alsa-lib(libasound2)を更新すればビルドできると思いますのでお試しください。パッケージのバージョンでダメならソースからのビルドもお考えください。ビルドだけであればカーネルはそのままで大丈夫ですが再生までとなるとカーネルの更新も必要になるかもしれません。
曲間ノイズについては分かりません。
donuts.shop73さんありがとうございます。
教えていただいた更新を行った結果コンパイルが通る様になりました。
でも systemctl で起動出来ません。
下の様にコンフィグしてエラーが出ていない様に見えるんですが
./configure --with-systemdsystemunitdir=/lib/systemd/system --enable-systemd-daemon
まあ /usr/local/bin/mpd /etc/mpd.config だと起動できるのですが
何が悪いのかよく分かりません。
donuts.shop73さんのRaspberryPi2 upnp版を試してみました。素晴らしいと思います。
もうちょっとPi2に力があればとも思いますが(^_^;)
私自身はsystemctlを使用しませんので分かりませんが、yoさんの記事「2017/07/08(PC_Audio) RaspberryPIをUPnP化させる」にたかじんさんのサイトへのリンクがあります。参考になるかと思います。
そのHPを見て --with-systemdsystemunitdir=/lib/systemd/system としたんですがダメでした(^_^;)まあしょうがない。
/usr/local/bin/mpd /etc/mpd.conf を/etc/rc.localに書き込むしかなさそうですね。
に対応したソース一式をバージョン1.2.1相当にしました。
公開している1.1.6ベースのソースではinotifyを無効にしてしまっている都合上
DBの更新は起動時の '-R' オプションに頼るしかなく使い勝手に難がありました。
1.2.xで '-r' オプションが追加され、この点が改善されていましたので取り込みました。
気になっていた方はお試しください。
【アップロード先】
https://drive.google.com/file/d/0B9LSJY9xM01jZkxrMExodHEtRmM/view?usp=sharing" target="_blank">https://drive.google.com/file/d/0B9LSJY9xM01jZkxrMExodHEtRmM/view?usp=sharing
【ファイル名】
minidlna-1.2.1-dsd.zip
【オプションの違い(Usageより抜粋)】
-r forces a rescan (差分更新)
-R forces a rebuild (再構築(処理前に全削除されます))
※1.1.6では「-R forces a full rescan」でした。
minidlna 1.2.1の公開ありがとうございます。助かります。
早速試してみました。素晴らしい音でDSD再生できます。
ただ、これは前の版でも同じなのですが、何故かコントロールポイントがLUMINだと、一部のDSDファイルが登録出来なくなります。それ以外のソフトでは問題なく登録、再生できます。
僕の環境の問題かと思いますが、他の方ではどうでしょうか。
LUMINは使ってないので分かりませんすいません(^_^;)
ブラウザのキャッシュのせいなのかタブにはMiniDLNA1.6.1と表示されます??
コマンドで-Vで確認すれば1.2.1と出るのですが?
DSDの件、AndroidのLUMINで確認しました。
手持ちのすべてを確認した訳ではないですが、私の環境ではどれも再生できました。
登録できないファイルに規則性はありますでしょうか。
こちらでは対応は出来ませんので、申し訳ありませんがデータ側で対応
していただくことになってしまいます。
ブラウザのバージョン標記の件、私が確認したところMiniDLNA 1.2.1と表示されました。
ソース上にも1.1.6は残っていませんのでやはりキャッシュではと思います。
傾向はありません。半分位のファイルが理由不明でプレイリストに登録できません。
面白いのはiPadで駄目なものは必ずandroidでも駄目になること(逆も真)。つまりLUMIN側にはちゃんと排除の論理があるみたいにみえることです(小池さんみたいですね^^;;;)。
まあ、Kinskyを使えば済みますので、問題はないのですが。
ubuntu16.04(32bit)+minidlna 1.2.1+Upplay+lightmpd/upnpgw(APU1C2+APU1D4) の組み合わせで特定の曲だけ2回表示されてその部分を再生すると2回再生されます?曲のデーターがまずいのでしょうか?音に関してはMinimServerよりもカチっとした感じで大変好ましいと思います。ファイル切り替わり時の曲間ノイズも前回比べてかなり減りました。DSDの方は完璧に近いです(^_^)
お世話になります。Arch Linuxにminidlna-1.2.1をインストールしました。
そもそもLUMINからは、flacデータしか見えませんでした。kinskyでは、DSDもwavも見えるのですが、クライアントによって違いが出ます。
digififanさんのrpi2-v1.0.4のupnpmodeでは、DSDもプレイリストに登録できて再生できますが、同じ版のupnpplayerやdonuts.shop73さんのupnpプレーヤーでは、プレイリストに登録することができません。(アダプターはいずれの場合もapu2/lightMPD)
何か設定のミスをやっている可能性は高いのですが、今のところ??な状態です(^^;
>特定の曲だけ2回表示
rebuild database コマンドで解決しました。お騒がせして申し訳なかったです。
昨日届いたので、早速試してみました。
1-bay NAS Dock v1.2 + NanoPiNEO2 という組み合わせ。
とりあえず手持ちのssdと組み合わせて、ご本家のdebian版のnasイメージをダウンロード。起動してみました。簡単です。これぞ、サルでも作れるnasという感じ。2.5インチディスクを用意する必要はありますが、28ドルで nasが自作出来るのは凄いコストバフォーマンスですね。情報はこちら。
http://wiki.friendlyarm.com/wiki/index.php/1-bay_NAS_Dock_v1.2_for_NanoPi_NEO/NEO2" target="_blank">http://wiki.friendlyarm.com/wiki/index.php/1-bay_NAS_Dock_v1.2_for_NanoPi_NEO/NEO2
ついでに lightmpd v1.04を動かしてみました。Allwinnerということなので、あまり期待していなかった(^^;;;のですが(4年位前にmpd対応イメージを公開したことがあります http://mimizukobo.sakura.ne.jp/articles/articles013.html#007" target="_blank">http://mimizukobo.sakura.ne.jp/articles/articles013.html#007)、apuと組み合わせると予想外に良い音がしますね。ちょっと硬めですが、しっかりした音で、これなら十分使えるという感じ。お勧め。
私もNanoPINEO2の1-bay NAS Dockには注目しておりました。
nasは簡単にできると思いますが,Twonkyはインストールできるでしょうか?
私はRaspberryPi3にTwonkeyをインストールしましたが,非常に簡単にDLNA Serverができました。HDDはUSB接続ですが,使い勝手も非常に良いので,これをメインにして,手持ちのRockDiskNextはMPD用のNAS(NFS接続)専用にしてしまいました。
もう一つありました。
MPDにNASをマウントする場合,普通はCIFSかNFSですが,SSHFSでマウントすると音が良い,というkickさんからの情報があります。
それでRaspberryPi3をSSHFSのMusicServerにしようと思い,悪戦苦闘していました。
この場合もNanoPINEO2でできれば良いと考えております。
NanoPINEO2 1-bay NAS Dock は一休みしています。理由はサイトに記事を書いていますが、r-pi用オーディオケースを入手し、r-piのUPnP化に熱中しているもので。
「UPnP化された r-piをplayerにして、NanoPINEO2 1-bay NAS Dock をadapterにする」のがいいかなと思っています。NanoPINEO2の音はやはりAllwinnerの音で、長時間、聞き続けるのはちょっと辛いなという感じなので。
NanoPINEO2のNAS用OSはdebianですから、r-piで出来ることは同じように出来るのではないかと思います。ただしバッケージのサボートなどの面ではr-piのグローバルさにはかなわないので、自力でやらないといけないという部分は多いかもしれません。このあたり、r-pi側が落ち着いたら試してみるつもりです。SSHFSをMusicServerにというのは面白そうですね。
スレッドの件名とは離れてしまいますが何点か気になりましたのでコメントします。
(1)sshfsでのマウント
RockDiskNext、lightMPD(RPi2)に手を入れてsshfsでのマウントに成功しました。
lightMPD側でマウントした状態を確認したところ、ユーザID、グループID、パーミッションがRockDiskNext上と同じ状態となっていました。RPi3側のパーミッションをご確認ください。
(2)RockDiskNextの使い道
RockDiskNextのDLNAサーバ機能は私も使う気にはなれずどうにかしたいと考え、強引ではありますが以下の方法でDLNAサーバ上にRockDiskNextの情報を共有できました。1つの案として参考にしていただければと思います。
「DLNAサーバソフトのデータディレクトリに、RockDiskNextをnfsマウントしたディレクトリを指定」
私は、lightMPD(RPi2)にMinimServerを導入し確認しました。
(3)wifi対応
yoさんに紹介していただいているlightMPD(RPi2)UPnP対応版は、GW-USNano2専用ではありますがwifiに対応しています。SDカード再生とminidlnaによるDLNAサーバ機能も持たせていますので、上で言われている「HDDプレイヤーのように」をある程度は実現しています。今後そのような方向に進むことがあれば何かしらのヒントになればと思います。
minidlnaはdebian-jessie-nasの中でoptionとして追加する項目がありましたが、エラーが出て組み込めません。
MinimServerですが、僕も試してみました。NanoPI NEO2では動かないようですね。エラー内容から判断するとインストールされているJavaは64ビット版なので一部のモジュールが整合性がとれなくなり、駄目になるようです。
試しにと考え、32ビット版を入れてみましたが、64ビット版を除去する方法がまずいのか、うまく動きませんでした。minidlnaもイントール出来ないとなると、DLNAサーバとして使うという方法はなさそうですね。
私の公開しているイメージには組み込んであります。
lightMPDのブートイメージ(約256MB)を流用しており、SDのFAT32領域の空き容量的にminidlnaを動かす意味がないため設定ファイルからは外していました。RPi2用イメージのlightmpd.confから[nas:SD]、[minidlna]の設定を流用し、iconのパスを修正すれば起動します。
パッケージ操作でのインストールはできないかもしれませんが、自力でビルド、あるいは私のイメージからの移植と言った手段でなら組み込み可能と思われます。
MinimServerはyoさんのおっしゃるとおり、無理なようです。
情報ありがとうございます。僕も試してみます。
minidlnaが使えるとなるとサーバとしての使い勝手は断然よくなりますね。
とこで、サイトの方に「NanoPI NEO用のnasイメージが無いよ」と書きましたが、誤りでした。
https://www.mediafire.com/folder/n5o8ihvqhnf6s/Nanopi-NEO#umkhdtp5nkect" target="_blank">https://www.mediafire.com/folder/n5o8ihvqhnf6s/Nanopi-NEO#umkhdtp5nkect
リンク先にありました。以前は見当たらなかったのですが、最新版では対応されたようです。
【情報元】
https://github.com/openhab/openhabian/issues/57" target="_blank">https://github.com/openhab/openhabian/issues/57
【操作】
以下2行の実行後(rootで実行)、32bit版のJavaが実行出来るようになります。
# dpkg --add-architecture armhf
# apt-get install libc6:armhf libncurses5:armhf libstdc++6:armhf
【確認PKG】
jdk-8u144-linux-arm32-vfp-hflt.tar.gz
MinimServer-0.8.4-linux-armhf.tar.gz
※32bit版同士の組み合わせ
素晴らしい調査能力ですね。そのものズバリのタイトル(Install 32-bit Java on 64-bit ARM processors )のページがあるとは、ビックリです。
家庭内LANが内乱状態なので(^^;;;、まだ試していませんが、これで3重化したnasが全てDLNA対応できそうで喜んでいます。
情報ありがとうございました。
minidlnaのCover Artに関しての情報は下記にありますが、バージョン1.1.4までの情報しかありません。現在のバージョンは1.2.1ですので、そこにアップされているパッチは使えません。
1.2.1用に修正したものをアップしましたのでお試しください。git版(最終更新日:8/26)で確認していますが、普通にDownloadしたものでも利用可能です。
【情報元】
https://sourceforge.net/p/minidlna/patches/70/" target="_blank">https://sourceforge.net/p/minidlna/patches/70/
【パッチアップロード先】
https://drive.google.com/file/d/0B9LSJY9xM01jUkw3eDFzbkZnN0E/view?usp=sharing" target="_blank">https://drive.google.com/file/d/0B9LSJY9xM01jUkw3eDFzbkZnN0E/view?usp=sharing
【ファイル名】
minidlna-1.2.1-no-cover-resize.patch
【利用方法】
1.パッケージを解凍
2.解凍して出来たディレクトリへ移動
3.パッチを同ディレクトリへ格納
4.下記コマンドでパッチ適用
patch -p1 < minidlna-1.2.1-no-cover-resize.patch
5.コンパイル
【設定ファイル】
Cover Artのリサイズを無効にするには設定ファイルに下記を追加してください。
resize_covers=no
cover art のパッチ公開、ありがとうございます。
minidlnaはオープンソースなので、機能拡張にパッチで対応できるのが強みですね。
dsd対応も日本の方がパッチを公開されているので、簡単に対応できます。
https://sourceforge.net/u/takeshich/minidlna/ci/AddSupport4DSD/tree/" target="_blank">https://sourceforge.net/u/takeshich/minidlna/ci/AddSupport4DSD/tree/
関連する作者の書き込みはこちら。
https://bitbucket.org/pl_shibby/tomato-arm/issues/9/bugs-in-my-source-code-minidlna-add" target="_blank">https://bitbucket.org/pl_shibby/tomato-arm/issues/9/bugs-in-my-source-code-minidlna-add
もっとも、そのままだと僕の手持ちのdacでは動かないので、この修正をかける必要があります。
https://sourceforge.net/p/minidlna/discussion/879956/thread/816fde51/" target="_blank">https://sourceforge.net/p/minidlna/discussion/879956/thread/816fde51/
このあたり作者のサイトでは何も書かれていないのですが、オープンにした方がいいですかね。
サイトの方に書くかな。
minidlnaに関する情報有難うございました。
nanopineo2では、パッチを当てたver 1.2.1のインストールに成功しました。しかし、nanopineoでは、パッチを当てた後のmakeがエラーになってしまいました。ライブラリーの問題かと思い、いろいろと試していますが、うまくいきません。そこで、patchが公開されていたver 1.1.5をインスールして、稼働しています。
mimimserverについても情報をいただきましたが、nanopineo2で、32bitのJavaのインストールが依然としてうまくいっていません。
なお、/etc/fstabでの内蔵HDDのマウントはできないようです。マウントに失敗すると、NAS自体が立ち上がらず、sshでの接続もできなくなります。rc.localで遅延時間を設けてマウントすることにしました。
minidlnaはlightMPDへ組み込む際いろいろとさわっており、dsd対応も当然のように行っていました。しかしyoさんと同様手持ちのdacではそのままでは再生できませんでしたので、MinimServer(Windows版)の動きと比較しつつ再生までこぎ着けることが出来ました。上で紹介されている2つめの情報は、名前は違いますが私です。
その他、アイコンファイルの外だし、ビデオ関連の削除も行いました。
余談ですが、MinimServerのアイコンも変更可能です。
「minimserver-バージョン.jar」ファイル内にアイコンファイルを持っていますので差し替えることでKinskyなどに表示されるアイコンを変更できます。ただ、バージョンアップすると元に戻ってしまいますが...
Toshiさん
NanoPiNEO2での32bit版のJavaインストールですが、
nanopi-neo2_debian-nas-jessie_4.11.2_20170817.img
でも動作確認がとれました。
起動直後の状態ではPKGの状態が古いようですので、そのあたりが原因かと思われます。
以下が私が確認した手順です。(1,2はyoさんの手順と同じです)
【Javaインストール手順】
1.Javaの展開
# cd /usr/lib/jvm
# tar xf jdk-8u144-linux-arm32-vfp-hflt.tar.gz
2.javaへのリンク編集
# cd /etc/alternatives
# mv java java.OpenJDKx64
# ln -s /usr/lib/jvm/jdk1.8.0_144/jre/bin/java java
3.パッケージリストの更新
# apt-get update
4.パッケージの更新
# apt-get upgrade
5.32bit対応パッケージのインストール
# dpkg --add-architecture armhf
# apt-get install libc6:armhf libncurses5:armhf libstdc++6:armhf
6.動作確認
# java -version
※以下が表示されればOK
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) Client VM (build 25.144-b01, mixed mode)
情報ありがとうございました。ビックリしました。yellow monkeyざんが donuts.shop73 さんだったとは。
名前の付け方から判断して、てっきりパッチの作者かなと思いましたが、それにしてはご自身のサイトに何も情報がないのは不自然だと考え、謎だったのですよね。
オープンソース、広めた方が有効な情報だと思いますので、donuts.shop73 さんに謎解きしていただいた件も含め僕のサイトの方に書き込むつもりです。ご了解よろしくです。
簡単に可能なら、アイコンファイルの外だし、ビデオ関連の削除も含めてパッチにして頂けると嬉しいです。
訂正します。この方法では、ポータブルハードディスクを共有ドライブにはできないので、nfsやcifsでアクセスすることができません。minidlnaやMinimServerによるDLNAサーバー専用となります。ファイルをコピーするのは、外してパソコンに繋げば良いので簡単ですが。
有難うございました。nanopineo2に32bitのjavaをインストールでき、MinimServerが稼働するようになりました。
お使いのイメージファイルはいつのものでしょうか。
僕は
nanopi-neo2_debian-nas-jessie_4.11.2_20170531.img.zip
を使っていますが、内蔵ディスクを問題なくfstabでマウント出来、組み込まれているsambaでのファイル共用も出来ています。
8月版(nanopi-neo2_debian-nas-jessie_4.11.2_20170817.img.zip)にしたら、ネットワークでの認識も出来なくなったので、元に戻したことがあります。
パッチを2つ用意しました。
いずれもバージョン1.2.1をターゲットにしています。
利用方法についてはCover Artの手順を参考にしてください。
(1)dsd対応パッチマージ版
上で紹介されている2つの情報を1つのパッチにマージしました。
【パッチアップロード先】
https://drive.google.com/file/d/0B9LSJY9xM01jWklPM3pNWmVIQVE/view?usp=sharing" target="_blank">https://drive.google.com/file/d/0B9LSJY9xM01jWklPM3pNWmVIQVE/view?usp=sharing
【ファイル名】
minidlna-1.2.1-add-support-dsd.patch
(2)外部アイコンファイルの取込
指定したアイコンがKinskyなどの画面に表示されます。
指定されない場合は、デフォルトのペンギンが表示されます。
【パッチアップロード先】
https://drive.google.com/file/d/0B9LSJY9xM01jV0xMZjhMVG9rUjA/view?usp=sharing" target="_blank">https://drive.google.com/file/d/0B9LSJY9xM01jV0xMZjhMVG9rUjA/view?usp=sharing
【ファイル名】
minidlna-1.2.1-get-outside-icon.patch
【設定ファイル】
各ファイルへのパスを絶対パスで指定してください。
icon_png_l=png形式:サイズ大
icon_png_s=png形式:サイズ小
icon_jpg_l=jpeg形式:サイズ大
icon_jpg_s=jpeg形式:サイズ小
【アイコンサイズ】
大:120x120
小:48x48
ビデオ関連の削除についてのパッチ化は無理です。修正箇所が多岐に渡りすぎておりもはや別物?状態です。
情報の公開については了解しました、お任せします。
パッチと情報の公開許可ありがとうございます。早速試してみます。
あと、ビデオ関連の削除の件ですが、ソースを丸ごと(ビルド関連ファイルを含めて)アーカイブして、公開できませんか。ビデオが無くなることで、音がどの位変わるか、是非試してみたいので。
ソース丸ごと以下にアップロードしましたのでお試しください。
バージョン1.1.6をベースにしたものです。
ビデオ関連を削除した目的は、単純に使用ライブラリを含めた最小化です。lightMPDへの組み込みを考えていましたのでlightにこだわりました。
【アップロード先】
https://drive.google.com/file/d/0B9LSJY9xM01jRGk1RHFKWTg2a3M/view?usp=sharing" target="_blank">https://drive.google.com/file/d/0B9LSJY9xM01jRGk1RHFKWTg2a3M/view?usp=sharing
【ファイル名】
minidlna-1.1.6-dsd.zip
【注意点】
(1)以下のオプションは使用出来ません。
inotify=yes
enable_tivo=no
(2)起動直後やDBの更新後はLibraryの情報が表示されないことがあります。Libraryを選択し直してください。
> debian-jessie-nasをインストールする必要はなく、他のlinuxでも良いことになりそうですが。
その通りだと思います。
やりたいことに対して必要なPKGが分かっていれば慣れたOSに組み込むのが良いと思います。SDは簡単にバックアップ・リストアが出来ますのでいろいろとチャレンジできます。私の場合「ubuntu-minimalで試し、lightMPDへ持っていく」ということをしています。
参考までに私のDLNAサーバ関連について書いておきます。
何かのヒントになれば幸いです。
(1)NAS
RockDiskNextに対して以下対応
・ssh導入
・自動サムネイル作成停止
・ほぼすべての機能を停止
※ファイル転送時のみsambaを起動
(2)DLNAサーバ
RaspberryPi2用のlightMPDに対して以下対応
・upmpdcliによるUPnPのレンダラー化
・polipoによるデータのキャッシュ対応
・Java(1.7.0_60)をRaspbianから拝借
・MinimServerによるDLNAサーバ化(DBはメディア保存)
・minidlnaによるDLNAサーバ化(DBはメモリ保存)
・sshfsマウント対応
・SDカードマウント対応
・USBメモリマウント対応
※マウントしたメディアをDLNAサーバにて公開
現在はRockDiskNextをsshfsでマウントしMinimServerで公開しています。
ソース一式公開ありがとうございます。活用するつもりです。
dlnaサーバの使い方によって、音がどう変わるかに興味があります。その意味では、donuts.shop73 さんの直前のメッセージに書かれた dlnaサーバの使われ方を大変興味深く拝見しました。
僕は今のところ、古いatom機をvoyageで動かし、samba、MinimServer、MiniDLNAを使って、音楽を聞いています(NanpPI NEO2サーバはバックアップ用です)。
この方法はWindows機を使ったファイル共用やSOCに直接USB接続でDiskを繋ぐ方式と比較して、こちらの方が音が良いので、決めたました。
しかし、dlnaを使い、タンデム方式でアダプターとプレーヤを分ける方式にした場合は、アダプター側にdlnaサーバを置く方法もありかなと思っています。また、サーバソフトによって微妙に音が変わるというも気もします。
ネットワークオーディオおいてCPU側の構成はdlnaを使ったタンデム方式で決まりだと思いますので、残されたフロンティアはdlnaサーバをどう配置し、どんなソフトを使うかですね。このあたり、いずれ新しいスレッドに書き込もうと思っています。よろしければ、お付き合い下さい。
Nanopineo2にArmbian(Debian-jessie)を入れ、minidlna、polipo、upmpdcliを組み込み、ポータブルUSBハードディスクをつないで、タンデム接続のアダプターの構築に成功しました。Armbianは、とくにカーネルをビルトしなくても、USBネットワークアダプタLUA3-U2-AGTを認識したのが幸いでした。もっとも、upmpdcli及びその前提となるlibupnp,libupnppのインストールはとても大変でした。apt-getではうまくいかず、ソースからコンパイルしたのですが、様々なlibraryが必要で、何度、./configureでエラーが出たのかわかりません。しかし、なんとか動作する状態になりました。USBの接続は、neopineo2標準のソケットでしかだめなようで、標準のソケットに、selfpowerのUSBハブを介して、ハードディスクとネットワークアダプタをつなぎました。
digififanさんのpolipoパッチはかけてありますか。あのパッチはハイレソ音源に対するノイズ対策です。
ありかは掲示板のどこかにあります。今年の春ころ。
devian-nas-jessieをインストールせずに、1-bay NAS Dock の内蔵HDDを認識する方法があれば、うまくいくのですが。
digififanさんのパッチはchunkが不足した場合の処理にも手が入れられているため、chunkHighMarkの指定が正しくされていれば再生が中断することはないと思います。
再生が中断した際にpolipoが落ちているようですとまずメモリ不足が原因だと思われますので設定を見直してみてください。(dmesgにもエラーが出力されていたと思います)。polipoが起動しているようですとちょっと分かりません。
ご教示有難うございます。たしかに、polipoが落ちています。chunk関連の設定をいろいろと変えて試してみることにします。
①polipoが落ちるケース out of memoryとのエラー表示あり
②polipoは生きており、中断後別のファイル再生はできるケース
、
https://volumio.org/direct-dsd-support-volumio-dsd512/" target="_blank">https://volumio.org/direct-dsd-support-volumio-dsd512/
ここを読むとRaspberryPiでもI2Sで出力出来そうな事が書いてある?様に思えるのですが
ついにサポートされたんでしょうか?
volumioで可能であれば一般のカーネルでも可能なはずですよね?
Volumioを使っていないので、よく分からないのですが、rpi対応のlightmpdだと、native dsdサボートは昨年の4月に公開された版(1.0.2)で対応されています。
https://sites.google.com/site/digififan/info/raspberrypiyongnolightmpd-v102wogongkaishimashita" target="_blank">https://sites.google.com/site/digififan/info/raspberrypiyongnolightmpd-v102wogongkaishimashita
従って、linux&mpdとしてもそれ以前からサポートされているということになりますね。
また、BBBだと2015年6月に公開されたv1.0.0でnative dsdサボートされていますので、linux&mpdのサポートはそれ以前ということになります。同じく2015年6月に公開されたapu.1c用のlightMPD-v1.0.0でもサポートされています。
ということで、Volumioの対応が随分遅かったということではないでしょうか。
As of now unfortunately no I2S DAC has this capability.
I2S DACはできないって書いてあります。
更に下の方には、DoPをOffにすれば変換してI2Sで通すとも書かれていますね。PCM変換するのでしょうね。
分かりにくい書き方でした(^_^;)
RaspberryPix+volmioでI2S出力を使ってDSD-native出力が
可能になったのか?という質問でした。
なのでkensさんの回答より やっぱり出来ない(^_^;)
という事ですね。
追伸
RaspberryPix + USB-DDCを使った場合でも
カーネルバージョン4.1.10以降 ALSAライブラリはバージョン1.0.29以降
であれば再生出来るはずです(^_^;)
yoさんの設定では、polipoをSDカードに保存する指定となっています。1bayDockでnanopineoを使い、upmpdcliとpolipoをインストールして、タンデム接続のアダプターとしていたものが、動作不良となり、調べたところ、polippのキャッシュファイルが肥大し、ディスクに空きスペースがなくなってまったとこが限でした。皆さんはこのような経験はないでしょうか?
ちなみに、lighMPDでは、polipoのキャッシュは保存しない設定となっているようです。
1 ブート時にキャッシュファイルを削除する。→ 保存と削除を毎回繰り返すことによるSDカードの損傷が心配。
2 POLIPOの設定ファイルで、キャッシュファイルを保存しないようにする。→当然ながら、メモリーを使い尽くしたというエラーが出る。もっとも、再生が止まるわけではない。
lightMPDではビルド時に -DNO_DISK_CACHE オプションを指定していますので、そもそもディスクへのキャッシュは無効化されています。SDへのキャッシュがどれ程効果があるのか分かりませんが、不要であれば上記オプションをお試しください。
ただ、NanoPiNeoですとメモリ容量が少ないため、同時に起動するAPLにもよりますが256MB程度しかキャッシュに割り当てられません。
ディスクキャッシュは特に指定しなければ、ディフォルトでオフになると思っていました。
大きな勘違いであったようですね(^^;;;。
http://mizushima.ne.jp/Windows/Proxy/Polipo/setting.php" target="_blank">http://mizushima.ne.jp/Windows/Proxy/Polipo/setting.php
# Uncomment this if you want to disable the on-disk cache:
# ディスクキャッシュを使用しないのならば有効化
# diskCacheRoot = "" # 有効にしたいのでここは放置
下記のページにご本家の解説があります。
https://www.irif.fr/~jch/software/polipo/polipo.html#Caching" target="_blank">https://www.irif.fr/~jch/software/polipo/polipo.html#Caching
このあたりは音質にも関連しそうだから、丁寧に対応する必要がありそうです。
polipoを使う時はカーネルの設定(kernel features)はRTではなく
No Forced Preemption (Server)
か
Voluntary Kernel Preemption (Desktop)
の方が良いと思うのですが、どうですかね。