オーディオヘルスモニター (9)UPnPへの船出 – らうとしゅぷらっひぇん@びちだすとらーだ

タグ:

アルバムアートワークの構想

表現も情報量も随分とリッチになってきた、我が家の「オーディオ・ヘルスモニター」。
単にリッチになるだけでなく、監視領域を徐々に広げてきた感じです。

Roon ROCKの内部稼働状態、メモリの空きなど
ROCK外側の温度、湿度
ROCK外側のファンノイズとスペクトル
WiiMの現在状況
WiiMの入力ソース
WiiMの再生中の曲名などトラックメタデータ
ESP32の動作状況

など。

そして、ここまで来たなら「アルバムのアートワーク」もダッシュボードへ表示したい。
ここ数週間はそこへチャレンジしていました。

これまで、私たち（私＋ちゃっぴー）は、WiiMアクセスにHTTP APIのみを利用していました。

この場合、ESP32が能動的に情報を取りにいかなければならない。だからレスポンスは悪い、
しかもこの経路だと、アートワーク（ジャケット写真）までは採れないんですよね

そこで、調査をすすめる中、とんでもない事実に行き当たりました。

UPnPの存在

WiiM… というよりもLinkplayは、

再生中にuPnP経由でDLNA的に周辺へ情報をブロードキャスト

しているのだと。
WiiM Ultraの3.5インチ液晶に表示されているジャケット画像や曲情報を外部…例えばオーディオ装置、PC、自作アプリなどへリアルタイムで同期・表示させたい場合、HTTP APIではなく UPnP (SSDP) のイベントサブスクリプション（Notify）機能を使用するのが、現在では世界的標準となっているという。
こういう存在を、「UPnP（DLNA）MediaRenderer」と呼びます。WiiM Ultraは起動中にネットワーク内に情報発信サーバーとして稼働しており、曲が変わるたびに「今のジャケット画像URLはこれです」といったXMLデータを周囲にブロードキャストしています。
もう少し正確にいうと、SUBSCRIBEした相手にのみ、「曲が変わったよ」という発信(Notify)を投げ、受信者がメタデータ等を取得可能にしている。

待ち受けていれば、情報変動と同時に最新情報がPushされてくるイメージなので、即時性も優れています。

なぜLinkplayはそんなことを？

LinkplayはWiiMを「単なる矮小ないちオーディオ機器」として捉えていないんですね。家庭内における「メディアハブ」になろうという野心がある。Linkplayは家庭内の「音楽の司令塔」になりたいのです。単なる「再生機」ではなくて、家庭内の「ルーティング」「配信者」になろうとしている。だからWiiMは家庭内のあらゆる装置…たとえば有線オーディオだけでなく、ネットワーク装置、Bluetoothオーディオなどへ、DLNA的に「音楽配信」を可能とするハブになります。そのとき、音楽のストリーミングだけでなくメタ情報も送ら「ねばならない」のは必然の流れです。だからこの世界のデファクトであるUPnP経由での情報ブロードキャストを行なっているわけ。ちょっと難しい話だったかな？

情報経路探検

まあなんにせよ。このUPnPの仕組みを利用すればアルバムジャケット表示も夢では無いというのです。

ただ、さすがに今回は一朝一夕ではいかなかった。採れそうということは分かっても、どこに何が収納されるかは実際にAPI叩いて解析しないとパースもできない。
よって、実装するというよりは、調査・探索をすすめていたという表現が当たっています。

ESP32は、MacやWin上で直接コードを走らせるよりも、さまざまな視点で都合がよろしい。自前でウェブクライアントにもウェブサーバーにもどちらにでもなれるし、APIを引っ叩いて戻り値をシリアルに垂れ流すのも自由自在。

だから、やっていたことは

ESP32を使って探索機を作り
あらゆる鉱脈を掘って、分析して、そして掘り進める方位を決めていく。

ESPはAPI探索機にもなれてしまうというのだから、本当にすごい存在です。
以前私は「金鉱脈」という言い方をしましたが、まさにそれ。チャッピーと組んで「こっちか？」「いや？むしろこっちじゃね？」わずかな情報量から、鉱脈の痕跡を見つけて、そこを掘り進めていく。間違っていたと感じたらリバートする。不思議と焦りはありませんでしたね。バージョン管理はしっかりやっているし、ウェブダッシュボードも半完成しているから、じっくり掘ればいい。間違ってたらいくらでもリバートできます。

探索プロセスを詳述していると夜が明けてしまうから、ざっくり言えばこんな図式です。

探索図

いろいろ名称が出てきますが、気にしないでください。個々が鉱脈であり、金のありかの片鱗であったり、はたまた金のありかがズバリ描いてある宝地図であったりしました。
最初はESP32を使ってSSDP探索マシンを作り、いろいろ叩いてXMLを片っ端から探索するというところから始めました。rendertransportSCPD.xmlのURLをゲットするまでが、結構長かった・・・。

rendertransportSCPD.xmlの在処。
私の場合でいうと、以下のURL。

http://192.168.3.＜WiiMのIPアドレス＞:49152/upnp/rendertransportSCPD.xml

そして、得られたXMLが・・・

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<scpd xmlns="urn:schemas-upnp-org:service-1-0">
//　中略　ここです！
<action>
<name>GetInfoEx</name>
<argumentList>
<argument>

