Technically Impossible

Lets look at the weak link in your statement. Anything "Technically Impossible" basically means we haven't figured out how yet.

Windows 10でのBluetoothパケットキャプチャ - そのイヤホンで本当にaptXは機能している?


以前、Wi-Fiボードの紹介に関連してBluetoothコーデックに触れたことがあった*1。特にaptX*2のようなベンダー固有のコーデックが機能するには、次のポイントを満たす必要があることについて触れた。

  • 送受信側の双方が同じコーデックをサポートしていること
  • コーデックがインストールされていること
  • インストールされたコーデックが機能していること
  • コーデックのライセンス料が支払われていること

例えば、aptXを搭載していながら機能しない、ということが実際にある。あるいはWindows 10はaptXをサポートしている*3のだが、接続中のイヤホンとの通信に使用しているコーデックを示してくれない。
イヤホンが真に利用可能なコーデック、あるいは現在接続中のイヤホンが使用しているコーデックを明らかにする方法はないものだろうか。

今回の投稿では、それを明らかにする方法、その作業手順を紹介する。

前提

この投稿での作業は、次の環境で検証した。

version
Windows 10 Pro 21H2 19044.1766
Wireshark*4 3.6.2
Microsoft Bluetooth Test Platform (BTP)*5 1.12.2

BTPで提供されるツールのうち、特にBluetooth Virtual Sniffer (btvs.exe)*6を使用する。デフォルトのインストール・パスに基づくと、次の場所に格納されている。

C:\BTP\v1.12.2\x86\btvs.exe

注意事項

作業に着手する前に、出来れば一切のBluetooth機器の接続を解除しておくと良い。Wiresharkが目的のイヤホン以外のパケットをキャプチャしないようにするためだ。

次にソフトウェア起動とイヤホン接続の順序だ。具体的には、以下の手順を経る。

  1. btvs.exeを起動→自動的にWiresharkが起動
  2. Wiresharkがパケット・キャプチャを開始
  3. イヤホンを接続

イヤホン接続開始のネゴシエーション処理のパケットを検証する必要がある。そのため順番は、必ずソフトウェアが先、イヤホンが後だ。

さらに必ずイヤホン側から接続要求すること。Windows側からペアリング済みのイヤホンを指定して接続要求するのではない。どちら側から開始するかによって、ネゴシエーション手順が変化するのだ。

ネゴシエーションを会話に置き換えて説明すると、次のようになる。

子機 イヤホン
親機 Windows

イヤホン側から開始
子機「繋がせてください」
親機「どのコーデックが使えますか?」
子機「〇〇と××と□□です」
親機「〇〇でどうぞ」

Windows側から開始
親機「繋ぎますか?」
子機「〇〇でお願いします」
親機「〇〇でどうぞ」

Windows側から開始すると、実際に使用するコーデックしか特定できない。利用可能な全てのコーデックを特定するには、イヤホン側から開始しなければならない。

最後にもう一つ。コーデックが利用可能だからと言って、必ずしもユーザーが希望するコーデックで接続できるとは限らない。例えば、イヤホンがaptXに対応していると宣言しても、SBCで接続することはあるのだ。この点も合わせて、実例で確認してみよう。

実作業

”C:\BTP\v1.12.2\x86\btvs.exe”を実行すると、次のWindowが表示される。「Full Packet Logging」を選択する。
同時にWiresharkも、自動的にパケット・キャプチャ開始状態で起動する。この状態でイヤホンをBluetooth接続すると、ネゴシエーション以降のパケットがキャプチャされ続ける。

注目したいのは、次に該当する行だ。

Column
Protocol AVDTP
Info Command - GetAllCapabilities ~
Info ResponseAccept - GetCapabilities ~
Info Command - SetConfiguration ~

"Command - GetAllCapabilities"というPCからイヤホンへの問いかけに対し、”ResponseAccept~”でイヤホンが対応しているコーデックを回答する。一連の確認を終えると、PCからイヤホンへ、"Command - SetConfiguration"で接続に利用するコーデックが指定される。

次の例では、

に対応していると宣言し、接続にaptXが採用されたことを表している。

この状態で動画や音声を再生すると、aptXのパケットをキャプチャし続ける。つまり、実際にコーデックとしてaptXが機能しているのが分かる。

次の例は、Command、ResponseAcceptの立場が、PCとイヤホンで逆転しており、イヤホンがSBCでの接続を選択している。PCはaptX、SBCに対応していると回答したものの、SBCで接続することになった例だ。結果として、コーデックとしてSBCが機能しているのが分かる。

なぜそのようなことが起こるのだろうか。究極的には、何らかの判断基準に基づいたOS、あるいはイヤホンの選択なのだが、加えて次の2つの可能性が考えられる。

  1. コーデックの優先順位
  2. デジタルコンテンツ保護

ResponseAcceptで宣言しているコーデックの順番を注意深く比較してみて欲しい。SBCを真っ先に宣言するデバイスと、aptXのようなSBC以外のコーデックを真っ先に宣言するデバイスがある。SBCで接続しているのは前者だ。つまりコーデックの優先順位が反映された結果として、aptXで接続できない。

一般的に、ユーザーはこの優先順位を変更できず、公開すらされていないのだが、特定のベンダーは優先順位の切替え方法をサポートページにて公開している*7

もう一つの理由はデジタルコンテンツ保護の有無だ。以下の画像は、aptX対応を宣言していながらSBC接続した例と、aptX接続した例のパケット比較だ。aptX接続したパケットにはSCMS-T*8が宣言されているのが分かる。

つまり、ただaptXに対応しているだけではダメで、SCMS-T(デジタル保護)にも対応していないと、WindowsはaptX接続を受け付けない。
あるいは接続だけはできる場合があるのかもしれない。その場合、ワンセグ放送の様なデジタル音声保護された音声は再生されないだろう。

余談

いわゆる中華製品に限らずだが、商品説明の一部に対応コーデックを列記している製品は多いのだが、デジタルコンテンツ保護対応を明記している製品を見かけたことは無いし、Amazon等の商品説明で、それに触れている事例を目にしたこともない。

ほとんどのユーザーは、ただ書いてあることを盲信し、書いてある機能が期待通りに動作していると無根拠に満足している、というのが実態なのではないだろうか。

その程度の、違いも分からないし理解もできないユーザーなのだから、マーケティングに通じる説明をしたほうが良い、と考える結果なのか、あるいはマーケティングに載せられた、騙された帰結としての有様なのかは、鶏卵論争だが、これだけは言える。ベンダーはもう少しまともな情報を公開したらどうだろうか。

商品説明や仕様からaptX対応しているのは分かる。しかし、それが真に機能する前提は整えられているのだろうか。実際、Bluetoothイヤホンはネゴシエーション中にaptXに対応していると主張している。しかし、それが受け入れられていない環境が存在しているのだ。
ベンダーは、もう少し仕様と、その前提に真摯に向き合う必要があるのではないか。

参照

habr.com