This article is also available in Russian / Эта статья также доступна на русском языке

The mass market of smartphones without the 3.5 mm audio jack changed headphones industry, wireless Bluetooth headphones have become the main way to listen to music and communicate in headset mode for many users.
Bluetooth device manufacturers rarely disclose detailed product specifications, and Bluetooth audio articles on the Internet are contradictory and sometimes incorrect. They do not tell about all the features, and often publish the same false information.
Let's try to understand the protocol, the capabilities of Bluetooth stacks, headphones and speakers, Bluetooth codecs for music and speech, find out what affects the quality of the transmitted audio and the delay, learn how to capture and decode information about supported codecs and other device features.

TL;DR:

• SBC codec is OK
• Headphones have their own per-codec equalizer and post processing configuration
• aptX is not as good as the advertisements say
• LDAC is a marketing fluff
• Voice audio quality is still low
• Browsers are able to execute audio encoders compiled to WebAssembly from C using emscripten, and they won't even lag.

Music via Bluetooth

The functional components of Bluetooth are defined by profiles—documented features formalized in specifications. Bluetooth music is transmitted using a high-quality audio A2DP transmission profile. The A2DP standard was adopted in 2003, and has not changed drastically since then.
The profile standardize one mandatory codec—SBC, a low computational complexity codec created specifically for Bluetooth, and 3 additional codecs. One can also use vendor-specific codecs of your own implementation, not included into A2DP.

As of June 2019, we live in XKCD comic with 14 A2DP codecs:

• SBC < included into A2DP, supported by all devices
• MPEG-1/2 Layer 1/2/3 < included into A2DP: widely-known MP3, common in digital TV MP2, and obsolete MP1
• MPEG-2/4 AAC < included into A2DP
• ATRAC < Sony's old codec, included into A2DP
• LDAC < Sony's new codec
• aptX < codec from 1988
• aptX HD < the same as aptX but with different encoding profile
• aptX Low Latency < totally different codec, no software implementation
• aptX Adaptive < another Qualcomm codec
• FastStream < pseudo-codec, SBC bidirectional modification
• HWA LHDC < Huawei’s New Codec
• Samsung HD < supported by 2 devices
• Samsung Scalable < supported by 2 devices
• Samsung UHQ-BT < supported by 3 devices

You may wonder why we need a codec in the first place, if Bluetooth has EDR, which allows you to transfer data at 2 or 3 Mb/s while uncompressed two-channel 16-bit PCM requires only 1.4 Mb/s?

Bluetooth Data Transfer

There are two types of data transfer in Bluetooth: Asynchronous Connection Less (ACL) for asynchronous transfer without establishing a connection, and Synchronous Connection Oriented (SCO), for synchronous transfer with connection establishment.
Data transmission uses time-division scheme and changes frequency channel for each transmitted data packet (Frequency-Hop/Time-Division-Duplex, FH/TDD). The time is divided into 625 microsecond intervals, called slots. One of the devices transmits in even numbers of slots, the other—in odd numbers. A transmitted packet can occupy 1, 3 or 5 slots, depending on the size of the data and the transmission mode. If the packet is big enough and more than one slot transmission mode is used, the data is carried out in even and odd slots until the end of the transmission. In one second you can receive and send up to 1600 packets if each of them occupies 1 slot and both devices continuously transmit and receive data.

Transfer rates of 2 or 3 Mbps for EDR found in announcements and on Bluetooth website are the maximum channel data transfer rate of all data in total (including the technical headers of all protocols for data to be encapsulated into) in two directions simultaneously. The actual data transfer rate will vary greatly.

Asynchronous method is used for music streaming, almost always using 2-DH5 and 3-DH5 type packets, which carry the maximum amount of data in 2 Mb/s and 3 Mb/s EDR modes respectively and occupy 5 time division slots.

Schematic representation of transmission using 5 slots by one device and 1 slot by another (DH5/DH1):


Due to time sharing principle, we have to wait for a 625 microsecond time slot after transmitting a packet if the second device does not transmit anything to us or transmits a small packet, and more time if the second device performs transmission in large packets. If more than one device is connected to the phone (e. g. headphones, smart watch and a fitness bracelet), then the transmission time is shared between them all.

