`
`Prepared
`Bluetooth Audio Video
`Working Group
`
`Approved
`Date / Year-Month-Day
`Version
`2003-05-22
`e-mail address
`avv-feedback@bluetooth.org
`
`Revision
`1.0
`
`Document No
`
`N.B.
`Confidential
`
`
`
`ADVANCED AUDIO DISTRIBUTION PROFILE
`SPECIFICATION
`
`Adopted version 1.0
`
`Abstract
`This profile defines the requirements for Bluetooth™ devices
`necessary for support of the high quality audio distribution. The
`requirements are expressed in terms of end-user services, and by
`defining the features and procedures that are required for
`interoperability between Bluetooth devices in the Audio
`Distribution usage model.
`
`
`
`Page 1 of 75
`
`BMW EXHIBIT 1017
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`
`Revision History
`
`Page 2 of 75
`
`Date
`Revision
`April 2001
`0.5
`June 2001
`0.7
`September 2001
`0.9
`October 2001
`Voting Draft 0.95
`March 2002
`0.95b
`May 2002
`Voting Draft 1.00
`June 2002
`Voting Draft 1.00 a
`Voting Draft 1.00 b February 2003
`Version 1.0
`May 2003
`
`Comments
`Release to Associates
`Release to Associates
`Release to Associates and Early Adopters
`Release to Associates and Early Adopters
`Adopted 0.95
`Release for Voting Draft
`Release for Voting Draft
`Release for Voting Draft
`Adopted version
`
` Release Date: 22 May 2003
`
`Page 2 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`
`Page 3 of 75
`
`Ericsson
`Ericsson
`Matsushita Electric Industrial
`Nokia
`Nokia
`Nokia
`Philips
`Philips
`Philips
`Philips
`Philips
`Philips
`Sony
`Sony
`Sony
`Sony
`Sony
`Sony
`Sony
`Sony
`Toshiba
`Toshiba
`Toshiba
`Toshiba
`Toshiba
`Toshiba
`
`Contributors
`
`Morgan Lindqvist
`Fisseha Mekuria
`Tsuyoshi Okada
`Kalervo Kontola
`Vesa Lunden
`Jurgen Schnitzler
`Shaun Barrett
`Christian Bouffioux
`Frans de Bont
`Rob J. Davies
`Emmanuel Mellery
`Marc Vauclair
`Kenzo Akagiri
`Masakazu Hattori
`Harumi Kawamura (Owner)
`Rudiger Mosig
`Yoshiyuki Nezu
`Masayuki Nishiguchi
`Hiroyasu Noguchi (Co-Owner)
`Tomoko Tanaka
`Junko Ami
`Takeshi Saito
`Yoshiaki Takabatake
`Yoichi Takebayashi
`Ichiro Tomoda
`Junichi Yoshizawa
`
`
` Release Date: 22 May 2003
`
`Page 3 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`
`Disclaimer and Copyright Notice
`
`Page 4 of 75
`
`The copyright in these specifications is owned by the Promoter Members of
`Bluetooth SIG, Inc. (“Bluetooth SIG”). Use of these specifications and any related
`intellectual property (collectively, the “Specification”), is governed by the Promoters
`Membership Agreement among the Promoter Members and Bluetooth SIG (the
`“Promoters Agreement”), certain membership agreements between Bluetooth SIG
`and its Adopter and Associate Members (the Membership Agreements”) and the
`Bluetooth Specification Early Adopters Agreements (“1.2 Early Adopters
`Agreements”) among Early Adopter members of the unincorporated Bluetooth
`special interest group and the Promoter Members (the “Early Adopters Agreement”).
`Certain rights and obligations of the Promoter Members under the Early Adopters
`Agreements have been assigned to Bluetooth SIG by the Promoter Members.
`
`Use of the Specification by anyone who is not a member of Bluetooth SIG or a party to an Early
`Adopters Agreement (each such person or party, a “Member”), is prohibited. The legal rights and
`obligations of each Member are governed by their applicable Membership Agreement, Early Adopters
`Agreement or Promoters Agreement. No license, express or implied, by estoppel or otherwise, to any
`intellectual property rights are granted herein.
`
`Any use of the Specification not in compliance with the terms of the applicable Membership
`Agreement, Early Adopters Agreement or Promoters Agreement is prohibited and any such prohibited
`use may result in termination of the applicable Membership Agreement or Early Adopters Agreement
`and other liability permitted by the applicable agreement or by applicable law to Bluetooth SIG or any
`of its members for patent, copyright and/or trademark infringement.
`
`IS” WITH NO WARRANTIES WHATSOEVER,
`IS PROVIDED “AS
`THE SPECIFICATION
`INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY
`PARTICULAR PURPOSE, SATISFACTORY QUALITY, OR REASONABLE SKILL OR CARE, OR
`ANY WARRANTY ARISING OUT OF ANY COURSE OF DEALING, USAGE, TRADE PRACTICE,
`PROPOSAL, SPECIFICATION OR SAMPLE.
`
`Each Member hereby acknowledges that products equipped with the Bluetooth™ technology
`(“Bluetooth™ Products”) may be subject to various regulatory controls under the laws and regulations
`of various governments worldwide. Such laws and regulatory controls may govern, among other
`things, the combi-nation, operation, use, implementation and distribution of Bluetooth™ Products.
`Examples of such laws and regulatory controls include, but are not limited to, airline regulatory
`controls, telecommunications regulations, technology transfer controls and health and safety
`regulations. Each Member is solely responsible for the compliance by their Bluetooth™ Products with
`any such laws and regulations and for obtaining any and all required authorizations, permits, or
`licenses for their Bluetooth™ Products related to such regulations within the applicable jurisdictions.
`Each Member acknowledges that nothing in the Specification provides any information or assistance
`in connection with securing such compliance, authorizations or licenses. NOTHING IN THE
`SPECIFICATION CREATES ANY WARRANTIES, EITHER EXPRESS OR IMPLIED, REGARDING
`SUCH LAWS OR REGULATIONS.
`
`INTELLECTUAL
`INFRINGEMENT OF ANY
`INCLUDING LIABILITY FOR
`ALL LIABILITY,
`PROPERTY RIGHTS OR FOR NONCOMPLIANCE WITH LAWS, RELATING TO USE OF THE
`SPECIFICATION IS EXPRESSLY DISCLAIMED. BY USE OF THE SPECIFICATION, EACH
`MEMBER EXPRESSLY WAIVES ANY CLAIM AGAINST BLUETOOTH SIG AND ITS PROMOTER
`MEMBERS RELATED TO USE OF THE SPECIFICATION.
`
`Bluetooth SIG reserves the right to adopt any changes or alterations to the Specification as it deems
`necessary or appropriate and to adopt a process for adding new Bluetooth™ profiles after the release
`of the Specification.
`
`Copyright © 2003, Bluetooth SIG Inc
`
` Release Date: 22 May 2003
`
`Page 4 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`
`Document Terminology
`
`Page 5 of 75
`
`The Bluetooth SIG has adopted Section 13.1 of the IEEE Standards Style Manual,
`which dictates use of the words ``shall’’, ``should’’, ``may’’, and ``can’’ in the
`development of documentation, as follows:
`
`• The word shall is used to indicate mandatory requirements strictly to be followed
`in order to conform to the standard and from which no deviation is permitted
`(shall equals is required to).
`
`• The use of the word must is deprecated and shall not be used when stating
`mandatory requirements; must is used only to describe unavoidable situations.
`
`• The use of the word will is deprecated and shall not be used when stating
`mandatory requirements; will is only used in statements of fact.
`
`• The word should is used to indicate that among several possibilities one is
`recommended as particularly suitable, without mentioning or excluding others; or
`that a certain course of action is preferred but not necessarily required; or that (in
`the negative form) a certain course of action is deprecated but not prohibited
`(should equals is recommended that).
`
`• The word may is used to indicate a course of action permissible within the limits
`of the standard (may equals is permitted).
`
`• The word can is used for statements of possibility and capability, whether
`material, physical, or causal (can equals is able to).
`
` Release Date: 22 May 2003
`
`Page 5 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`
`Contents
`
`Page 6 of 75
`
`1
`
`2
`
`3
`
`4
`
`Introduction ......................................................................................... 9
`1.1 Scope.......................................................................................... 9
`1.2 Profile Dependency..................................................................... 9
`1.3 Symbols and Conventions ........................................................ 10
`1.3.1 Requirement Status Symbols ....................................... 10
`1.3.2 Definition ...................................................................... 11
`Profile Overview ................................................................................ 12
`2.1 Profile Stacks ............................................................................ 12
`2.2 Configurations and Roles.......................................................... 12
`2.3 User Requirements and Scenarios ........................................... 13
`2.4 Profile Fundamentals ................................................................ 14
`2.5 Conformance............................................................................. 14
`Application Layer .............................................................................. 15
`3.1 Audio Streaming Set Up............................................................ 15
`3.2 Audio Streaming........................................................................ 15
`3.2.1 Send Audio Stream ...................................................... 16
`3.2.2 Receive Audio Stream.................................................. 16
`Audio Codec Interoperability Requirements .................................. 18
`4.1 Overview ................................................................................... 18
`4.2 Support of Codecs .................................................................... 18
`4.2.1 Mandatory Codec ......................................................... 18
`4.2.2 Optional codecs............................................................ 19
`4.2.3 Non-A2DP Codecs ....................................................... 19
`4.2.4 Codec Interoperability Requirements ........................... 19
`4.2.5 Audio Codec Type Field Values ................................... 19
`4.3 SBC........................................................................................... 19
`4.3.1 Reference..................................................................... 19
`4.3.2 Codec Specific Information Elements........................... 20
`4.3.3 Media Packet Header Requirements............................ 22
`4.3.4 Media Payload Format ................................................. 23
`4.4 MPEG-1,2 Audio ....................................................................... 24
`4.4.1 Reference..................................................................... 24
`4.4.2 Codec Specific Information Elements........................... 24
`4.4.3 Media Packet Header Requirements............................ 27
`4.4.4 Media Payload Format ................................................. 27
`4.5 MPEG-2, 4 AAC ........................................................................ 27
`4.5.1 Reference..................................................................... 27
`
` Release Date: 22 May 2003
`
`Page 6 of 75
`
`
`
`5
`
`5.2
`
`BLUETOOTH SPECIFICATION
`Page 7 of 75
`Advanced Audio Distribution Profile
`4.5.2 Codec Specific Information Elements........................... 27
`4.5.3 Media Packet Header Requirements............................ 30
`4.5.4 Media Payload Format ................................................. 30
`4.6 ATRAC family............................................................................ 30
`4.6.1 Reference..................................................................... 30
`4.6.2 Codec Specific Information Elements........................... 30
`4.6.3 Media Packet Header Requirements............................ 33
`4.6.4 Media Payload Format ................................................. 34
`4.7 Non-A2DP Codec...................................................................... 34
`4.7.1 Reference..................................................................... 34
`4.7.2 Codec Specific Information Elements........................... 34
`4.7.3 Media Packet Header Requirements............................ 35
`4.7.4 Media Payload Format ................................................. 35
`GAVDP Interoperability Requirements............................................ 36
`5.1 AVDTP Interoperability Requirements ...................................... 36
`5.1.1 Signalling procedures................................................... 36
`5.1.2 Transport Services ....................................................... 36
`5.1.3 Error Codes .................................................................. 36
`L2CAP Interoperability Requirements ....................................... 38
`5.2.1 Maximum Transmission Unit ........................................ 39
`5.2.2 Flush Timeout............................................................... 39
`5.3 SDP Interoperability Requirements ........................................... 39
`5.4
`Link Manager Interoperability Requirements............................. 41
`5.5
`Link Controller Interoperability Requirements ........................... 41
`5.5.1 Class of Device............................................................. 42
`Generic Access Profile Interoperability Requirements.................. 43
`Testing ............................................................................................... 44
`References......................................................................................... 45
`List of Figures ................................................................................... 47
`List of Tables ..................................................................................... 48
`Appendix A (Informative): Audio Streaming with Content Protection 49
`Appendix B: Technical Specification of SBC ................................. 50
`12.1
`Introduction ............................................................................... 50
`12.2 Glossary.................................................................................... 50
`12.3 Symbols and Abbreviations....................................................... 50
`12.3.1 Arithmetic Operators..................................................... 50
`12.3.2 Logical Operators ......................................................... 51
`12.3.3 Relation Operators ....................................................... 51
`12.3.4 Bitwise Operators ......................................................... 51
`
`6
`7
`8
`9
`10
`11
`12
`
` Release Date: 22 May 2003
`
`Page 7 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Page 8 of 75
`Advanced Audio Distribution Profile
`12.3.5 Assignment................................................................... 51
`12.3.6 Mnemonics ................................................................... 51
`12.3.7 Constants ..................................................................... 52
`12.3.8 Ranges 52
`12.3.9 Number Notation .......................................................... 52
`12.4 Syntax ....................................................................................... 52
`12.5 Semantics ................................................................................. 54
`12.5.1 Frame_header.............................................................. 54
`12.5.2 scale_factors ................................................................ 55
`12.5.3 audio_samples ............................................................. 55
`12.5.4 padding 55
`12.6 Decoding Processes ................................................................. 56
`12.6.1 Frame Header .............................................................. 56
`12.6.2 Scale Factors ............................................................... 57
`12.6.3 Bit Allocation................................................................. 57
`12.6.4 Reconstruction of the Subband Samples ..................... 64
`12.6.5 Joint Processing ........................................................... 64
`12.6.6 Synthesis Filter............................................................. 64
`12.7 Encoding Processes ................................................................. 66
`12.7.1 Analysis Filter ............................................................... 67
`12.7.2 Scale Factors ............................................................... 69
`12.7.3 Joint_Stereo Channel Mode Operation ........................ 69
`12.7.4 Bit Allocation................................................................. 69
`12.7.5 Quantization ................................................................. 69
`12.8 Tables ....................................................................................... 69
`12.9 Calculation of Bit Rate and Frame Length ................................ 70
`Appendix C (Informative): Signalling Flows ................................... 72
`13.1 Audio Streaming Set Up............................................................ 72
`13.2 Audio Streaming........................................................................ 73
`Appendix D: Acronyms and Abbreviations .................................... 75
`
`13
`
`14
`
`
`
` Release Date: 22 May 2003
`
`Page 8 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`
`1
`
`Introduction
`
`1.1
`
`Scope
`
`Page 9 of 75
`
`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 as defined in Chapter 12 of Bluetooth Baseband specification [1].
`
`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.
`
`The A2DP focuses on audio streaming, while the Video Distribution Profile (VDP)
`specifies video streaming. Support of both profiles enables us to distribute video
`content accompanied with high-quality audio. The usage case of video and audio
`streaming is described in the VDP.
`
`Note also that the A2DP does not include remote control functions. Devices may
`support remote control features by implementing both A2DP and the control profile
`as depicted, for example, in the usage scenario of Audio/Video Remote Control
`Profile[2].
`
`Editor's note: The A/V WG has requested additional QoS support in the next revision
`of the Bluetooth data link specification. When other profiles with stringent
`requirements are used in conjunction with this profile the performance may be
`degraded due to insufficient support of QoS in the current Bluetooth specification
`v.1.1, which all profiles use.
`
`1.2
`
`Profile Dependency
`
`In Figure 1.1, the structure and the dependencies of the profiles are depicted. A
`profile is dependent upon another profile if it re-uses parts of that profile, by implicitly
`or explicitly referencing it. Dependency is illustrated in the figure. A profile has
`dependencies on the profile(s) in which it is contained – directly and indirectly.
`
`As indicated in the figure, the A2DP is dependent upon the Generic Access Profile
`(GAP), and also the Generic Audio/Video Distribution Profile (GAVDP) [3], which
`defines procedures required to setup an audio/video streaming. The A2DP defines
`parameters and procedures that are specific for audio streaming. The terminology,
`user interface and procedures as defined in the GAP and GAVDP are applicable to
`this profile, unless explicitly stated otherwise.
`
`
`
` Release Date: 22 May 2003
`
`Page 9 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`
`
`Generic Access Profile
`
`Page 10 of 75
`
`Generic Audio/Video
`Distribution Profile
`
`Advanced Audio Distribution
`Profile
`
`Video Distribution Profile*
`
`Audio/Video Remote Control Profile
`
`* Still under development when A2DP version 1.0 is published.
`
`
`
`Figure 1.1: Profile Dependencies
`
`Symbols and Conventions
`1.3
`1.3.1 Requirement Status Symbols
`
`In this document the following symbols are used:
`
`‘M’ for mandatory to support (used for capabilities that shall be used in the profile).
`
`‘O’ for optional to support (used for capabilities that may be used in the profile).
`
`‘C’ for conditional support (used for capabilities that shall be used in case a certain
`other capability is supported).
`
`‘X’ for excluded (used for capabilities that may be supported by the unit, but that
`shall never be used in the profile).
`
`‘N/A’ for not applicable (in the given context it is impossible to use this capability).
`
`Some excluded capabilities are capabilities that, according to the relevant Bluetooth
`specification, are mandatory. These are features that may degrade operation of
`
` Release Date: 22 May 2003
`
`Page 10 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Page 11 of 75
`Advanced Audio Distribution Profile
`devices following this profile. Therefore, these features shall never be activated while
`a unit is operating as a unit within this profile.
`
`1.3.2 Definition
`
`1.3.2.1 RFA
`
`Reserved for Future Additions. Bits with this designation shall be set to zero.
`Receivers shall ignore these bits.
`
`1.3.2.2 RFD
`
`Reserved for Future Definition. These bit value combinations or bit values are not
`allowed in the current specification but may be used in future versions. The receiver
`shall check that unsupported bit value combination is not used.
`
` Release Date: 22 May 2003
`
`Page 11 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`
`2
`
`Profile Overview
`
`2.1
`
`Profile Stacks
`
`The figure below shows the protocols and entities used in this profile.
`
`Page 12 of 75
`
`Application
`
`Audio Source
`
`Application
`
`Audio Sink
`
`AVDTP
`
`SDP
`
`AVDTP
`
`SDP
`
`LMP
`
`L2CAP
`
`LMP
`
`L2CAP
`
`Baseband
`
`Baseband
`
`Audio Source Side
`
`Audio Sink Side
`
`Figure 2.1: Protocol Model
`
`
`
`The Baseband[1], LMP[5], L2CAP[6], and SDP[7] are Bluetooth protocols defined in
`the Bluetooth Core specifications. AVDTP[4] consists of a signalling entity for
`negotiation of streaming parameters and a transport entity that handles streaming
`itself.
`
`The Application layer shown in Figure 2.1 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 Figure 2.1, the GAVDP applies, except in those
`cases where this profile explicitly states deviations.
`
`2.2
`
`Configurations and Roles
`
`The following roles are defined for devices that implement this profile:
`
`Source (SRC) – 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.
`
` Release Date: 22 May 2003
`
`Page 12 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Page 13 of 75
`Advanced Audio Distribution Profile
`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.
`
`Examples of configurations illustrating the roles for this profile are depicted in Figure
`2.2.
`
`
`
`Audio Stream
`
`Portable Player (SRC)
`
`Headphones (SNK)
`
`Audio Stream
`
`Portable Recorder (SNK)
`
`Microphone (SRC)
`
`
`
`Figure 2.2: Examples of Configuration
`
`2.3
`
`User Requirements and Scenarios
`
`The following scenario is covered by this profile:
`
`- Setup/control/manipulate a streaming of audio data from the SRC to the SNK(s).
`
`The following restrictions are applied to this profile:
`
`1 The profile does not support a synchronized point-to-multipoint distribution.
`
`2 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:
`
` Release Date: 22 May 2003
`
`Page 13 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Page 14 of 75
`Advanced Audio Distribution Profile
`3 The audio data rate should be sufficiently smaller than usable bit rate on the
`Bluetooth link. This is to allow retransmission schemes to reduce the effects of
`packet loss.
`
`4 The profile does not exclude any content protection method.
`
`Profile Fundamentals
`2.4
`The profile fundamentals are same as defined in the GAVDP in addition to the
`following requirement.
`
`- Content Protection is provided at the application level and is not a function of the
`Bluetooth link level security protocol.
`
`2.5
`
`Conformance
`
`When 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 for optional and conditional capabilities for which support is indicated. All
`mandatory, optional, and conditional capabilities, for which support is indicated, are
`subject to verification as part of the Bluetooth certification program.
`
` Release Date: 22 May 2003
`
`Page 14 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`
`3
`
`Application Layer
`
`Page 15 of 75
`
`This section describes the feature requirements on units complying with the A2DP.
`
`Table 3.1 shows the feature requirements for this profile.
`Item
`Feature
`Support in
`No.
`SRC
`1
`M
`
`Audio Streaming
`Table 3.1: Application Layer Features
`
`Support in
`SNK
`M
`
`Table 3.2 maps each feature to the procedures used for that feature, and shows
`whether the procedure is optional, mandatory, or conditional. The procedures are
`described in the reference section.
`Item
`Feature
`Procedure
`No.
`1
`
`
`Audio Streaming
`
`
`Support
`in SRC
`M
`3.2.1
`Send Audio Stream
`N/A
`3.2.2
`Receive Audio Stream
`Table 3.2: Application Layer Feature to Procedure Mapping
`
`Ref.
`
`Support
`in SNK
`N/A
`M
`
`3.1
`
`Audio Streaming Set Up
`
`When a device wishes to start streaming of audio content, the device firstly needs to
`set up a streaming connection. Signalling procedures and typical signalling flows are
`illustrated in Section 4.1 and Appendix A of GAVDP[3], respectively. 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. (For details, see Section 4.4 in
`AVDTP[4].) This profile specifies audio-specific parameters necessary for these
`signalling procedures. An example of how the session signalling is performed is
`described in Chapter 14 of GAVDP[3] and in Chapter 13 of this specification.
`
`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. The content protection capability is described in Appendix A
`as informative.
`
`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. Available services are listed in Section 5.1.2.
`
`3.2
`
`Audio Streaming
`
`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
`
` Release Date: 22 May 2003
`
`Page 15 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Page 16 of 75
`Advanced Audio Distribution Profile
`(SNK) is ready to send (receive) audio stream. (See Section 4.1 in GAVDP[3].) 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 Figure
`3.1. In Chapter 4 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.
`
`3.2.1 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.
`
`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 Chapter 2 of AVDTP[4]. The stream data
`shall be sent out on the transport channel using the selected transport services
`defined in Section 5.4 of AVDTP[4].
`
`3.2.2
`
` 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 Chapter 2 of AVDTP[4].
`
`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.
`
` Release Date: 22 May 2003
`
`Page 16 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`
`
`Audio Source
`
`Audio Sink
`
`Encoding
`
`Decoding
`
`Encryption
`(optional)
`
`Decryption
`(optional)
`
`Page 17 of 75
`
`Media PL
`
`CP
`
`Media PL
`
`AVDTP
`
`AVDTP
`
`MP
`
`CP
`
`Media PL
`
`L2CAP
`
`L2CAP
`
`L2CAP
`
`MP
`
`CP
`
`Media PL
`
`Send Audio
`Stream
`
`Receive Audio
`Stream
`
`Media PL: Media Payload
`CP: Content protection header
`MP: Media packet header
`L2CAP: L2CAP header
`Packet Format
`
`
`
`Figure 3.1: Block Diagram of Audio Streaming Procedures and the Packet Format
`
` Release Date: 22 May 2003
`
`Page 17 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`
`Page 18 of 75
`
`4
`
`Audio Codec Interoperability Requirements
`
`4.1 Overview
`
`This chapter defines necessary information specific for audio codec. In Section 4.2
`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 Bluetooth Assigned Numbers[8].
`
`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.
`(See Figure 3.1)
`- Media payload format defines the codec specific payload format in the AVDTP
`packet, which shall be used in the Audio Streaming procedures in Section 3.2.
`See also Figure 3.1.
`4.2
` Support of Codecs
`
`Table 4.1 shows supported Mandatory and Optional codecs in this profile.
`Codec Type
`Support Ref.
`
`M
`SBC
`O
`MPEG-1,2 Audio
`O
`MPEG-2,4 AAC
`O
`ATRAC family
`Table 4.1: Supported codecs
`
`4.3
`4.4
`4.5
`4.6
`
`The following codecs are treated as Non-A2DP codecs:
`
`- The codecs that are not on Table 4.1.
`- The Mandatory or Optional codecs on Table 4.1 used in non-conforming way.
`
`Requirements for the use of Non-A2DP codecs are defined in Section 4.2.3 and 4.7.
`
`4.2.1
`
` Mandatory Codec
`
`The A2DP mandates low complexity subband 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.
`
` Release Date: 22 May 2003
`
`Page 18 of 75
`
`
`
`BLUETOOTH SPECIFICATION
`Advanced Audio Distribution Profile
`4.2.2
` Optional codecs
`
`Page 19 of 75
`
`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 versi