・・・
この[GetInfoEx]こそが、金鉱脈だったのです。
他にもトラックのメタデータが入った入れ物はいくつかりました。しかしコレは、それらとタマが違う。
Linkplay特有・固有の構造体であり、一般性はないが、そのぶん「思い切り」拡張されている。これの中に「入っていない情報は何も無い」と言えるほどの「全部入り」だったのです。

そのことが分かったので、他のXMLや入れ物をパーシングするのは全部やめました。このGetInfoExだけで十二分だからです。
Trackのメタデータは、この中のさらに[TrackMetaData]の中へ入れ子構造で収納されているようです。
このように、UPnPというのは、直接に情報にはなかなか辿り着けず、ありかが書いてあり、そのありかに行くとまたありかが書いてあり、そのありかには詳細地図が書いてあり、その地図を掘り進めていくとようやく目的情報に辿り着けるという、超・多重DB構造で配信されているのでした。

そこへ収納していることはわかりましたので、今度はそれをSOAPで取りに行くわけです。

◾️SOAPとは？

「XMLを使って機器へ命令したり、情報を取得したりするための通信方式」です。
HTTP POSTで本文はXMLで送る。
すると返答もXMLで返ってくる。
これはUPnPでは標準的な制御方法です。

私の場合のSOAP_URLはこれでした。（このURLを探り当てるだけで大変な苦労）

”http://192.168.3.＜WiiMのIPアドレス＞:49152/upnp/control/rendertransport1”

そしてアルバムアートワークのURLは、このSOAPで採取したGetInfoEXのXMLの下記の部分へ記述されていました。

<upnp:albumArtURI>https://192.168.3.＜Roon-ROCKのIPアドレス＞/data/roon_image_69_83262.jpeg</upnp:albumArtURI>

なんと、画像のパスはRoon ROCKの内蔵ストレージの下であった・・！そして、WiiMはそれをリダイレクトして表示していたのです。

今回の発掘で、それぞれのAPIの棲み分けがはっきりしました。

利用項目	HTTP API	GetInfoEx
タイトル	◯	◯
アーティスト	◯	◯
アルバム	◯	◯
Artwork URL	×	◎
サンプリング周波数	◯	◯
BitDepth	◯	◯
Volume	×	◯
Mute	×	◯
TrackDuration	×	◯
再生位置	×	◯
TransportState	◯	◯
TrackMetaData	×	◎
INPUT Source	◯	×

結論からいうと、従来のHTTP-APIも必要です。
WiiMの入力ソースの状態を取得したり、それを切り替え操作したりするにはHTTP-APIは必要です。

そして、どドーン。
ついに、オーディオヘルスモニターのダッシュボードへ、再生中のアートワークも出るようになりました。
もはや、単純な監視ダッシュボードの域は逸脱した感じがします。美しすぎる・・・！

こちらはBluetooth入力の場合。（スマホ音源）
こちらもアーティストやタイトル等のメタ情報は表示できますが、さすがにアートワークは表示できません。Roon再生ではないから、ローカルに画像受け継ぎ情報が無いのです。

Roonの場合は、ROCK内部ストレージの画像パス情報がWiiMに飛んでおり、それをリレーできているのですね。
　

入力ソースをウェブから「切替」も可能に

今のこの部分

入力ソースインジケーターはあくまで、現状のステータスを表示しているに過ぎません。
しかしここをクリッカブルにして、切替の操作も可能にしてしまいます。

オーディオ・ヘルス・モニターとしては、以下の視点やユースケースもあるからです。

あれ、音が出ないな
なんだ、入力がBluetoothになってるからか
今すぐRoonへ切り替えたい

見えているのに、それを触れないのは単純にUXとしてジレンマがあるからです。
もうひとつあるのが以下の視点。

WiiMのリモコンは入力が「トグル」なので、操作が面倒かつダイレクト感がない
おまけに入力切替の表示遅延があるから、リモコンだとオーバーシュートしてしまう場合がある
アプリは瞬時切替可能だが、まずWiiMデバイス選択をしなければならないし、UI階層も深すぎる。

だからこのダッシュボードに入力切替操作をつける事には価値があります。

このボタン切替の実装もかなり苦労しました。
GetInfoEXの機能拡張をしていく過程で「input」「input_mode」「mode」などの変数名や、収納する引数としての名前と表示名などが複雑に混濁して、動かなくなってしまう瞬間が何度もありました。
丹念に引数と変数名を整備して解決していきました。

結果のフルコードは [こちら] です。

そしてとうとう、ここのインジケーターはステータス表示だけでなく、操作も身につけてしまいました。

最初は「温度とノイズレベルだけ数字で見れればいいや」といって始めたこのプロジェクト。
いつの間にか情報は多次元で広範になり、そして開始当時からは随分と遠いところへ来てしまったという感慨があります。なにより、このリッチなダッシュボードが小さなESP32の基板「だけ」で成立していることが俄かには信じられません。まさに「小さな巨人」とでも言って良いんじゃないでしょうか。

なりは小さくても、ウチのネットワークノードの中で無くてはならない監視塔・司令塔にもなりましたし、立派にIoTの一員にもなったと思います。