A2DP audio streaming requires encapsulation in a special transport protocols L2CAP and AVDTP which deduct 16 bytes from the maximum possible amount of audio payload in the packet.
1414 and 1429 kbps are just not enough to transmit uncompressed audio in real-world conditions, with a noisy 2.4 GHz band and occasional service data. EDR 3 Mbps is demanding of transmit power and signal/noise ratio, so even in 3-DH5 mode no comfortable PCM transmission is possible, as there will always be short-term interruptions and everything will work more or less reliable only at a distance of a couple of meters.
In practice, even 990 kb/s audio stream (LDAC 990 kb/s) is not trivial to transmit reliably.

Let's get back to the codecs.

SBC

This codec is mandatory for all devices supporting A2DP standard. The best and the worst codec at the same time.



SBC is a simple and computationally fast codec with a primitive psychoacoustic model (with simple auditory masking) using adaptive pulse code modulation (APCM).
A2DP specification recommends using two profiles: Middle Quality and High Quality.


The codec has many settings that allow you to control the algorithmic delay, number of samples in the block and bit allocation algorithm, but almost always the parameters used in the specification are used everywhere: Joint Stereo, 8 frequency bands, 16 blocks in the audio frame, Loudness bit allocation method.
SBC can adjust bitpool parameter dynamically, which directly affects the bitrate. If the radio is clogged, packets are lost, or devices are far away, the audio source can reduce bitpool to prevent audio disruptions until the connection is stable again.

Manufacturers of most headphones set the maximum value of bitpool parameter to 53, which limits the bitrate to 328 kilobits per second when using the recommended profile.
Even if the headphone manufacturer has set the maximum bitpool value above 53 (which is true, for instance, for Beats Solo?, JBL Everest Elite 750NC, Apple AirPods, and also for some receivers and car head units), most OS will not allow using higher bit rates due to internal limits ??in Bluetooth stacks.
In addition, some manufacturers set low maximum bitpool value for some devices. For example, in Bluedio T it equals to 39, in Samsung Gear IconX it is 37, which gives poor sound quality.

The artificial limitations were introduced in Bluetooth stacks probably due to insufficient amount of certification tests and incompatibility of some devices with large Bitpool values or atypical profiles, even if they report to support them. It was easier for the developers to restrict the options to known-good values of a recommended profile, rather than creating database of incompatible devices. Though now they do this for other incorrectly working functions.

SBC dynamically allocates quantization bits for frequency bands, acting from bottom to top, with different weights. If the entire bit rate was used for low and middle frequencies, the upper frequencies will be cut off (replaced by silence).

Example of SBC 328 kbps. Original audio is on the top, SBC-encoded audio is on the bottom. The tracks are switched for comparison. Audio stream in the video file is compressed using FLAC lossless codec. Using FLAC in the mp4 container is not officially standardized, that's why the audio may not play in your browser (should work in the latest versions of desktop Chrome and Firefox). If you do not have sound, you can download the file and open it in any video player.
ZZ Top — Sharp Dressed Man

The moment of switching is visible on the spectrogram: SBC periodically cuts quiet sounds above 17.5 kHz, and does not allocate bits at all for a band above 20 kHz. The spectrogram is clickable (1.7 MB).


I can not hear the difference between the original and the SBC on this track.

Let's take something newer and simulate audio quality of Samsung Gear IconX headphones with Bitpool 37 (top is the original stream, bottom is SBC 239 kbps, FLAC is used for audio).
Mindless Self Indulgence — Witness

I hear crackle, a smaller stereo effect and an unpleasant «clatter» of vocals at high frequencies.

To sum up, SBC is a very flexible codec: it can be configured for low latency, gives excellent audio quality at high bitrates (452+ kb/s) and is quite good for most people on standard High Quality (328 kb/s). However, there are a few reasons why the codec is infamous for its low sound quality: A2DP standard does not define fixed profiles (it only gives recommendations), Bluetooth stack developers set artificial limits on Bitpool, the parameters of the transmitted audio are not displayed in the user interface, and headphone manufacturers are free to set their settings and never specify the Bitpool value in technical characteristics of the product.
The bitpool parameter directly affects the bitrate only within one profile. The same bitpool value of 53 can produce both the 328 kbps bitrate with the recommended High Quality profile, and 1212 kbps in Dual Channel mode and 4 frequency bands, which is why the OS authors also set limits on bitrate in addition to bitpool. I assume the situation arose due to the flaw in the A2DP standard: it was necessary to negotiate the bitrate, not bitpool.

