|
|
The Advanced Audio Distribution Profile (A2DP)
defines the protocols and procedures that realize distribution of audio
content of high-quality in mono or stereo on ACL channels. The term
"advanced audio", therefore, should be distinguished from
"Bluetooth audio", which indicates distribution of narrow band
voice on SCO channels.
A typical usage case is the streaming
of music content from a stereo music player to headphones or speakers. The
audio data is compressed in a proper format for efficient use of the
limited bandwidth. Surround sound distribution is not included in the
scope of this profile.
For more details : Download the A2DP Profile from the Bluetooth.org
website.
Image reprinted from Bluetooth A2DP Profile, Figure
2.1
The Baseband, LMP,
L2CAP, and SDP are Bluetooth
protocols defined in the Bluetooth Core specifications. AVDTP consists of
a signalling entity for negotiation of streaming parameters and a
transport entity that handles the streaming.
The Application layer shown in the
Figure above is the entity in which the device defines application service
and transport service parameters. The entity also adapts the audio
streaming data into the defined packet format, or vice versa. For the
shaded protocols/entities in the Figure above, the GAVDP
applies, except in those cases where this profile explicitly states
deviations.
The following roles are defined for devices that
implement this profile:
A device is the SRC when
it acts as a source of a digital audio stream that is delivered to the
SNK of the piconet.
Sink (SNK) – A device is the SNK when it
acts as a sink of a digital audio stream delivered from the SRC on
the same piconet.
The following scenario is covered by
this profile:
The following restrictions are applied
to this profile:
-
The profile does not support a synchronized
point-to-multipoint distribution.
-
There exists certain delay between the SRC and
the SNK due to radio signal processing, data buffering, and
encode/decode of the stream data. Countering the effects of such
delays depends on implementation.
The following requirements are set in
this profile:
-
The audio data rate should be sufficiently smaller
than usable bit rate on the Bluetooth link. This is to allow
retransmission scheme to reduce effects of packet loss, which results
in audible unpleasant effects such as noise or discontinuity.
-
The profile does not exclude any content protection
method.
The profile fundamentals are same as
defined in the GAVDP in addition to the following requirement.
If conformance to this profile is claimed, all
capabilities indicated mandatory for this profile shall be supported in
the specified manner (process-mandatory). This also applies to all
optional and conditional capabilities for which support is indicated.
This section describes the feature requirements on
units complying with the A2DP.
Image reprinted from Bluetooth A2DP Profile, Table
3.2
When a device wishes to start streaming
of audio content, the device firstly needs to set up a streaming
connection. During such set up procedure, the devices select the most
suitable audio streaming parameters.
There are two kinds of services
configured; one is an application service capability, and the other is a
transport service capability. This profile specifies audio-specific
parameters necessary for these signalling procedures.
The application service capability for
A2DP consists of audio codec capability and content protection capability.
Requirements for audio codec interoperability and details of codec
parameters such as mode, sampling frequency, and bit rate are described in
Chapter 4 of the A2DP profile. The transport service capability is
provided by AVDTP in order to manipulate the streaming packets more
intelligently. Appropriate configuration of these services increases
channel throughput.
Once streaming connection is
established and Start Streaming procedure in GAVDP is executed,
both SRC and SNK are in the STREAMING state, in which the SRC
(SNK) is ready to send (receive) audio stream. The SRC uses
the Send Audio Stream procedure to send audio data to the SNK,
which in turn employs the Receive Audio Stream procedure to receive
the audio data. The block diagrams of these procedures and created packet
format are shown in the Figure below. Later audio-specific parameters in
AVDTP header and media payload format are also specified.
Note again that the devices shall be in
the STREAMING state to send/receive audio stream. If the SRC/SNK
wishes to send/receive the audio stream whereas the state is still at
OPEN, the SRC/SNK shall initiate Start Streaming procedure
defined in GAVDP.
Send Audio Stream
-
In the Send Audio Stream procedure, the SRC shall,
if needed, encode the data into a selected format in the signalling
session. Then, the application layer of the SRC shall adapt the
encoded data into the defined media payload format. The frame of
encoded audio data is adapted to the defined payload format as defined
in Chapter 4 of the A2DP Profile.
-
When content protection is in use, a content
protection header may precede encrypted audio content. This is content
protection method dependent. Afterwards, the stream data shall be
handed down to the AVDTP entity through the exposed interface
(Interface 4) defined in the AVDTP spec. The stream data shall be sent
out on the transport channel using the selected transport services
defined in the AVDTP.
-
- Image reprinted from Bluetooth A2DP Profile, Figure 3.1
Receive Audio Stream
-
The AVDTP entity of the SNK shall receive the
stream data from the transport channel using the selected transport
services and pass it to the application layer by exposed interface
defined in the AVDTP.
-
When a content protection method is active, the
application layer of the SNK shall process the retrieved AVDTP
payload as described by the content protection method. Typically, this
processing entails content protection header analysis and decryption
of associated encrypted content. If applicable, the frame of audio
data shall be decoded according to the selected coding format.
-
This chapter defines necessary
information specific for audio codec. In Section 4.2 of the A2DP
definition of codecs used in this profile version 1.0 and their
requirements are fully described. Additional information about codec
introduced after A2DP version 1.0 is described in the Bluetooth Assigned
Numbers spec, available at the Bluetooth
website.
Remaining sections provide reference
for each codec as well as the following information:
-
Audio codec capabilities define the capability
field and its parameters necessary for signalling procedures in the
streaming set up. Related procedures in GAVDP are Connection
Establishment and Change Parameters procedures.
-
Media packet header requirements define codec
specific parameters in the media packet header, which shall be added
to the media payload in the AVDTP entity.
-
Media payload format defines the codec specific
payload format in the AVDTP packet, which shall be used in the Audio
Streaming procedures.
The table below shows supported Mandatory
and Optional codecs in this profile.
Image reprinted from Bluetooth A2DP Profile, Table
4.1
Mandatory Codecs
-
The A2DP mandates low complexity sub band codec (SBC)
to ensure the interoperability. The device shall implement a SBC
encoder when the device is the SRC, and a SBC decoder when the
device is the SNK. All other codecs in this document are called
Non-Mandatory codecs.
Optional Codecs
-
The device may also support Optional codecs to
maximize its usability. When both SRC and SNK support
the same Optional codec, this codec may be used instead of
Mandatory codec. Optional codecs available in this profile
version 1.0 are listed in Table 4.1 of the A2DP spec.
-
The device may support other codecs as Non-A2DP codecs.
A user of the Non- A2DP codec (hereafter the Vendor)
oneself defines parameters and any information necessary for use of
the codec in A2DP. The profile does not specify anything for Non-A2DP
codecs, whereas the following requirements are imposed:
-
To maintain interoperability, the requirements in
Section 4.2.4 in the A2DP Profile shall be applied.
-
The Non-A2DP codec can be upgraded to Optional
when the following items are prepared:
Clear pointer to the specification, test vectors, and
related documents
Necessary parameters for Signalling
Codec Interoperability Requirements
-
When the SRC wishes to send an audio data whose
codec format is not supported by the SNK, the data shall be
transcoded into SBC. Therefore, the following requirements are applied
to the SRC when it supports Non-Mandatory codecs.
-
For example, when the SRC accepts pre-encoded
audio data in the Non-Mandatory codec format, the SRC shall
have a decoder of this Non-Mandatory codec as well as a SBC
encoder for transcoding.
Audio Codec Type Field Values
-
Refer to Bluetooth Assigned Numbers[8] for audio codec
types available in this profile. Message format of audio codec
capabilities is defined in Section 8.19.5 of the AVDTP Profile. The
following section defines audio codec parameters and formats required
for audio streaming on the Bluetooth link.
SBC is mandatory to support in this
profile. The SBC specification is a part of the
Codec Specific Information Elements
-
The figure below shows Codec Specific Information
Elements for SBC used in the signalling procedures.. The following
section defines the field values and their requirements. T. If the
packet includes improper settings, the error code shall be returned.
See Section 4.3.2 of the A2DP Profile for elaboration of each of the
elements listed in the table below.
- Image reprinted from Bluetooth A2DP Profile, Figure 4.1
-
Note: In the Get Capabilities Response of
AVDTP, one or more bits may be defined/set in each field. On the other
hand, in the Set Configuration Command and the Reconfigure Command of
AVDTP, only one bit shall be defined/set in each field.
Media Packet Header Requirements
-
The media packet header must follow the following
requirements:
-
Timestamp: The clock frequency necessary to
create TS shall be set to the sample rate of the encoded audio data.
-
Payload Type: A payload type in the dynamic range
shall be chosen.
-
Marker (M) bit: Set to zero.
-
Extension (X) bit: Not used, set to zero
Media Payload Format
-
The media payload for SBC shown in the Figure below
consists of SBC specific header and SBC frame(s) defined in the SBC
specification. If the configured MTU size for the transport channel is
greater or equal to the SBC frame size + the sum of [Media Payload
header size, Content Protection header size (if Content Protection is
selected), Media Packet header size], then a media payload shall
contain an integral number of complete SBC frames (a).
Image reprinted from Bluetooth A2DP Profile, Figure
4.2
Codec Specific Information Elements
-
The figure below shows Codec Specific Information
Elements for MPEG-1,2 Audio used in the signalling procedures. The
following section defines the field values and their requirements..
Support columns in each field value show the requirements to fulfil
when this codec is supported. If the packet includes improper
settings, the error code shall be returned as specified. See Section
4.4.2 of the A2DP Profile for elaboration of each of the elements
listed in the table below.
-
- Image reprinted from Bluetooth A2DP Profile, Figure 4.4
-
Note: In the Get Capabilities Response of
AVDTP, one or more bits may be defined/set in each field. On the other
hand, in the Set Configuration Command and the Reconfigure Command of
AVDTP, only one bit shall be defined/set in each field.
Media Packet Header Requirements
-
The media packet header requirements for MPEG-1,2
Audio are contained in the specification of media payload format
referenced in Section 4.4.4 (Media Payload Format section below) of
the A2DP Profile.
Media Payload Format
-
MPEG-1,2 Audio uses payload formats defined in RFC
2250: "RTP Payload Format for MPEG1/MPEG2 Video." and
RFC3119: "A More Loss-Tolerant RTP Payload Format for MP3
Audio". This profile mandates support of the format in MPF-1.
MPF-2 provides more error-robustness for MPEG-1,2 Audio Layer III.
Codec Specific Information Elements
-
The figure below shows Codec Specific Information
Elements for MPEG-2,4 AAC used in the signalling procedures. The
following section defines the field values and their requirements.
Support columns in each field value show the requirements to fulfil
when this codec is supported. If the packet includes improper
settings, the error code shall be returned. See Section 4.5.2 of the
A2DP Profile for elaboration of each of the elements listed in the
table below.
-
- Image reprinted from Bluetooth A2DP Profile, Figure 4.5
-
Note: In the Get Capabilities Response of AVDTP, one
or more bits may be defined/set in each field. On the other hand, in
the Set Configuration Command and the Reconfigure Command of AVDTP,
only one bit shall be defined/set in each field.
Media Packet Header Requirements
-
The media packet header requirements for MPEG-2,4 AAC
are contained in the specification of media payload format referenced
in Section 4.5.4 (Media Payload Format section below) of the A2DP
Profile.
Media Payload Format
-
MPEG-2,4 AAC uses the media payload format defined in
RFC 3016: "RTP Payload Format for MPEG-4 Audio/Visual
streams". The specification defines the payload format only for
MPEG-4 audio; in use of MPEG-2 AAC LC, the audio stream shall be
transformed to MPEG-4 AAC LC in the SRC by modifying the codec
information and adapted into MPEG-4 LATM format before being put into
Media Payload Format. The SNK shall retransform the stream into
MPEG-2 AAC LC, if necessary.
Codec Specific Information Elements
-
The figure below shows Codec Specific Information
Elements for ATRAC family used in the signalling procedures. The
following section defines the field values and their requirements.
Support columns in each field value show the requirements to fulfil
when this codec is supported. If the packet includes improper
settings, the error code shall be returned as specified. See Section
4.6.2 of the A2DP Profile for elaboration of each of the elements
listed in the table below.
-
- Image reprinted from Bluetooth A2DP Profile, Figure 4.6
-
Note: In the Get Capabilities Response of AVDTP, one
or more bits may be defined/set in each field. On the other hand, in
the Set Configuration Command and the Reconfigure Command of AVDTP,
only one bit shall be defined/set in each field.
Media Packet Header Requirements
-
The media packet header must follow the following
requirements:
-
Timestamp: The clock frequency necessary
to create TS shall be set to the sample rate of the encoded audio
data.
Payload Type: A payload type in the dynamic
range shall be chosen.
Marker (M) bit: Set to zero.
-
Extension (X) bit: Not used, set to zero
Media Payload Format
-
Licensed users obtain the specification of Media
Payload Format for ATRAC family.
Codec Specific Information Elements
-
The figure below shows Codec Specific Information
Elements for Non-A2DP codec used in the signalling
procedures. If the packet includes improper settings, the error code
shall be returned. See Section 4.7.2 of the A2DP Profile for
elaboration of each of the elements listed in the table below.
-
- Image reprinted from Bluetooth A2DP Profile, Figure 4.7
-
Note: In the Get Capabilities Response of AVDTP, one
or more bits may be defined/set in each field. On the other hand, in
the Set Configuration Command and the Reconfigure Command of AVDTP,
only one bit shall be defined/set in each field.
Media Packet Header Requirements & Media Payload
Format
-
Media Packet Header requirements and Media Payload
Format shall be defined by the Vendor.
This profile requires compliance to the
Generic A/V Distribution Profile (GAVDP). The following text together with
the associated sub-clauses defines the requirements with regards to this
profile, in addition to the requirements defined in GAVDP.
Signalling Procedures
-
In the Advanced Audio Distribution Profile, it is
mandatory for the SRC and optional
Transport Services
-
Table 5.2 in the A2DP Profile shows support of AVDTP
transport capabilities for this profile. In this profile
-
For the L2CAP layer, no additions to
the requirements as stated in the GAVDP shall apply except for the
following requirements.
Maximum Transmission Unit
-
The minimum MTU that a L2CAP implementation for this
profile shall support is 335bytes.
Flush Timeout
-
Application shall set the appropriate value for
responding time to the flush timeout. A small finite value should be
used to allow sufficient real-time throughput on the interface.
-
Note: Flush timeout can be constrained by the ACL
channels when the other profile(s) coexist with A2DP.
-
Table 5.1 & 5.2 in the A2DP
Profile define the following service records for the SRC and the SNK
respectively.
For the LMP layer, no additions to the
requirements as stated in the GAVDP shall apply.
For the LC layer, the requirements as
stated in the GAVDP shall apply. Further more the following packets
shall be supported in both SNK and SRC: DH3, DM3, DH5 and
DM5
Note: Requirements described in GAVDP is
described for INT/ACP. For SRC, it is mandatory to
support both INT and ACP. For SNK, it is mandatory
to support ACP and it is optional to support INT.
The Advanced Audio Distribution
profile requires compliance to the Generic Access Profile. There
is no change to the requirements as stated in the General Audio/Video
Distribution Profile.
Note: Requirements described
in GAVDP is described for INT/ACP.
For SRC,
it is mandatory to support both INT
and ACP.
For SNK,
it is mandatory to support ACP
and it is optional to support INT.
Note , the above text contains excerpts from the
Bluetooth SIG's Specification, as well as various interpretations of the
Specs. For complete details of the various sections, consult the actual
Bluetooth Specification.
|
