Research on short-range wireless audio communication based on A2DP framework

Research on short-range wireless audio communication based on A2DP framework

With the increasing popularity of Bluetooth technology in electronic products, Bluetooth audio devices are also emerging one after another. Among them, the application of Bluetooth headsets and Bluetooth audio gateways with hands-free functions is the most typical example. However, the SCO connection established by the hands-free unit and the audio gateway for audio transmission can only support 64Kb / s carrier-grade voice quality audio streams, which limits the improvement of Bluetooth audio quality and also affects Bluetooth's entertainment consumer market. . In order to meet people's demand for high-quality audio and further expand the Bluetooth product market, the Bluetooth Special Interest Group SIG organized a separate advanced audio distribution framework (Advanced Audio DistribuTIon Profile, A2DP) based on the application framework of the Bluetooth 1.1 specification. The framework uses the ACL asynchronous connectionless link established at the L2CAP layer to transmit high-quality mono or stereo audio data, and the transmission rate of the payload can reach 300-400Kb / s.

Overview of the A2DP framework In the entertainment consumer market, the instantiated application of A2DP is to use a music player to send audio data to headphones or speakers through an ACL connection. The current framework specification does not support synchronous point-to-multipoint broadcast audio distribution, and there are two different roles for point-to-point audio distribution. One is the source equipment (SRC). The initiator sends the digital audio stream to the Piconet network; the other is the sink device, which is the device that receives the audio stream from the source. If the Bluetooth music player is the source device, the Bluetooth headset interacting with it is the sink device. The difference between the source and sink is whether it is the initiator or the receiver. The specific protocols involved in the framework and their dependent frameworks are analyzed below.

1 A2DP application framework In the overall structure of a typical Bluetooth audio-related framework, the location of the A2DP framework is shown in Figure 1.
The function provided by the Service Discovery Application Framework (SDAP) is to provide other Bluetooth devices with their own services and to use the services and functions provided by remote devices. In practical applications, almost all frameworks support Service Discovery Protocol (SDP). The Bluetooth Audio Video Remote Control Application Framework (AVRCP) implements remote control functions between Bluetooth devices, for example, the transmission of control signaling such as forward, backward, stop, and playback of music players. Hands-free function application framework for head-mounted devices (HFP / HSP), the main application is to realize the hands-free function of Bluetooth headsets and the audio gateway function of some Bluetooth devices.

The Advanced Audio Distribution Framework (A2DP) relies on the General Audio Video Distribution Framework (GAVDP). GAVDP defines the steps for setting up audio and video streaming, while A2DP further defines the parameters and step details for audio streaming.

In practical applications, the logical link control adaptation layer protocol (L2CAP) requires relatively high reliability. Baseband broadcast data packets will be banned. Therefore, the L2CAP layer does not support reliable multipoint transmission channels, which is One of the main reasons why the A2DP framework does not support multicast audio distribution. For the development and application of high-level protocols, the L2CAP layer protocol is transparent, so the relevant description of the specific implementation of the A2DP lightweight framework is limited to the L2CAP layer above. The A2DP related protocols and frameworks such as AVDTP, GAVDP and other protocol modules the design of.

Figure 1 Overall structure of Bluetooth audio framework

The HCI layer of the Bluetooth host control interface in Figure 1 is the interface of the software and hardware in the protocol stack. The hardware environment involved here is the connection model between the host and the host controller. The protocols above the HCI layer (such as SDP) run on the host, while the following protocols (such as the Bluetooth baseband protocol at the transport layer, etc.) come from the Bluetooth host controller hardware. Completed, this not only ensures the stability of the underlying protocol transmission, but also supports the scalability of the upper layer application protocol. Once the market conditions are mature, the hardware part of Bluetooth technology can be replaced by faster hardware radio frequency technology, and the high-level transmission protocol can still be used after transplantation, which greatly shortens the development cycle of Bluetooth products.