Table of SBC features supported in different OS:
* Bitpool decreases, but does not increase automatically in case of varying transmission conditions. To restore bitpool, you need to stop playback, wait a couple of seconds and restart the audio.
** The default value depends on the stack settings specified when compiling the firmware. In Android 8/8.1 the frequency is only either 44.1 kHz or 48 kHz, depending on the settings when compiling, other versions support 44.1 kHz and 48 kHz simultaneously.
*** Bitpool value can be adjusted using Bluetooth Explorer software.

aptX and aptX HD

aptX is a simple and computationally fast codec, without psychoacoustics, which uses adaptive differential pulse code modulation (ADPCM). It appeared around 1988 (patent filing date is February 1988). Before Bluetooth, it was used mostly for professional wireless audio equipment. Currently owned by Qualcomm, it requires licensing and license fees. As of 2014: $6,000 one-time payment and ? $1 per-device, for batches of up to 10,000 devices (source, page 16).

The codec has only one parameter—sampling rate. Although there's also channel number/mode configuration option, all devices I know only support stereo (70+ models).

* Versions up to 7 require modification of Bluetooth stack. The codec is supported only if the manufacturer of Android device has licensed the codec usage from Qualcomm (if the OS has encoding libraries included).

aptX splits audio into 4 frequency bands and quantizes them with the same number of bits continuously: 8 bits for 0-5.5 kHz, 4 bits for 5.5-11 kHz, 2 bits for 11-16.5 kHz, 2 bits for 16.5-22 kHz (values for 44.1 kHz sample rate).

aptX audio example (top—original audio, bottom—aptX-encoded audio, spectrograms of left channels only, sound in FLAC):

The upper frequencies are a little redder, but the difference is not audible.

Due to the fixed distribution of quantization bits, the codec cannot “transfer the bits” to frequencies that need them most. Unlike SBC, aptX will not “cut off” frequencies, but will add quantization noise to them, reducing the dynamic range of the audio.

We should not assume that using, for example, 2 bits for a band reduces the dynamic range to 12 dB: ADPCM allows up to 96 dB of dynamic range to be used, even with 2 quantization bits, but only with a certain type of signal.
ADPCM stores the difference between the current and the next value in numerical representation, instead of using the absolute value, as in PCM. This reduces the requirements for the number of bits needed to store the same (without loss) or almost the same (with relatively small rounding error) information. To reduce rounding errors, factor tables are applied.
When creating the codec, the authors calculated ADPCM coefficients on a set of music audio files. The closer audio signal is to the set of music on which the tables were built, the less quantization errors (noise) are generated by aptX.

Because of this, synthetic tests will always produce worse results than music. I made a special synthetic example in which aptX performs badly—a 12.4 kHz sine wave (top—original signal, bottom—aptX. Sound in FLAC. Ear rape, decrease the volume!):

Spectrum Graph:


Noise is clearly audible.

However, if you generate a sine wave with a smaller amplitude so that it is quieter, the noise will also become quieter, which indicates a wide dynamic range:


To hear the difference between an original music track and a compressed one, you can invert one of the signals and add tracks to respective channels. This approach is incorrect in general and would not give proper results with more complex codecs, but for ADPCM-class codec usage of this method is reasonable.
The difference between original and aptX-encoded audio
The root mean square difference of the signals is at the level of -37.4 dB, which is not much for such compressed music.

aptX HD

aptX HD is not a standalone codec—it is an improved aptX encoding profile. The changes affect the number of bits allocated for frequency bands encoding: 10 bits for 0-5.5 kHz, 6 bits for 5.5-11 kHz, 4 bits for 11-16.5 kHz, 4 bits for 16.5-22 kHz (values for 44.1 kHz).

* Versions up to 7 require modification of Bluetooth stack. The codec is supported only if the manufacturer of Android device has licensed the codec usage from Qualcomm (if the OS has encoding libraries included).

This codec is less common than aptX: it seems to require separate licensing from Qualcomm, and separate licensing fees.

Let's repeat the example with a 12.4 kHz sine wave:


Much better than with aptX, but still noisy.

aptX Low Latency

A Qualcomm codec that has nothing to do with standard aptX and aptX HD, judging by the limited information from people involved in its development. It was designed for interactive audio transmission with low latency (movies, games), where the sound delay can not be adjusted programmatically. There are no known software implementations of encoders and decoders. It is supported exclusively by transmitters, receivers, headphones and speakers, but not smartphones and computers.

