Improving A2DP Audio Quality Instruction Manual

: June 2, 2024
: Bluetooth Device

IMPROVING A2DP AUDIO QUALITY

Revision History

Revision: Date: Description
D05r01: 23-11-2009: 1st draft to show possible outline of document
D05r02: 14-12-2009: 2nd draft, with detailed added for 1st time review from AVWG.
D05r03 :14-12-2009: Include changes suggested by John and Rudiger. Better wording need for using AVRCP volume control in preference to changing the loudness within the SBC data. Recommend the AG_MP includes AVRCP 1.3 command to turn of Equalization or other DSP is may perform on the SBC data
D05r04 :17-02-2010: Updates in response to comments from Rüdiger, Stephen and Sekisan. Made it clear that AVRCP volume control should be supported by the RD and MP so that MP shall not alter the digital bitstream as a form of volume control.
D05r05 :18-02-2010: Ed made some minor changes.
D05r06: 12-03-2010: Added Rec. 10, during last week’s conference call it seemed contentious about describing a quality vs range setting on the IUT, hopefully Rec .10 resolves this.
D05r07: 15-03-2010: Remove HF_RD and AG_MP usage as this implied some relevance to HFP which was not intended for this WP.
D05r08 : 15-02-2011: Update after F2F at UPF38.
Address Seattle F2F comments.
D05r09 :21-06-2011: From ASG meeting suggest to add statement that a SRC should also use appropriate bitpools.
D05r10 :29-06-2011: Allan asked to combine/review some of the Recommendations which have overlapping scope.
D05r11 : 06-09-2011: Add Rec.11 and include Rec.12 based on Allan’s’ YY update from message on 07/07 from the avv-main.
D05r12: 19-09-2011: Response to comments from Allan and Ash on avv-main in the last 7 days.
D05r13: 28-09-2011: Response to minutes of conference call on Sept. 20th.
D05r14: 08-10-2011: Updated at F2F meeting in Budapest
D05r15: 24-10-2011: Corrected table reference in R3, updated reference section + TOC
D05r16: 24-04-2012: Updated to resolve comments from BARB review
D05r17: 15-05-2012: Section 4 updated to indicate that all recommendations assumed A2DP and necessary A2DP role support, whilst avoiding instances of “shall”.
D05r18: 25-09-2012: Formatting, spell checking
V10r00: 09-10-2012: Approved by the Bluetooth SIG Board of Directors

Contributors

Name: Company
Rüdiger Mosig: BMS
Scott Walsh: Plantronics
Morgan Lindqvist: Ericsson
John Larkin: Qualcomm
Stephen Raxter: National Analysis Center
Masahiko Seki: Sony Corp
Allan Madsen: CSR
Ed McQuillan: CSR
David Trainor: CSR

DISCLAIMER AND COPYRIGHT NOTICE :
THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Any liability, including liability for infringement of any proprietary rights, relating to use of information in this document is disclaimed. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein.
This document is for comment only and is subject to change without notice. Copyright © 2012. Bluetooth® SIG, Inc. All copyrights in the Bluetooth Specifications themselves are owned by Ericsson AB, Lenovo (Singapore) Pte. Ltd., Intel Corporation, Microsoft Corporation, Motorola Mobility, Inc., Nokia Corporation, and Toshiba Corporation.
*Other third-party brands and names are the property of their respective owners.

1 Terms and Abbreviations

Abbreviation: Term
A2DP: Advanced Audio Distribution Profile
AVDTP: Audio Video Distribution Transport Protocol
AVRCP: Audio Video Remote Control Profile
GAVDP: Generic Audio/Video Distribution Profile
MP: Media Player
NA: Not Applicable
RC: Remote Controller
RD: Rendering Device
SBC: Sub-band Coding
SEP : Stream End Point (as described in Audio/Video Distribution Transport Protocol)
SNK: Sink (as defined in Advanced Audio Distribution Profile)
SRC: Source (as defined in Advanced Audio Distribution Profile)
UI: User Interface. Some possibility for the user to interact with the system, ranging from simple button clicks to a more complex UI; e.g., a display with keyboard or touch screen.

2 Document Terminology

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 )

3 Document Scope

This white paper describes how to configure A2DP SRC and SNK devices to produce high quality audio.
The recommendations in this white paper that are related to audio coding are relevant for the SBC algorithm.
However, the recommendations that are not related to audio coding are applicable irrespective of the audio coding algorithm employed.
This white paper does not make specific recommendations regarding the functionality and performance of audio system components that are outside the scope of the Bluetooth audio subsystem. Examples of such components include A/D and D/A converters and transducers within microphones and speakers. However, it should be noted that these components also contribute to system- level audio quality and their specifications and parameters; for example, frequency response and resolution must be carefully chosen to prevent significant degradation of the high-quality digital audio provided by A2DP.

4 Configuration and Roles

4.1 MEDIA PLAYER (MP)

The media player can, among other devices, be a portable media player (MP3 player, video player or mobile phone) or a fixed media player (home audio/video system or in-car audio/video system).

4.1.1 RECOMMENDATION

The MP is an example of an A2DP SRC device with the following properties:

It is assumed to support A2DP as defined in [1] , otherwise the recommendations in this white paper are not applicable
It should support AVRCP commands as described later in the document.
It is assumed to support the SRC role defined in [1] , otherwise the recommendations in this white paper are not applicable
It should include the ability to configure the SBC SEP on the SNK to the values defined Table 4.7 in [1].

