「中華タブ買って、HDMI出力をアンプに入れて、タブからNASを見に行って音楽再生させたいんよね。」
「ほぅほぅ、いわゆるDMRってやつね」
「そそ。で、Androidアプリを探してみたけど、これが全然見つからない。」
「あら意外。DLNAアプリって結構見つかりそうなもんだけれど。」
「自分がDMCとかDMPになるアプリはあるけど、DMRはないんよなぁ。」
「あーまぁ、そらそうか。スマホやタブレットをレンダラーにする需要はあんまりなさそうやからなぁ・・・」
「そうなんよなー。毎回毎回タブレットを操作してるけど、できたらスマホからタブレットを操作したい。」
「なければ作ってみるかー？ 多分フリーソフトがあるってことは仕様も公開されてるんでしょう」
って感じで作ってみようという事に。
まずはDLNAライブラリを探す。フリーソフトが出てるってことはきっとライブラリがあるのだろうとかって思ったけど思いの外無いのな！
Androidにも対応してるのでまず見つけたのがこれ。
対応Androidバージョンは2.1、一部2.2から。中華タブは4.0なので全く問題ないですね。
サンプルもあるしドキュメントも充実してるし、なかなか良さ気な感じ。
ただ、肝心のメディアレンダラーのサンプルがGStreamer使ってる。。。 ここは自分で実装しなさいという事に。
まーしゃーないな、とりあえず通信の流れを調べないとなーって思ったけどソースコード見てても正直よく分からん。。。
DLNAってちゃんとした規格？ なんだし、どっかにドキュメントくらい落ちてるだろうって思って探したけどこいつがほんっとに見つからない！ どうなってんねんというくらいに見つからない。DLNAの規格団体？のHPとか行ってみるけどドキュメント類は見つからない。
で、途方に暮れながら色々と調べていると見つかったのがこのツール。
なんかネットワーク内にあるDLNA（というかUPnP）デバイスの仕様を調べるのに便利なツールと、それらのツールのソースコード、さらにはプログラムのスケルトンを作ってくれるコードジェネレータがセットになった太っ腹なツール！ Intelが公開しているようで、ライセンスはApache-2.0。素晴らしい。実に使いやすそう。
で、ようやく見つけたドキュメント類！
UPnPの団体の方を当たらないといけなかったか・・・。それは盲点だった。
で、DMSやらDMCやらDMRやらの用語が出てくるのかと想ったらそこはそうでもない。それはあくまでDLNAの範疇であって、UPnPでは
・DMS = Content Directory
・DMR = Media Renderer
・DMC = Control Point
と微妙に呼び方が違ったり。最初混乱したぜ・・・。
で、それらが通信する仕組みを理解してくるにつけ、
「あぁ、こいつらそりゃDLNA1.5準拠とか言っててもそりゃ繋がらねぇわ」
という思いが強まってくる。
なんせ、「UPnP」それぞれのサービスで規定されている事柄は非情に多岐にわたるんだけど、必須条件はかなり限られる。再生できるフォーマットの必須条件がかなり少ないのは調べてすぐ出てくる話だから知ってたけど、メディアデータの通信コントロールの実装がオプションだとは知らなかったわ・・・。
UPnPデバイスは「サービス」って言われる、UPnPで定められた役割をいくつか実装してるらしい。
例えば"Connection Manager"サービス。
まずLAN内にブロードキャスト飛ばして、
「おるかー？」
って聞いたり
「おるでー」
って答えたり、
「おぉお前さんどんなメディアとプロトコル扱えんの？」
とかのやりとりをする。
で、DMSが自分の持っているメディアの情報をやりとりするのが"Content Directory"サービス。
他のコントロールポイントとかレンダラーからの問い合わせに対して
「俺の扱えるMIMEタイプってこんなんやでー」
とか
「そのファイルのタグ情報はこれやでー」
みたいなやりとりをする。DMSはCMSとCDSの２つが必須。あとはオプション。
続いて、DMRが自分のプレイヤー状態をやりとりするのが"Remote Control"サービス。
これはまさにリモコン。特にテレビのリモコンをイメージするといいかな？
音量調整やら画質調整などを行う。DMRはCMSとRCSの２つが必須。あとはオプション。
そう、実はDMSとDMR、これらのデバイスって、必須条件はこれだけ。
メディアファイルをやりとりするサービスは両者ともにオプション扱い！
まぁ実際のところ、メディアをやり取りする"AVTransport"サービスについては多くの場合レンダラーが実装しているようです。いわゆるDMPですね。
まぁしかし、こうしたややこしい通信規約を見ると、そりゃ相性やらなんやらって出てくるわけだわ。メディア情報を見るための通信経路と実際にファイルをやり取りする経路は別だし。
ということで、ようのようやく概要を理解できてきたのでIntelのツールを使ってスケルトンコードを作り、その中身を実装していきたい所存。
ただ、それもかなり難航中。。。 ソースコードはまるっとあるからありがたいけど、ドキュメント類は特になし。。。 手を加える部分というか、見える部分のソースにはコメントが結構ついてるけど、そうじゃなくてライブラリとして使っちゃう部分はほぼコメント無し。ただ、APIのシグネチャにもコメント付けられてないからその関数が何をするものか、引数に何を与えるべきかはサンプルプログラムを見たりするしかない。。。
そこがちょっとしんどいかな。サンプルがあるだけマシと見るべきか・・・。
いやーにしても、ちょっとややこしいところに手を出しちゃった感じがするなぁ・・・。
分かってはきたけど逆に深みにハマっている気もする・・・ｗ
はじめまして。記事を興味深く拝見しました。やりたい事（作りたいもの）があるのですが・・・。この辺りの事なのですが、不案内でできません。お忙しいところ申し訳ないのですが、力を貸していただけますか？
返信削除DMR = Media Renderer を小さな組み込みボードに実装したいのがやりたい事です。
よろしくお願いいたします。
はじめまして。
返信削除組み込みとなると私がお役に立てるような部分があるかはとっても不安ですが、私の分かる範囲であれば・・・。
ご返信ありがとうございます。
返信削除特にこのボードという指定は無いので、使いよいLinuxが動くμPが載ったのを探してみたいと思います。
具体的に依頼したいのですが、どのようにご連絡を取るのが望ましいでしょうか？
誠に申し訳ないのですが、当方、Twitterアカウントは持っておりません。google+はあります。
よろしくお願いいたします。
Linuxということであれば、gUPnPのライブラリが用意されているディストリビューションだとかなり開発が楽になるのではないかと思います。
返信削除依頼となりますと、お仕事ということですか？
私はプロのプログラマではありませんし組み込みも経験ございませんので、それならば他を当たられたほうが良い気もします。。。
雑談程度と申しましょうか、そのくらいでよろしければ構いませんが・・・。
私の方はサイトの右上の方に有ります通り、G+もアカウント有りますのでそちらを叩いていただいても結構ですよー。
ご丁寧なお返事ありがとうございます。
返信削除依頼と言ったのは、ご自身の目的でないことも時間を割いてやって頂くには何らかのお礼がしたかったと思いまして、成果をコミットして頂くお仕事という意味ではありません。ほんの気持ちなのですが、表現したかったので・・。
”gUPnPのライブラリが用意されているディストリビューション”ということさえもパッと出てこないLinux素人ですので、お力になっていただけますと助かります。
G+も自分で言っておきながら、全く使っていなかったので使い方も分かりませんでした。失礼しました。
ここにあるようなボードに載っている（載る）Linuxでもできそうですか？
http://armadillo.atmark-techno.com/products
お手数お掛けしてスミマセン。
Armadilloでしたら
返信削除Armadillo-500 FX 液晶モデルでDebian lennyを使う | 組み込みLinuxのArmadilloサイト っ[ http://armadillo.atmark-techno.com/howto/a500fx-debian-lenny-x ]
第4章 Armadillo上にDebian GNU/Linuxを構築する っ[ http://manual.atmark-techno.com/armadillo-guide/armadillo-guide-2_ja-2.0.1/ch04.html ]
なんて記事が見つかるので環境構築は大丈夫じゃないでしょうか。
後はスペック的に満足なパフォーマンスが出せるか、ですがそこはなんとも言えませんね・・・。
内容を見ていただきありがとうございます。
返信削除Armadillo-500 FX 液晶モデルで環境の方は、可能性があると聞けて助かります。
音声データの受信とその付帯処理はそれほど高負荷とは思っていないのですが、パフォーマンスの方は実機確認になりますかね。
実験前にパフォーマンス上に心配なところは何か思い当たりますでしょうか？GUIに凝るとか、そういうところは必要ないと考えております。
受信データの曲目（ファイル名なのかな）と、サンプリング周波数、可能なら再生時間のカウントが表示できればと思っております。
環境構築が出来てからの、作業は結構大変でしょうか？
多分すんなりとは行かなくて、大変ではないかと予測しておりますが・・・
どんな感触でしょうか？
Armadillo-800 EVA でも可能性はあるでしょうか？
返信削除こちらの方が少し安価なので、実験用に買うとなると助かりますので・・・。
＞受信データの曲目（ファイル名なのかな）と、サンプリング周波数、可能なら再生時間のカウントが表示できればと思っております。
返信削除このあたりであれば、DMCから大抵渡されますので（SetAVTransportURIというコマンドにて、ファイル名とともにトラック情報がまずはDMRに渡されます）、実際に再生せずとも情報の表示はできるかと。
＞環境構築が出来てからの、作業は結構大変でしょうか？
多分すんなりとは行かなくて、大変ではないかと予測しておりますが・・・
ある程度、PCで動くものを作ってから組み込みに持っていったほうがいいのだろうと思います。
パフォーマンス調整は実機でしかできないでしょうが。。。
＞Armadillo-800 EVA でも可能性はあるでしょうか？
そちらにもDebianあるようなので、環境構築は多分大丈夫なんじゃないでしょうか。
断言はできませんが。。。
とても参考になります。ありがとうございます。
返信削除＞実際に再生せずとも情報の表示はできるかと。
再生中の経過時間や、曲終わりませのカウントダウンについても、時間情報がある程度周期に送られてくるのでしょうか？カウントダウンは無くても良いが、経過時間は表示したい内容です。
＞ある程度、PCで動くものを作ってから
は、Nagomi Kode様のほうで本記事投稿時に既に作られたもの（そのまま流用は出来ないにしても改造すればなど）が有りますでしょうか？
ここから、一からの製作が必要になってきますか？
＞＞Armadillo-800 EVA でも可能性はあるでしょうか？
＞そちらにもDebianあるようなので
可能性があるなら、実験用に入手してみたいと思います。
勿論、動作せられないというリスクは承知です。
よろしくお願いいたします。
＞再生中の経過時間や、曲終わりませのカウントダウンについても、時間情報がある程度周期に送られてくるのでしょうか？カウントダウンは無くても良いが、経過時間は表示したい内容です。
返信削除それはさすがに送られてこないです。
というよりも楽曲の再生はDMR側で適当に実装しないといけません。経過時間はそこで制御することになります。
＞既に作られたもの（そのまま流用は出来ないにしても改造すればなど）が有りますでしょうか？
ここから、一からの製作が必要になってきますか？
んー、Android向けにはこの記事のちょっと後にちらっと実装は載せていますが、他のOS向けには実装したものはないです。ごめんなさい。
いつもありがとうございます。
返信削除＞んー、Android向けにはこの記事のちょっと後にちらっと実装は載せていますが、他のOS向けには実装したものはないです。
ArmadilloにもAndroidも乗せられるようですが、その線で少しはうまくいかないでしょうか？
Debianでもどうにかできると、道が二つになり、何かと良いのですが・・・。
パフォーマンスについてはわからないのですが、実装はできるはずです。
返信削除確か私が使ったツールはAndroid2.2以上を対象にしていましたので、そのままコピペでも多分動くんじゃないかと。。。
（いくつかよろしくない処理してるところがあるのでまるっとコピペはまずいですが・・・）
あと、Javaで使いやすいライブラリとしてはClingがいいと思います。あれもAndroid向けに提供されてますし。