2 A2DP framework protocol stack
A2DP is an audio transmission framework. It distributes audio data streams from an audio source (SRC) to an audio sink (SNK) through a Bluetooth transmission layer and a peer device. Therefore, the protocol stack included in the framework is also divided into two parts , The specific performance shown in Figure 2.

Figure 2 A2DP framework protocol stack

Baseband protocol (Baseband Protocol), link management protocol (LMP), logical link control and adaptation protocol (L2CAP) and service discovery protocol (SDP) are defined in the Bluetooth core protocol specification. The Bluetooth audio and video distribution and transmission protocol AVDTP defines the parameter negotiation, establishment and transmission process of data flow handles between Bluetooth devices and the form of signaling entities that are exchanged. This protocol is the basic protocol of the A2DP framework.

Lightweight A2DP Framework Protocol Implementation The implementation of the A2DP framework protocol presented here is focused on the audio source end, and the sink end is not designed. It is defined as lightweight because it implements the mandatory functions specified in this specification on the basis of the A2DP specification 1.0, that is, only the basic functions of advanced audio distribution, such as stereo audio transmission, are implemented on the source side. Supports low-complexity subband codec (SBC) standards, but does not involve other codec standards; the implementation of the A2DP module does not include any codec capabilities, which is implemented on the user layer and is an upper-layer application In the setting stage, the program does the corresponding encoding, decoding and audio content conversion through configuration negotiation; the function of the AVDTP module does not include checksum reporting, nor does it include media multiplexing, checksum reporting channel establishment.

1 Protocol module division
The A2DP framework protocol is divided into three modules: A2DP module, GAVDP module and AVDTP module, and also includes the Audio application test module required for testing the protocol stack. For GAVDP, although this functional module includes the transmission and distribution of both audio / video data streams, the video stream related module (VDP) has not been implemented because of the focus on audio streams. Figure 3 is a specific implementation of the module division diagram.

Figure 3 A2DP framework specific module division

2 Message passing mechanism The interaction between the protocol layers of the lightweight framework module is realized through the message passing mechanism. The types of messages can be divided into the following four types.
â‘ Request message REQ
This message is a request from the upper layer protocol to the lower layer protocol.
â‘¡ Confirmation message CFM
Each REQ message sent by the upper layer protocol will receive confirmation from the lower layer protocol.
â‘¢Indication message IND
This message is a notification initiated by the lower layer protocol to the upper layer protocol.
â‘£Response message REP
For each IND message sent actively by the lower layer protocol, the upper layer protocol responds to this message.

Figure 4 Message passing between protocols

