Technically Impossible

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

Bluetooth packet capture on Windows - Is aptX really working in those earpieces?

Abstract

Followings are requirements that vender-specific codec as aptX*1 should work.

  • Both, sound source and sink support common codec.
  • codec is installed.
  • installed codec works.
  • license fee for codec has been paid

In spite of aptX is installed, it doesn't work. Or although Windows 10 supports aptX *2, aptX is not applied for earpieces. Such cases are not unusual.

This post introduces how to identify available codecs and codec in use.

Assumption

The work in this post was done in the following environment.

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

Among the tools provided by BTP, use the Bluetooth Virtual Sniffer (btvs.exe) *5. Based on the default installation path, it is stored at

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

Basic precautions

In advance of begining the operation, all Bluetooth equipments should be disconnected. It prevents Wireshark from capturing extra packets.

Packet capture with Wireshark should be started before connecting Bluetooth earpiece. Specifically, following steps will be taken.

  1. run btvs.exe, then autonatically run Wireshark
  2. start packet capture
  3. connect Bluetooth earpiece

These steps ensures to capture packets during Bluetooth negotiation between Windows and earpiece.

In addition, connection request should be started by earpiece, not Windows. Depending on which side starting from, negotiation procedure changes.
defining negotiation as conversation between Windows and earpiece, it is expressed as followings.

Host = Windows
Guest = earpiece

The case starting by guest
G: Please let me talk
H: What language do you speak?
G: EN, FR, JP, etc
H: JP please

The case starting by host
H: Shall we talk?
G: Is it ok to speak JP?
H: JP please

In the case starting by guest, all languages are opened, but the other case is not. This language is codec in actual operation, and to identify all available codecs, negotiation must be started by earpiece.

Finally, there is a case that in spite of expected codec is available, it is not always applied in communication. Example, earpiece says aptX is available, SBC is applied in actual communication. This topic is discussed later.

Operation

Run ”C:\BTP\v1.12.2\x86\btvs.exe”, the next window appears. Then, click "Full Packet Logging". Simultaneously, Wireshark appears, too. Packet capture is already initiated.


Connect Bluetooth earpiece in this situation, all packets including negotiation are captured.

Focus next records, ”ResponseAccept” shows codec supported by earpiece, and "SetConfiguration" indicates codec in use for communication.

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

Next sample shows codecs below, and indicates that aptX is applied for communication.

When video or audio is played in this state, Wireshark continues to capture aptX packets. aptX codec is working.

Next sample is the case that communication with SBC is established, though earpiece supports aptX and SBC. Actually, packet capture shows SBC is working.

There are 2 reasons considered below.

  1. Priority of codec
  2. Digital content protection

Carefully looking at codecs and their order in "ResponceAccept", will find that the one declares aptX first, and the other declares SBC first. And the former connects in aptX and the later connects in SBC, which means connection is established with prioritized codec.

Although such priority is usually hidden to user, certain vender opens how to switch priority on their support page as this*6.

The other reason is to missing digital content protection. Next image is comparison among packets in case of aptX communication is established or not. Packet in aptX communication indicates SCMS-T*7.

So, to establish connection with aptX between Windows are earpiece, digital content protection as SCMS-T is required. In other words, only supporting aptX is not enough to establish its communication. Even if connection is established, protected audio won't be played.