Discussion

The test began without any issue. DUT1 and DUT2 negotiated a Bluetooth connection suitable for transmitting the audio. When the Reference Audio was played there were no obvious audio distortions or anomalies heard by the tester.

The tester used a ComProbe BPA 600 configured for capturing Classic Bluetooth over a single connection.

In Frame Display AVDTP Signaling tab we see the start of the negotiation between DUT1 and DUT2 to establish an audio connection, see "Frame Display for AVDTP Signaling Frame 2089 & 2092". At frames 2089 and 2092 the initiating or local device sends an AVDTP_DDISCOVER command. The remote device responds by identifying the ACP Stream Endpoint IDs. In this case the remote device identifies three audio media-type devices that are SNK (sink) devices currently not in use: SEPID (Stream Endpoint Identification) 5, 2, and 1.

 

Note: "ACP" is AVDTP terminology for the remote device.

The next step in the negotiation is to get the audio capabilities of each SEPID. For each SEPID there is an exchange of GET_CAPABILITIES AVDTP signals.

Examination of the Frame Display AVDTP Signaling protocol tab shows at frame 2116 the slave device request SEP (Stream End Point) characteristics. for SEPID (SEP Identifier) 5. Details of the GET_CAPABILITIES command are shown in the "Frame Display for AVDTP Signaling Frame 2116".

 

At frame 2119 the remote device responds to the GET_CAPABILITIES for SEPID 5 reporting that this SEP codec is aptX with a Channel Mode Stereo.

 

In "Frame Display for AVDTP Signaling Frame 2119", frames 2138 through 2158 perform the GET_CAPABILITIES negotiation between the local and remote device for SEPIDs 2 and 1. SEPID 2 is an MPEG SEP, and SEPID 1 is the SBC SEP.

Frames 2169 and 2175 sets the specific details of the connection with the SET_CONFIGURATION signal. The local device sets the remote endpoint to the aptX device (ACP Stream Endpoint ID: 5), and sets the local endpoint to SEPID 1 (INT Stream Endpoint ID: 2). The Codec, Sampling Frequency, and Channel Mode are also configured. See "Frame Display for AVDTP Signaling Frame 2169, SET_CONFIGURATION".

At frame 2175 the remote device sends the message "Response Accept" completing the audio stream setup.

Frames 2185 and 2190 are the local request and the remote response to OPEN the audio stream.

Frames 2823 and 2833 START the audio stream with the local request and the remote response respectively.

 

So far the process of setting up an aptX audio connection between DUT1 and DUT2 appears normal, correct and error free. We now move from he AVDTP protocol to the A2DP protocol to observe the audio.

Problem Discovery

In the ComProbe software, the audio data is shown in the A2DP tab in the Frame Display, see "Frame Display for A2DP Streaming at Frame 2839 with Audio Expanded". The frame 2839, which is the first audio frame, is identified as being aptX encoded because of the successful codec negotiation. At this frame, the conventional audio data analysis methods do not show any issues. Assuming the data is aptX encoded, the AES software passes it to the AES aptX decoder. However, the data was not decoded.correctly and is marked as a bad aptX frame.On further analysis, the AES software discovers that the frame is not aptX encoded but is actually SBC encoded. Frame 2839 begins with “0x9C”, and all SBC audio frames begin with sync word “0x9c” as shown in "Frame Display for A2DP Streaming at Frame 2839 with Audio Expanded". The AES cannot solely rely on the sync word to determine if it is a SBC frame. To confirm the suspicion, the AES passed the data through its SBC decoder, and the data came out cleanly decoded.

The AES software not only showed that there is a problem in the audio data but also made it clear where the problem is.

The Error that is identified by Event 4, the Severity red circle , is a codec event at Frame 2839 states "Unable to process AptX data as extracted. It appears that SBC encoded data is being sent over this stream."