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
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|
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.
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.
|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.
- 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.