4.1.2 MOTIVATION

The media player complies with the A2DP SRC role to enable streaming of audio/video to a SNK device. In addition, it should support suitable codec settings and remote control capabilities to deliver high audio quality.

4.2 RENDERING DEVICE (RD)

The rendering device can, among other devices, be headphones, loudspeakers, in-car audio systems, or a video display with optional audio capabilities.

4.2.1 RECOMMENDATION

The RD is an example of an A2DP SNK device with the following properties:

It is assumed to support A2DP as defined in [1], otherwise the recommendations in this whitepaper are not applicable
It should support AVRCP commands as described later in the document.
It is assumed to support the SNK role defined in [1], otherwise the recommendations in this whitepaper are not applicable
It should include the ability to configure the SBC SEP on the SNK to the values defined in Table 4.7 in [1] .

4.2.2 MOTIVATION

The rendering device complies with the A2DP SNK role to be able to receive audio from a media player.
In addition, it should support suitable codec settings and remote control capabilities to deliver high audio quality

5 Recommendations and Motivations

This section summarizes all motivations and recommendations used in the different use cases.

Recommendation 1:

When device capability and network capacity permit, the SRC device should configure the SNK SEP to use the SBC codec parameter settings labeled as High Quality in Table 4.7 of [1]. Use of SBC codec parameter settings that give lower quality than the settings labeled as Medium Quality in Table 4.7 of [1] is not recommended.

Motivation 1:

The recommended settings configure the SNK audio decoder to support high quality audio.

Recommendation 2:

When device capability and network capacity permit, the SRC device should encode and stream all SBC frames using the maximum SBC bitpool value previously agreed with the SNK device in the A2DP stream configuration procedure.

Motivation 2:

The configuration of the maximum SBC bitpool value sets an upper bound on audio quality. However this upper bound on quality is only achieved when the bitpool value used for the encoding equals the maximum bitpool value that was configured.

Recommendation 3:

Despite the motivation for high audio quality, the SRC device should not disconnect from a SNK device that will not accept the High Quality setting described in Table 4.7 of [1]. The AVDTP Signaling Channel should remain connected. The SRC may then request SNK SEP settings with a lower quality and bitrate.

Motivation 3:

There are two reasons for this. The first is for backwards compatibility with legacy RD devices. The second is that there may be reasons that an RD does not have the slot-bandwidth required to support that configuration, for example, the RD may be in a scatternet.

Recommendation 4:

If the audio input to the SBC encoder of the SRC device is not one of the four supported sample rates listed in Table 4.2 of [1], the SRC should perform sample rate conversion to raise the sample rate to the next-highest sample rate listed in Table 4.2 of [1] . Care should be taken that the filter characteristics of sample rate converters, including passband ripple, transition band width and stopband attenuation, are appropriate for the desired system-level audio quality. If the audio input to the SBC encoder of the SRC device is already sampled at a rate natively supported by SBC then the rate should not be further converted before SBC encoding.

Motivation 4:

Extraneous sample rate conversion is avoided and any conversion that is required involves raising the sample rate and utilizing sample rate converters with suitable characteristics. This approach minimizes audio quality degradation due to rate conversion.

Recommendation 5:

If the RD does not possess a suitable UI for volume adjustment then both the RD and MP should implement volume control using suitable signaling from the Audio/Video Remote Control Profile [2], [3] in preference to direct manipulation of the audio data by the RD. The MP and RD should respectively support the AVRCP CT and TG roles. An exception to this recommendation is if environmental or legislative constraints make it unsafe to allow remote volume adjustment, for example in an automotive environment.

Motivation 5:

The recommended approach to volume control avoids audio quality degradation caused by the SRC device manipulating audio data to simulate a volume control.

Recommendation 6:

If the RD does not possess a suitable UI for volume adjustment then both the RD and MP should support Absolute Volume Control as defined in AVRCP 1.4 [3] unless environmental or legislative constraints make it unsafe to allow remote volume adjustment, for example in an automotive environment. The MP and RD should respectively support the AVRCP CT and TG roles. Use of the Absolute Volume Control procedure described in this Recommendation is strongly preferred to other AVRCP volume control procedures, except for the purpose of backwards compatibility.

Motivation 6:

The recommended approach to volume control audio quality degradation caused by the SRC device manipulating audio data to simulate a volume control. In addition, the recommended form of volume control improves volume control synchronization between MP and RD and prevents volume saturation.

Recommendation 7:

The MP should support the AVRCP setting called “Equalizer ON/OFF Status” in the Player Application Settings. If the RD tells the MP to set this value to OFF as an argument included in the Set Player Application Setting Value command, the MP should turn off all DSP processing it may be performing on the audio transmitted over AVDTP, for example equalization or spatial effects.

Motivation 7:

The recommended approach avoids audio quality degradation caused by similar audio signal processing being carried out on both the RD and MP. If the MP does not apply any audio processing, this recommendation is not applicable.

Recommendation 8:

The MP should not alter the digital bit-stream to implement volume control if the RD implements any alternative form of volume control; see Recommendations 6 and 7 above.

Motivation 8:

Having two methods for adjusting the volume is confusing, and creates the potential for a scenario in which one volume setting is set to minimum and the other is set to maximum. This can lead to increased levels of audio distortion.