AAC

AAC, or Advanced Audio Coding, is a computationally sophisticated codec with a complex psychoacoustic model. It is widely used for audio on the Internet, the second most popular codec after MP3. Requires licensing and license fees: $15,000 one-time payment (or $1000 for companies with less than 15 employees) + $0.98 for the first 500,000 devices (source).
The codec is standardized within MPEG-2 and MPEG-4 specifications, and, despite frequent misbelief, does not belong to Apple.

* only on devices whose manufacturers paid royalties

iOS and macOS contain the best Apple AAC encoder available to date, producing the highest possible audio quality. Android uses the second-best Fraunhofer FDK AAC encoder, but also can use various hardware encoders embedded in the platform (SoC) with an unknown encoding quality. According to recent tests published on SoundGuys website, the quality of AAC encoding on different Android phones varies greatly:


Most wireless audio devices have a maximum bitrate of 320 kbps for AAC, some support only 256 kbps. Other bitrates are extremely rare.
AAC provides excellent quality at 320 and 256 kb/s bit rates, but is prone to generation loss on already compressed content, however it’s difficult to hear any differences between the original and AAC 256 kb/s on iOS, even with several consecutive encodings. For MP3 320 kbps encoded into AAC 256 kbps the loss can be neglected.
Just as with any other Bluetooth codec, any music is first decoded then encoded with a codec. When listening to music in AAC format, it is first decoded by the OS, then encoded into AAC again, for transmission over Bluetooth. This is necessary to mix several audio streams such as music and new message notifications. iOS is no exception. You can find a lot of statements that iOS does not transcode music in AAC format for transmission via Bluetooth, which is incorrect.

AAC has many extensions to the standard encoding method. One of them—Scalable To Lossless (SLS)—is standardized for Bluetooth and allows you to transfer lossless audio. Unfortunately, no SLS support could be found on existing devices. An extension to reduce transmission delay AAC-LD (Low Delay) is not standardized for Bluetooth.

MP1/2/3

MPEG-1/2 Part 3 codecs consist of well-known and widely used MP3, the less common MP2 (used primarily in digital TV and radio), and the completely unknown MP1.

The old MP1 and MP2 codecs are not supported at all, I could not find any headphones or any Bluetooth stack that would encode or decode them.
MP3 decoding is supported by some headphones, but encoding is not supported on any modern operating system stack. It seems that the third-party BlueSoleil stack for Windows can encode MP3 if you manually edit the configuration file, but on my installation it leads to BSoD on Windows 10. The result: you can’t actually use a codec for Bluetooth audio.
Previously, in 2006-2008, before the A2DP standard was widely used in devices, people listened to MP3 music on the Nokia BH-501 headset through the MSI BluePlayer program, which was available on Symbian and Windows Mobile. At that time, the OS architecture of smartphones allowed access to many low-level functions, it was even possible to install third-party Bluetooth stack on Windows Mobile.

The latest patent of the MP3 codec has expired, the use of the codec does not require license fees since April 23, 2017.

If the longest-running patent mentioned in the aforementioned references is taken as a measure, then the MP3 technology became patent-free in the United States on 16 April 2017 when U.S. Patent 6,009,399, held by and administered by Technicolor, expired.

Source: www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html

LDAC

New and actively promoted «Hi-Res» codec from Sony that supports sampling rates up to 96 kHz and 24-bit depth, with a bitrate up to 990 kbps. It is advertised as an audiophile codec, as a replacement for existing Bluetooth codecs. It has an adaptive bitrate function which tunes bitrate depending on the radio transmission conditions.

The LDAC encoder (libldac) is included in the standard Android distribution, encoding is supported on any Android smartphone starting with OS version 8. Software decoders are not freely available and the codec specification is not available to the general public, however, at first glance at the encoder, the internals are similar to Sony's ATRAC9 codec used in PlayStation 4 and Vita: both work in the frequency domain, use a modified discrete cosine transform (MDCT) and Huffman compression.
LDAC split audio into 12 or 16 frequency bands: 12 is used for 44.1 and 48 kHz, 16 for 88.2 and 96 kHz.

LDAC is supported almost exclusively only by Sony headphones. LDAC decoding is sometimes found on headphones and DACs from other manufacturers, but very rarely.