The message transfer between the protocols is shown in Figure 4.
The advantages of the implementation method based on the message passing mechanism are as follows:
â‘  The interaction between the protocol layers through a fixed message interface, even if the upper and lower protocol modules are upgraded, it will not affect the function of the protocol module of this layer, and has good portability and reusability.
â‘¡ All layers of protocols are asynchronous communication, which can greatly reduce the occurrence of congestion.
â‘¢The protocol stack process can manage a message queue at the upper layer and uniformly send and receive messages. When the message is rejected during the downward transmission process, the message retransmission function can be realized.
â‘£ Compared with each layer protocol using a separate task to achieve the corresponding function, the method of using the message mechanism saves the system scheduling time, more real-time, while avoiding the occurrence of deadlock.
3 Important data structure â‘  Message structure The message structure is divided into 3 fields: sending module Id, receiving module Id, and message enumeration type. The specific definitions are as follows:
typedef struct
{
BT_ModuleId sender;
BT_ModuleId receiver;
BT_PrimiTIve primiTIve;
} BT_Header;
②Stream endpoint structure The stream endpoint SEP exists in the application layer, and the application layer registers its SEP in AVDTP so that other devices can discover and connect. SEP has different structure types in three modules—A2DP, GAVDP, and AVDTP to adapt to the special role of this layer of protocol. Taking the A2DP module as an example, its SEP structure is specifically defined as follows:
typedef struct
{
GAVDP_Handle streamHandle;
BT_U8 * codecInfoElement;
BT_U8 lengthInfoElements;
AVDT_MediaCodecType codecType;
ChannelConfig configuraTIon;
AVDT_ResponseCode pendingRspCode;
BT_TimerId resendTimerId;
} StreamEndPoint;
4 Main functions of each module and message interface Each module receives different enumerated messages through its own message function and turns to its own message processing function. The functions realized by each module will be analyzed below.
â‘ A2DP module
The A2DP module implements the function of managing SEP and SEP capabilities through GAVDP, and sets and configures a streaming channel for audio streaming text between SRC and SNK. According to the communication process of the A2DP module, its message interface is divided into 6 types: flow setting message, which can be divided into two steps: peer flow endpoint discovery and flow configuration; flow channel release message; start / suspend flow message; Configuration / reconfiguration message; discovery / obtainment capability message; media stream start message.
â‘¡GAVDP module
From the perspective of multiple users, the GAVDP module manages the registration of local stream SEP and SEP capabilities, processes discovery query requests and capability requests sent from remote devices, and automatically sends responses based on user registered SEP information.
Since the function of the GAVDP module is to refine the upper-layer A2DP module, the message interface of the GAVDP and the interface type of the A2DP module can be designed for consistency, and the message interface types of the two are basically the same.
â‘¢AVDTP module
The AVDTP module is responsible for establishing an AVDTP signaling channel to a remote Bluetooth device, and sends all signaling commands with the aid of the AVDTP protocol, at the same time establishes a transmission channel for the media stream, and also establishes a channel for checksum reporting if necessary. Linghe media segmentation. The most basic process of AVDTP module data communication is SEP discovery → acquire SNK capability → data flow configuration → data flow establishment → data flow start → data flow suspend → data flow reconfiguration → data flow release. The state machine of the corresponding SEP in the AVDTP module is shown in Figure 5.

Figure 5 SEP state machine in AVDTP module

The transition between the various states of the entire communication process is triggered by the following messages:
A: AVDT_SET_CONFIGURATION _REQ
B: AVDT_OPEN_REQ
C: AVDT_START_REQ
D: AVDT_SUSPEND_REQ
E: AVDT_CLOSE_REQ
F: AVDT_ABORT_REQ
G: AVDT_RECONFIGURE_REQ
H: AVDT_MEDIA_REQ
In the idle state, before sending the A message, a series of actions should be issued in the idle state, including a connection request, a discovery request, and a request to obtain SNK capabilities. The transition process from the idle state to the configuration state is collectively referred to as the flow setting process.

After sending the C message in the open state, it enters the flow control state. At this time, the media stream data packet from SRC to SNK can be sent through the H message.

In any state during the communication process, you can enter the suspended state by sending an F message, and then return to the idle state without any remote SEP connected.

Test and conclusion The realization and test of this lightweight protocol stack can be completed based on CSR's advanced BlueCore4 Bluetooth chip. The chip supports Bluetooth 2.0 + EDR specification, and provides a data transfer rate of 2.1Mb / s, which is 3 times faster than standard Bluetooth, enabling faster connection, simultaneous support for multiple Bluetooth links, and wider bandwidth such as audio streaming Emerging applications. The top-level audio application program implements a simple player with SBC format codec information. The application program and some high-level protocol stacks are cross-compiled and downloaded to the hardware platform host. The player program distributes the audio data stream by calling the API provided by this protocol stack. For the audio data receiving end SNK, Motorola HT820 stereo headphones are used for testing. In the case of playing audio data for a long time, there will still be audio pauses. Airsniffer, a tool that intercepts Bluetooth signals in the air and performs protocol analysis, grabs streaming media transmission packets. After analysis, the audio data is not lost, but the flow control mechanism has problems and needs to be further improved.