iWRAP4.0.1を導入して、すぐと気がついたことがあります。それは、やはりAVRCPに関する動作でした。今回の記事では、WCA-009を使って動作の違いを確認するとともに、その原因を探ってみることにしまいた。
まずは、どこが違ったのかの説明から。iWRAP4.0.0ではiPadからBluetoothの接続をおこなうと、次のようにWT32上にイベントが表示されました。
それが、iWRAP4.0.1ではこのようになります。
一目瞭然、iWRAP4.0.1ではA2DPだけでなく、AVRCPについても接続されています。本来、こうあって欲しかったのですが、iWRAP4.0.0ではA2DPはつながるものの、AVRCPはつながりませんでした。しょうがないので、callコマンドを使うことでWT32側からAVRCPのリンクを張っていました。どちらの場合も、iPad側はiOS 5.0ですので、この動作の違いが生じる要因はWT32側にあることになります。iPad側から接続手続きが始まっているので、AVRCPのプロトコル動作が原因では無いということもわかります。すると、原因はWT32が公開しているSDP情報の違いに起因していると推測することができます。
と、いうわけで、WT32が提供しているSDP情報を調べてみることにします。使うのはいつものようにLinux上のsdptoolです。まずは、iWRAP4.0.0の場合。
そして、こちらがiWRAP4.0.1の場合。
ほとんど同じような内容ですが、よく見るとiWRAP4.0.0ではA/V Controller ServiceにおいてService Class ID Listが含まれていなかったことがわかります。つまり、iPadではこのService Class IDを確認してAVRCP接続を起動するかどうかを判断していたのですね。実はiWRAP4.0.0を使った場合でも、AVRCPをtarget側に設定した時にはちゃんとService Class ID Listは出ていました。ですから、controller側でSerivice Class IDが出ていなかったのは、iWRAP4.0.0でのバグだったのですね。
iWRAP4.0.1でつないだ場合に
まずは、どこが違ったのかの説明から。iWRAP4.0.0ではiPadからBluetoothの接続をおこなうと、次のようにWT32上にイベントが表示されました。
それが、iWRAP4.0.1ではこのようになります。
一目瞭然、iWRAP4.0.1ではA2DPだけでなく、AVRCPについても接続されています。本来、こうあって欲しかったのですが、iWRAP4.0.0ではA2DPはつながるものの、AVRCPはつながりませんでした。しょうがないので、callコマンドを使うことでWT32側からAVRCPのリンクを張っていました。どちらの場合も、iPad側はiOS 5.0ですので、この動作の違いが生じる要因はWT32側にあることになります。iPad側から接続手続きが始まっているので、AVRCPのプロトコル動作が原因では無いということもわかります。すると、原因はWT32が公開しているSDP情報の違いに起因していると推測することができます。
と、いうわけで、WT32が提供しているSDP情報を調べてみることにします。使うのはいつものようにLinux上のsdptoolです。まずは、iWRAP4.0.0の場合。
そして、こちらがiWRAP4.0.1の場合。
ほとんど同じような内容ですが、よく見るとiWRAP4.0.0ではA/V Controller ServiceにおいてService Class ID Listが含まれていなかったことがわかります。つまり、iPadではこのService Class IDを確認してAVRCP接続を起動するかどうかを判断していたのですね。実はiWRAP4.0.0を使った場合でも、AVRCPをtarget側に設定した時にはちゃんとService Class ID Listは出ていました。ですから、controller側でSerivice Class IDが出ていなかったのは、iWRAP4.0.0でのバグだったのですね。
iWRAP4.0.1でつないだ場合に
AVRCP GET_CAPABILITIES_RSP REJというイベントが表示されていますが、この意味するところは、今のところ不明。avrcp pduコマンドをつかってGET_CAPABILITYを送ってみると、サポートするイベントはちゃんとひろうことができています。iWRAPのAVRCPスタックが自動的に何やらリクエストを送っているのでしょうが、それが何なのかはわかっていません。