LDAC «Hi-Res codec» marketing harms its technical properties: it’s not wise to spend the bitrate to encode and transmit frequencies that are not audible to the human ear and a higher bit depth when it's still not possible to losslessly compress CD quality audio. Fortunately, the codec has two modes of operation: CD audio transmission and Hi-Res audio transmission. In the first case, only 44.1 kHz / 16 bits are transmitted over the air.

Since the LDAC software decoder is not freely available, it is not possible to test the codec without additional devices that decode LDAC. According to the results of the LDAC test on the DAC with its support, which SoundGuys.com engineers connected via the digital output and recorded the output sound of the test signals, the LDAC 660 and 990 kbit/s in CD quality mode provides a signal-to-noise ratio slightly better than that of aptX HD. This is a good result.


Source: www.soundguys.com/ldac-ultimate-bluetooth-guide-20026

LDAC also supports dynamic bitrate outside the established profiles — from 138 kbps to 990 kbps, but as far as I can tell, Android only uses standardized profiles of 303/606/909 and 330/660/990 kbps.

Other codecs

Other A2DP codecs are not widely used. Their support is either almost completely absent, or is only available on certain models of headphones and smartphones.
The A2DP-standardized ATRAC codec has never been used as a Bluetooth codec even by Sony. Samsung HD, Samsung Scalable and Samsung UHQ-BT codecs have very limited support from transmitting and receiving devices. HWA LHDC is too new and only supported three (?) devices.

Audio devices' codec support

Not all manufacturers publish accurate information about codecs supported in certain wireless headphones, speakers, receivers or transmitters. Sometimes it happens that certain codec is supported only for transmission but not for reception (relevant for combined transmitter-receivers), although the manufacturer simply declares “support”, without any notes (I assume that separate licensing of encoders and decoders is to blame). In the cheapest devices, you can never find the declared support for aptX.

Unfortunately, supported codecs are not displayed anywhere on most OS interfaces. Information about current used codec is only present in Android, starting with version 8, and macOS. However, even in these operating systems, only those codecs that are supported by both the phone / computer and headphones will be displayed.

How to find out which codecs the device supports? By capturing and analyzing traffic dump with A2DP negotiation options!
This can be done in Linux, macOS and Android. In Linux you can use Wireshark or hcidump, in macOS Bluetooth Explorer could be used, and in Android use Bluetooth HCI dump save feature available in the developers tools. You will get a dump in btsnoop format, which could be opened in Wireshark analyzer.
NOTE: you'll need to connect from the smartphone/computer to the headphones to capture correct dump, not vice versa (no matter how silly it sounds)! Headphones can also establish a connection to the smartphone or PC, in which case they will request a list of codecs from the phone, and not disclose their own set of codecs. To ensure that you capture a correct dump, first un-pair the device, and then, while recording the dump, pair the phone with the headphones.

Use the following display filter to hide irrelevant traffic:

btavdtp.signal_id

As a result, you should see something similar:


By clicking on GetCapabilities command you can get detailed information of the codec.


Wireshark does not know all codec identifiers, so some of the codecs will have to be decrypted manually, depending on the table of identifiers below:

Mandatory:
0x00 - SBC

Optional:
0x01 - MPEG-1,2 (aka MP3)
0x02 - MPEG-2,4 (aka AAC)
0x04 - ATRAC

Vendor specific:
0xFF 0x004F 0x01   - aptX
0xFF 0x00D7 0x24   - aptX HD
0xFF 0x000A 0x02   - aptX Low Latency
0xFF 0x00D7 0x02   - aptX Low Latency
0xFF 0x000A 0x01   - FastStream
0xFF 0x012D 0xAA   - LDAC
0xFF 0x0075 0x0102 - Samsung HD
0xFF 0x0075 0x0103 - Samsung Scalable Codec
0xFF 0x053A 0x484C - Savitech LHDC

0xFF 0x000A 0x0104 - The CSR True Wireless Stereo v3 Codec ID for AAC
0xFF 0x000A 0x0105 - The CSR True Wireless Stereo v3 Codec ID for MP3
0xFF 0x000A 0x0106 - The CSR True Wireless Stereo v3 Codec ID for aptX

You can find out if your device supports EDR 3 Mbps by using the following filter:

bthci_evt.code==0x0b

In order to not analyze the dumps manually, I made a service that will analyze everything automatically: btcodecs.valdikss.org.ru

