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.
The work in this post was done in the following environment.
|Windows 10 Pro||21H2 19044.1766|
|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
In advance of beginning the operation, all Bluetooth equipment 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.
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.
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, and "SetConfiguration" indicates codec in use for communication.
|Info||Command - GetAllCapabilities ~|
|Info||ResponseAccept - GetCapabilities ~|
|Info||Command - SetConfiguration ~|
Next sample shows codecs below, and indicates that aptX is applied for communication.
PC ask to earphones as "Command - GetAllCapabilities", and earphones respond ”ResponseAccept~” with codec information. And PC tells earphones codec with "Command - SetConfiguration"
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.
Choice of codec is ultimately decision by OS based on some criteria, though there are potentially 2 reasons considered below.
- Priority of codec
- 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.