A2DP audio intermittent drops while the device inquiry

QCT Technical Memo

Subject: Bluetooth Inquiry Effects on ACL Data Streams

1. Scope

This document will describe the technical aspects of the Bluetooth inquiry process and how this process may affect other data streams currently being serviced. For the sake of brevity, only basic inquiry will be considered by this document. The concepts presented here will be valid for Extended Inquiry Response (EIR) scenarios as well.

Note: Affected Bluetooth SOC platform
1) BTS402X - all H/W revisions on BTS4025/BTS4020
2) QTR8k - all H/W revisions on QTR8600/QTR8200
3) WCN2243 - all H/W revisions on WCN2243 BT/FM SOC

2. Definitions
2.1. Inquiry
The inquiry process is the name of the Bluetooth process for a device to discover any available peers within range.
2.2. Inquiry Master
The inquiry master is the device that is actively seeking other Bluetooth devices in range. This device may also be known as the inquiring device.
2.3. Inquiry Slave
The inquiry slave is the device that is making itself visible to other Bluetooth devices. This device is said to be "discoverable" to other Bluetooth devices.
2.4. Inquiry Process
When an inquiry slave is put into "discoverable" mode, this device will listen for inquiry requests from any inquiry masters within range. When in discoverable mode, the inquiry slave shall open a correlation window for a given period of time listening for an ID packet containing the General Inquiry Access Code (GIAC) type from potential inquiry masters. In order to be power-efficient, the inquiry slave will not open its correlation window indefinitely. Instead, the correlation window shall be opened periodically. The default configuration is to have the correlation window open 11.25 msec at a single frequency at a periodicity of once every 2.56 seconds

The inquiry master will actively attempt to discover an inquiry slave by transmitting ID packets containing the GIAC and listening on the prescribed response frequency. All transmit and receive slots during the inquiry process are spaced 312.5 usec apart. The ID packets sent as part of the inquiry process can be set on any of 32 frequencies. There are two "frequency trains" of 16 frequencies each. The "frequency" train changes every 1.28 seconds based on the devices current Bluetooth Clock. Based on these timing characteristics, the inquiry master will test all 16 frequencies of a train every 10msec ( (312.5 usec * 16 receive slots) + (312.5 usec * 16 transmit slots)).

The inquiry slave's correlator is receiving data on a single frequency for 11.25 msec every 2.56 seconds. This timing indicates that there will be a single packet from the inquiry master (312.5 usec) that can be correlator over the entire period of the inquiry slave (2.56 seconds). Because these two devices are not synchronized during the inquiry process, the inquiry master must utilize 100% of the Bluetooth bandwidth for a minimum of 2.56 seconds in order to guarantee device discovery in perfect signal conditions with only two devices. With more than two devices, it is recommended for a much longer duration.

From the Bluetooth Core 2.1 + EDR Specification, Section 8.4.2:
In order to collect all responses in an error-free environment, at least three train switches must have taken place. As a result, the inquiry substate may have to last for 10.24 s unless the inquirer collects enough responses and aborts the inquiry substate earlier.
The timing synchronization requires three train switches by the inquriy master to ensure adequate inquiry performance. In the absence of SCO (Synchronous Connection Oriented) channels which require reserved Bluetooth slots, this duration may be as much as 10.24 seconds. If SCO channels are present, the time requirements are significantly higher.

3. ACL Data Interaction
In the absense of existing SCO channels, the inquiry process will require 100% of the inquiry master's available Bluetooth slots. This will have an adverse effects on ACL (Asynchronous Connection oriented Logical) channels. Specifically, while the inquiry master is performing the inquiry process, no ACL data will be allowed to be transmitted to existing connections. These data stalls will likely not be perceivable on non-realtime data streams such as those used in the FTP, OPP, or DUN profiles; however, there will be a noticable effect on realtime data streams such as A2DP.

4. Conclusion
The A2DP audio distortions occur because of ACL data stalls which are caused by implementing the recommended prioritization of the inquiry process over existing ACL data streams.