Codec comparison. Which codec is better?

Each codec has its advantages and disadvantages.
aptX and aptX HD use hard-coded profiles that cannot be changed without modifying the encoder and decoder. Neither the smartphone nor the headphone manufacturer can change the bitrate or coding factors of aptX. Qualcomm, the owner of the codec, distributes the reference encoder as a library to the licensees. These facts are aptX's forte—you know in advance what quality of sound you will get, no buts.

SBC, on the contrary, has many adjustable parameters, dynamic bitrate (the encoder can reduce the bitpool parameter if the radio is congested), and does not have hard-coded profiles, but only the recommended «medium quality» and «high quality» that have been added to the A2DP specification in 2003. “High quality” is no longer as high by modern standards, and most Bluetooth stacks do not allow using parameters that are better than in the “high quality” profile, although there are no technical limitations for this.
Bluetooth SIG does not provide SBC reference encoder in the form of a library, and the manufacturers implement it themselves.
These are SBC's weaknesses—it is never clear in advance what sound quality is to be expected from a particular device. SBC can produce both low and very high sound quality, but the latter is unattainable without disabling or circumventing the artificial limitations of Bluetooth stacks.

The situation with AAC is ambiguous: on one hand, theoretically, the codec should produce quality that is indistinguishable from the original, but practice, judging by the tests of the SoundGuys laboratory on different Android devices, is not confirmed. Most likely, the fault is on low-quality hardware audio encoders embedded in various phone chipsets. It makes sense to use AAC only on Apple devices; with Android you'd better stick with aptX/HD and LDAC.

Devices that supports alternative codecs is usually of higher quality, simply because it does not make sense to pay royalties for very cheap, low-quality devices to use these codecs. According to my tests, SBC sounds very good on high-quality hardware.

I made a web service that encodes audio to SBC, aptX and aptX HD in real time, right in your browser. You can use it to test these audio codecs without actually transmitting audio via Bluetooth, on any wired headphones, speakers, and your favorite music, and also change the encoding parameters directly during audio playback:
btcodecs.valdikss.org.ru/sbc-encoder
The service uses SBC coding libraries from BlueZ project and libopenaptx from ffmpeg, which are compiled into WebAssembly and JavaScript from C via emscripten, for execution in a browser. Who could have dreamed of such a future!

Here's what it looks like:

Notice how the noise level changes after 20 kHz for different codecs. No frequences above 20 kHz present in the original MP3 file.

Try switching codecs and see if you can hear the difference between the original, SBC 53 Joint Stereo (the standard and most common profile), and aptX / aptX HD.

But I can hear the difference between codecs in a headphones!

People who do not hear the difference between codecs while testing via a web service claim they hear it when listening to music with Bluetooth headphones. Unfortunately, that is not a joke or a placebo effect: the difference is really audible, but it is not caused by difference in codecs.

The vast majority of Bluetooth audio chipsets used in receiving wireless devices are equipped with a digital signal processor (DSP) that implements an equalizer, compander, stereo extender, and other things designed to improve (or change) the sound. Bluetooth hardware manufacturers can configure the DSP for each codec separately, and when switching between codecs, the listener will feel that they can hear the difference in the performance of codecs when in reality they are listening to different DSP settings.


Kalimba DSP audio processing pipeline in CSR/Qualcomm SoCs


Activation of various DSP functions for each codec and output separately

Some premium segment devices are equipped with software that allows you to adjust the DSP parameters, but most of the cheaper headphones do not have this feature, and users cannot turn off the post-processing of sound using standard tools.

Devices' functional features

The current version of the A2DP standard has an absolute volume control function allowing to control output gain with special commands by using AVRCP protocol, instead of programmatically reducing the volume of the audio stream itself. If you change the volume on the headphones and the change is not synchronized with the volume on the phone, this means that your headphones or phone do not support this function. In this case, it makes sense to always listen to music at maximum volume on the phone, adjusting the actual volume with the headphone buttons—the signal-to-noise ratio will be better and the audio quality should be higher.
In reality, there are sad situations. By RealForce OverDrive D1 headphones use strong compander for SBC and an increase in volume leads to an increase in the level of quiet sounds, and the volume of loud sounds does not change (signal compression occurs). Because of this, it is necessary to set the volume on the computer to about half, in this case there is practically no compression effect.
According to my observations, all headphones with additional codecs support absolute volume control function, which is probably one of the requirements for codec certification.

Some headphones support connecting two devices at the same time. This allows, for example, to listen to music from a computer and receive calls from a phone. However, you should be aware that alternative codecs are disabled in this mode, and only SBC is used.

The AVDTP 1.3 Delay Reporting feature allows headphones to report a delay to a sending device that actually plays the sound. This helps to adjust the synchronization of audio with video while watching video files: if radio congestion occurs, the audio will not lag behind the video, but on the contrary, the video will be slowed down by the video player until the audio and video are synchronized again.
The feature is supported by many headphones, Android 9+ and Linux with PulseAudio 12.0+. I'm not aware about support in other OS.

Duplex communication over Bluetooth. Voice transmisson.

Synchronous Connection Oriented (SCO) and its enhanced version Enhanced Synchronous Connection Oriented (eSCO) are the modes used for Bluetooth voice transmission. The mode allows you to transmit sound and voice strictly in order, with a symmetrical speed of sending and receiving, without waiting for confirmation of transmission and re-sending packets. This reduces the overall delay in the transmission of audio over the radio channel, but imposes serious restrictions on the amount of data transmitted per unit of time and adversely affects the quality of the audio.
When this mode is used, both the voice from the microphone and the audio are transmitted to the headphones with the same quality.
Transfer of the data itself is standardized by the HSP profile, which also describes additional functions, such as operation of volume control buttons, the pick up of the handset and the hang up.
Unfortunately, as of 2019, the quality of voice transmission via Bluetooth is still poor, and it is not clear why Bluetooth SIG is not doing anything about it.

CVSD

The basic speech transfer codec CVSD was standardized in 2002, and is supported by all bidirectional Bluetooth devices. It provides audio transmission with a sampling frequency of 8 kHz, which corresponds to the quality of conventional wired telephony.

An example of recording in this codec.

mSBC

Additional mSBC codec was standardized in 2009, and in 2010 there were chips that already used it for voice transmission. mSBC is widely supported by various devices.
This is not a standalone codec, but the usual SBC from the A2DP standard, with a fixed encoding profile: 16 kHz, mono, bitpool 26.

An example of recording in this codec.

Not brilliant, but much better than CVSD, though it is still unpleasant to use it to communicate via the Internet, especially when you use headphones for communication in the game — the sound of the game will also be transmitted at a sampling frequency of 16 kHz.

FastStream

CSR decided to further develop the idea of ??re-using SBC. To get around the limitations of the SCO protocol and use higher bit rates, CSR went the other way—they've added support for two-way SBC audio into the one-way audio transmission A2DP standard, and called it «FastStream».

FastStream transmits 44.1 or 48 kHz stereo sound to speakers with a bitrate of 212 kbps. 16 kHz with a bitrate of 72 kbps (slightly better than that of mSBC) is used to transmit audio from a microphone. Such parameters are much better suited for communication in online games—the sound of the game and the teammates will be of high quality.

An example of recording in this codec (+ audio from the mic, the same as in mSBC).

The company came up with an interesting hack, but due to the fact that it contradicts with A2DP standard, only some of the company's transmitters support it (which work as a USB audio card, and not a Bluetooth device), but it did not receive support in Bluetooth stack. The number of headphones with FastStream support is not so small though.

At the moment, FastStream support is available only in the form of a patch for Linux PulseAudio from Pali Rohar, which is not included in the main program branch.

aptX Low Latency

Much to the surprise, aptX Low Latency also supports bidirectional audio, implementing the same principle as FastStream.
There is no way to use this feature of the codec anywhere—there is no support for Low Latency decoding in any OS and in any Bluetooth stack which I'm aware of.

Bluetooth 5, Classic and Low Energy

There is a lot of confusion around the specifications and versions of Bluetooth due to the presence of two incompatible standards under one brand, both of which are widely used for different purposes.

There are two different, incompatible Bluetooth protocols: Bluetooth Classic and Bluetooth Low Energy (LE, also known as Bluetooth Smart). There is also a third protocol, Bluetooth High Speed, but it is not common, and is not used in home appliances.

Beginning with Bluetooth 4.0, the changes in the specifications focused primarily on Bluetooth Low Energy, while the Classic version received only minor improvements.

List of changes between Bluetooth 4.2 and Bluetooth 5:

9 CHANGES FROM v4.2 TO 5.0

9.1 NEW FEATURES

Several new features are introduced in Bluetooth Core Specification 5.0 Release. The major areas of improvement are:
• Slot Availability Mask (SAM)
• 2 Msym/s PHY for LE
• LE Long Range
• High Duty Cycle Non-Connectable Advertising
• LE Advertising Extensions
• LE Channel Selection Algorithm #2
9.1.1 Features Added in CSA5 — Integrated in v5.0
• Higher Output Power

Source: www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=421043 (page 291)

Only one change affected the Classic version within the specification of Bluetooth 5: support for the Slot Availability Mask (SAM) technology, designed to improve radio frequency sharing. All other changes affect only Bluetooth LE (the same applies to Higher Output Power too).

All audio devices use only Bluetooth Classic. Headphones and speakers cannot be connected via Bluetooth Low Energy. There is no standard for transmitting audio using LE. The A2DP standard, used to transmit high-quality audio, works only through Bluetooth Classic, and there is no equivalent in LE.

To sum up: buying audio devices with Bluetooth 5 only because of the new version of the protocol is meaningless. Bluetooth 4.0/4.1/4.2 in the context of audio transmission will work the same way.
If the announcement of the new headphone mentions a doubled radius and reduced power consumption thanks to Bluetooth 5, then you should know that they either do not understand themselves or mislead you. No wonder, even the manufacturers of Bluetooth chips confuse the difference in both standards, and some Bluetooth 5 chips support the fifth version only for LE, and use 4.2 for Classic.

Audio transmission latency

The amount of latency (lag) in the audio depends on many factors: the size of the buffer in the audio library, in Bluetooth stack and in the playback device itself, the algorithmic delay of the codec.

The delay of simple codecs, like SBC, aptX and aptX HD is quite small, about 3-6 ms, which can be neglected, but complex codecs, such as AAC and LDAC can give a noticeable delay. Algorithmic delay AAC for 44.1 kHz is 60 ms. LDAC—about 30 ms (by rough analysis of the source code. I can be wrong, but not much.)

The total delay is highly dependent on the playback device, its chipset and buffer. During the tests, I got a spread of 150 to 250 ms on different devices (with the SBC codec). If we assume that devices with support for aptX, AAC, and LDAC additional codecs use better quality components and a small buffer size, we get the following typical latency values:

SBC: 150-250 ms
aptX: 130-180 ms
AAC: 190-240 ms
LDAC: 160-210 ms

Let me remind you: aptX Low Latency is not supported in operating systems, which is why a lower delay can be obtained only with a transmitter + receiver or transmitter + headphone/speaker bundle, and all devices must support this codec.

The problems with certifications, logos and devices

How to distinguish high-quality audio device from cheap crafts? By the appearance, in the first place!

Cheap Chinese headphones, speakers and receivers have:

1. No «Bluetooth» word on the box and the device, most often replaced by «Wireless» and «BT»
2. No Bluetooth logo on box or device
3. No blue flashing LED

The absence of these elements indicates that the device has not been certified, which means that it is potentially problematic or of poor quality. For example, Bluedio headphones are not certified by Bluetooth, and do not fully comply with the A2DP specification. They would not have passed certification process.

Let's look at several devices and boxes from them:






These are all non-certified devices. The instructions may have the logo and «Bluetooth» name, but most importantly—these elements should be present on the device or box itself.

If your headphones or speaker say «Ze bluetooth dewise is connecteda successfulle», this does not say good about quality as well:

Conclusion

Can Bluetooth completely replace wired headphones and headsets? Probably, but at the cost of low quality voice, increased latency in sound transmission, which can be annoying in games, and a multitude of proprietary codecs that require license fees and increase the final cost of both smartphones and headphones.

The marketing of alternative codecs is very strong: aptX and LDAC are presented as a long-awaited replacement of the “outdated and bad” SBC, which is far from as bad as it is commonly thought of.

As it turned out, the artificial limitations of Bluetooth stacks on SBC can be bypassed, so that the SBC will be on par with aptX HD. I took the initiative and made a patch for LineageOS firmware: Modifying Bluetooth stack to improve the sound on headphones without AAC, aptX and LDAC codecs

More information about codecs could be found on SoundGuys and SoundExpert websites.

Bonus: SBC reference encoder, A2DP bitstream information and test files. This file was previously posted on Bluetooth website publicly, but now it is available only to those who have joined Bluetooth SIG.