With the mass release of smartphones without a 3.5 mm audio jack, wireless Bluetooth headphones have become the primary way for many to listen to music and communicate in headset mode.
Wireless device manufacturers do not always provide detailed product specifications, and articles about Bluetooth audio on the internet are inconsistent, sometimes incorrect, do not cover all features, and often replicate the same misleading information.
Let's explore the protocol, the capabilities of Bluetooth stacks on operating systems, headphones and speakers, Bluetooth codecs for music and speech, determine what affects sound quality and latency, and learn how to gather and decode information about supported codecs and other device features.
TL;DR:
- SBC is a standard codec.
- Headphones have their own equalizer and post-processing for each codec separately.
- aptX is not as good as its advertising claims.
- LDAC is marketing nonsense.
- Call quality is still low.
- Audio encoders can be embedded in the browser using C, compiled to WebAssembly via emscripten, and they won’t cause significant lag.
Music over Bluetooth.
The functional aspect of Bluetooth is determined by profiles—specifications for specific functions. Music transmission over Bluetooth is done using the high-quality one-way audio transmission profile A2DP. The A2DP standard was adopted in 2003, and since then it has not changed significantly.
Within the profile, 1 mandatory low-complexity codec SBC, specifically designed for Bluetooth, and 3 additional codecs are standardized. The use of undocumented codecs of proprietary implementation is also permitted.
As of June 2019, we are located with 14 A2DP codecs:
- SBC ← standardized in A2DP, supported by all devices.
- MPEG-1/2 Layer 1/2/3 ← standardized in A2DP: the well-known , used in digital TV. , and the unknown
- MPEG-2/4 AAC ← standardized in A2DP.
- ATRAC ← an old codec from Sony, standardized in A2DP.
- LDAC ← a new codec from Sony.
- aptX ← a codec from 1988.
- aptX HD ← the same as aptX, just with different encoding parameters.
- aptX Low Latency ← a completely different codec, with no software implementation.
- aptX Adaptive ← another codec from Qualcomm.
- FastStream ← a pseudo-codec, a bidirectional modification of SBC.
- HWA LHDC ← new codec from Huawei
- Samsung HD ← supported by 2 devices
- Samsung Scalable ← supported by 2 devices
- Samsung UHQ-BT ← supported by 3 devices
You might ask why codecs are even necessary when Bluetooth has EDR, which allows data transmission at speeds of 2 and 3 Mbps, while for uncompressed two-channel 16-bit PCM, only 1.4 Mbps is needed?
Data transmission via Bluetooth
Bluetooth features two types of data transmission: Asynchronous Connection Less (ACL) for asynchronous transmission without establishing a connection, and Synchronous Connection Oriented (SCO) for synchronous transmission with prior connection agreement.
Transmission is carried out using a time-division frequency-hopping scheme (Frequency-Hop/Time-Division-Duplex, FH/TDD), where time is divided into 625-microsecond intervals called slots. One device transmits during even-numbered slots, while another transmits during odd-numbered slots. The transmitted packet can occupy 1, 3, or 5 slots, depending on the data size and established transmission type; in this case, one device transmits in both even and odd slots until the transmission is complete. A total of up to 1600 packets can be sent and received per second if each occupies 1 slot, provided both devices continuously transmit and receive data.
2 and 3 Mbps for EDR, which can be found in announcements and on the Bluetooth website, represent the maximum channel transmission speed for all data combined (including the technical headers of all protocols that encapsulate the data) in both directions simultaneously. The actual data transmission speed will vary significantly.
To transmit music, an asynchronous method is used, nearly always with packets of type 2-DH5 and 3-DH5, which carry the maximum amount of data at EDR rates of 2 Mbps and 3 Mbps, respectively, occupying 5 slots of time-division spectrum.
A schematic representation of the transmission using 5 slots by one device and 1 slot by another (DH5/DH1):
Due to the principle of time-division duplexing, we have to wait for a 625-microsecond time slot after transmitting a packet if the second device does not send anything or sends a small packet, and for a longer time if the second device is transmitting large packets. If more than one device is connected to the phone (for example, headphones, a watch, and a fitness tracker), the transmission time is divided among all of them.
The need to encapsulate audio in special transport protocols L2CAP and AVDTP takes away 16 bytes from the possible maximum amount of transmitted audio payload.
Packet type
Number of slots
Max. number of bytes in a packet
Max. number of bytes of A2DP payload
Max. bitrate of A2DP payload
2-DH3
3
367
351
936 kbps
3-DH3
3
552
536
1429 kbps
2-DH5
5
679
663
1414 kbps
3-DH5
5
1021
1005
2143 kbps
1414 and 1429 kbps are clearly insufficient for transmitting uncompressed audio in real-world conditions, with the noisy 2.4 GHz band and the need to transmit auxiliary data. EDR 3 Mbps is demanding in terms of transmission power and noise in the air, so even in 3-DH5 mode, comfortable PCM transmission is impossible; there will be constant brief interruptions, and everything will only work at a distance of a couple of meters.
In practice, even a 990 kbps audio stream (LDAC 990 kbit/s) is transmitted with difficulty.
Let's get back to codecs.
SBC
A codec that is mandatory for all devices supporting the A2DP standard. The best and worst codec at the same time.
Sampling frequency
Bit width
Bitrate
Encoding support
Decoding support
16, 32, 44.1, 48 kHz
16 bits
10-1500 kbps
By all devices
By all devices
SBC is a simple and computationally fast codec with a primitive psychoacoustic model (only masking quiet sounds is used), employing adaptive pulse code modulation (APCM).
The A2DP specification recommends the use of two profiles: Middle Quality and High Quality.
The codec has many settings that allow managing algorithmic delay, the number of samples in a block, and the bit allocation algorithm, but almost universally the same recommended parameters are used as in the specification: Joint Stereo, 8 frequency bands, 16 blocks in an audio frame, Loudness bit allocation method.
SBC supports dynamic adjustment of the Bitpool parameter, which directly affects the bitrate. If the radio broadcast is congested, packets are lost, or devices are far apart, the audio source may reduce the Bitpool until the connection stabilizes.
Most headphone manufacturers set the maximum value of the Bitpool parameter at 53, which limits the bitrate to 328 kilobits per second when using the recommended profile.
Even if a headphone manufacturer has set the maximum Bitpool value above 53 (such models include, for example: Beats Solo³, JBL Everest Elite 750NC, Apple AirPods, and some receivers and car head units), most operating systems will not allow the use of higher bitrates due to internal limitations in Bluetooth stacks.
Additionally, some manufacturers set a low maximum Bitpool value for certain devices. For example, for Bluedio T it is 39, and for Samsung Gear IconX — 37, which results in poor sound quality.
Artificial limitations imposed by Bluetooth stack developers likely arose due to incompatibility of certain devices with high Bitpool values or atypical profiles, even if they claimed support, and insufficient testing during certification. It was easier for Bluetooth stack authors to stick to the recommended profile rather than create a database of incorrectly functioning devices (though they are now doing this for other malfunctioning features).
SBC dynamically allocates bits of quantization for frequency bands, working from low to high frequencies, with different weighting coefficients. If the entire bitrate is used for low and mid frequencies, high frequencies will be 'cut off' (resulting in silence instead).
Example SBC 328 kbps. At the top is the original, and at the bottom is SBC, with periodic switching between tracks. For audio in the video file, a lossless compression codec FLAC is used. Using FLAC in an mp4 container is not officially standardized, so it’s uncertain whether your browser will play it, but it should work in the latest desktop versions of Chrome and Firefox. If you do not hear sound, you can download the file and open it in a full-featured media player.
ZZ Top — Sharp Dressed Man
The spectrogram shows the moment of switching: SBC periodically cuts quiet sounds above 17.5 kHz and does not allocate any bits for the range above 20 kHz. The full spectrogram is available by clicking (1.7 MB).
I don't hear a difference between the original and SBC on this track.
Let's take something newer and simulate the audio that would result from using Samsung Gear IconX headphones with Bitpool 37 (above — original signal, below — SBC 239 kbps, sound in FLAC).
Mindless Self Indulgence — Witness
I hear crackling, reduced stereo effect, and an unpleasant 'clicking' of the vocals in the high frequencies.
Although SBC is a very flexible codec that can be tuned for low latency, it offers excellent audio quality at high bitrates (452+ kbps) and is quite good for most people at the standard High Quality (328 kbps). Since the A2DP standard does not set fixed profiles (but only gives recommendations), stack developers impose artificial limitations on Bitpool, audio parameters are not displayed in the user interface, and headphone manufacturers are free to set their own settings and never specify the Bitpool value in the product specifications. The codec has gained a reputation for low sound quality, although this is not a problem with the codec itself.
The Bitpool parameter directly affects the bitrate only within a single profile. The same Bitpool value of 53 can yield a bitrate of 328 kbps under the recommended High Quality profile, as well as 1212 kbps with Dual Channel and 4 frequency bands. This is why OS authors, in addition to the Bitpool limitations, also impose a limit on Bitrate. In my view, this situation arose from the shortcomings of the A2DP standard: it should have been necessary to agree on the bitrate rather than Bitpool.
Table of SBC capability support in different operating systems:
OS
Supported sampling frequencies
Max Bitpool limit
Max Bitrate limit
Typical Bitrate
Dynamic Bitpool adjustment
Windows 10
44.1 kHz
53
512 kbps
328 kbps
✓*
Linux (BlueZ + PulseAudio)
16, 32, 44.1, 48 kHz
64 (for incoming connection), 53 (for outgoing)
No limit
328 kbps
✓*
macOS High Sierra
44.1 kHz
64, default 53***
Unknown
328 kbps
✗
Android 4.4-9
44.1/48 kHz**
53
328 kbps
328 kbps
✗
Android 4.1-4.3.1
44.1, 48 kHz**
53
229 kbps
229 kbps
✗
Blackberry OS 10
48 kHz
53
No limit
328 kbps
✗
* The Bitpool only decreases, but does not increase automatically when transmission conditions improve. To restore the Bitpool, you need to stop playback, wait a couple of seconds, and restart the audio.
** The default value depends on the stack settings specified during firmware compilation. In Android 8/8.1, the frequency is either 44.1 kHz or 48 kHz, depending on the compilation settings, while in other versions, both 44.1 kHz and 48 kHz are supported simultaneously.
*** The Bitpool value can be raised in the Bluetooth Explorer application.
aptX and aptX HD
aptX is a simple and computationally fast codec, without psychoacoustics, using adaptive differential pulse-code modulation (). It appeared around 1988 (the patent submission date , p. 16).aptX and aptX HD are the same codec, with different encoding profiles.
The codec has only one parameter—the choice of sampling frequency. There is also the option to select the number/mode of channels, but in all the devices I am aware of (over 70), only Stereo is supported.
Codec
128 / 256 / 352 / 384 kbps (depending on the sampling frequency)
Sampling frequency
Bit width
Bitrate
Encoding support
Decoding support
aptX
16, 32, 44.1, 48 kHz
16 bits
Windows 10 (desktop and mobile), macOS, Android 4.4+/7*, Blackberry OS 10
A wide range of audio devices (hardware)
Versions prior to 7 require modification of the Bluetooth stack. The codec is supported only if the Android device manufacturer has licensed the codec from Qualcomm (if the OS has encoding libraries).
* aptX divides audio into 4 frequency bands and quantizes them with the same number of bits constantly: 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 (numbers for a sampling frequency of 44.1 kHz).
An example of aptX audio (above is the original signal, below is aptX, spectrograms of only the left channels, sound in FLAC):
The higher frequencies became slightly redder, but the difference is not audible.
The upper frequencies became a bit redder, but the difference is not noticeable.
Due to the fixed distribution of quantization bits, the codec cannot 'shift bits' to the frequencies that need them the most. Unlike SBC, aptX does not 'cut' frequencies but adds quantization noise, reducing the dynamic range of the audio.
It should not be assumed that using, for example, 2 bits for the band reduces the dynamic range to 12 dB: ADPCM allows for a dynamic range of up to 96 dB even when using 2-bit quantization, but only under certain signals.
ADPCM stores the difference in numerical representation between the current and the next sample instead of recording the absolute value, as in PCM. This reduces the number of bits required to store the same (lossless) or virtually the same (with relatively small rounding error) information. Coefficient tables are applied to reduce rounding errors.
When creating the codec, the authors calculated the ADPCM coefficients based on a set of musical audio files. The closer the audio signal is to the set of music on which the tables were built, the fewer quantization errors (noise) aptX creates.
As a result, synthetic tests will always yield worse results than music. I made a special synthetic example where aptX shows poor results — a sine wave at a frequency of 12.4 kHz (top — original signal, bottom — aptX. Sound in FLAC. Lower the volume!):
Spectrum chart:
Noise is distinctly audible.
However, if a sine wave is generated with a lower amplitude to make it quieter, the noise will also become quieter, indicating a wide dynamic range:
To hear the difference between the original music track and the compressed one, one can invert one of the signals and mix the tracks channel by channel. This approach, in general, is incorrect and would not yield reasonable results with more complex codecs, but is quite suitable for ADPCM.
The root mean square difference of the signals is at -37.4 dB, which is not much for such compressed music.
aptX HD
aptX HD is not a standalone codec — it is an enhanced encoding profile of the aptX codec. Changes relate to the number of bits allocated for encoding frequency ranges: 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 (numbers for 44.1 kHz).
128 / 256 / 352 / 384 kbps (depending on the sampling frequency)
Sampling frequency
Bit width
Bitrate
Encoding support
Decoding support
aptX HD
16, 32, 44.1, 48 kHz
24 bits
192 / 384 / 529 / 576 kbps (depending on the sampling rate)
Android 8+*
By some audio devices (hardware)
* aptX divides audio into 4 frequency bands and quantizes them with the same number of bits constantly: 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 (numbers for a sampling frequency of 44.1 kHz).
Less common than aptX: apparently requires separate licensing from Qualcomm, and separate royalty payments.
Let's repeat the example with a sine wave at 12.4 kHz:
Much better than with aptX, but still noisy.
aptX Low Latency
A codec from Qualcomm, unrelated to the standard aptX and aptX HD, according to limited information from those involved in its development. Designed for interactive audio transmission with low latency (movies, games), where sound delay cannot be adjusted programmatically. Known software implementations of encoders and decoders are absent, supported exclusively by transmitters, receivers, headphones, and speakers, but not smartphones and computers.
Sampling frequency
Bitrate
Encoding support
Decoding support
44.1 kHz
276/420 kbps
By some transmitters (hardware)
By some audio devices (hardware)
AAC
AAC, or Advanced Audio Coding — a computationally intensive codec with a serious psychoacoustic model. It has become widely adopted for audio on the internet, second in popularity only to MP3. Requires licensing and royalty payments: $15,000 one-time payment (or $1,000 for companies with fewer than 15 employees) + $0.98 for the first 500,000 devices ().
The codec is standardized under MPEG-2 and MPEG-4 specifications, and contrary to a common misconception, it does not belong to Apple.
Sampling frequency
Bitrate
Encoding support
Decoding support
8 — 96 kHz
8 — 576 kbps (for stereo), 256 — 320 kbps (typical for Bluetooth)
macOS, Android 7+*, iOS
Versions prior to 7 require modification of the Bluetooth stack. The codec is supported only if the Android device manufacturer has licensed the codec from Qualcomm (if the OS has encoding libraries).
* only on devices whose manufacturers have paid royalty fees
In iOS and macOS, the best codec available today, Apple's AAC, is used, providing the highest possible audio quality. In Android, the second-best quality encoder, Fraunhofer FDK AAC, is used, but various hardware encoders built into the platform (SoC) may be employed, with unknown encoding quality. , the encoding quality of AAC varies significantly among different Android phones:
Most wireless audio devices set a maximum bitrate of 320 kbps for AAC, while some only support 256 kbps. Other bitrates are extremely rare.
AAC delivers excellent quality at bitrates of 320 and 256 kbps, but is prone to however, it’s difficult to hear any differences from the original on iOS at a bitrate of 256 kbps, even after several successive encodings; in a single encoding, for example, MP3 at 320 kbps to AAC at 256 kbps, the losses can be neglected.
As with other Bluetooth codecs, any music is first decoded and then re-encoded by the codec. When listening to music in AAC format, it is first decoded by the OS, then re-encoded to AAC for transmission over Bluetooth. This is necessary for mixing multiple audio streams, such as music and new message notifications. iOS is no exception. There are many claims online that music in AAC format is not transcoded on iOS during Bluetooth transmission, which is incorrect.
MP1/2/3
The MPEG-1/2 Part 3 codecs include the well-known and widely used MP3, the less common MP2 (primarily used in digital TV and radio), and the completely unknown MP1.
Older MP1 and MP2 codecs are not supported at all: I couldn't find any headphones or any Bluetooth stack that could encode or decode them.
MP3 decoding is supported by some headphones, but encoding is not supported by any current operating system stacks. It seems that the third-party BlueSoleil stack for Windows can encode to MP3 if the configuration file is manually altered, but installing it leads to a BSOD on Windows 10. The conclusion is that the codec is effectively unusable for Bluetooth audio.
Previously, in 2006-2008, before the A2DP standard was widely adopted in devices, people listened to MP3 music on the Nokia BH-501 headset through the MSI BluePlayer app, which was available on Symbian and Windows Mobile. At that time, the smartphone OS architecture allowed access to many low-level functions, and on Windows Mobile, it was even possible to install third-party Bluetooth stacks.
The last patent for the MP3 codec expired, and using the codec does not require any licensing 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 April 16, 2017, when U.S. Patent 6,009,399, held by and administered by Technicolor, expired.
Source:
Sampling frequency
Bitrate
Encoding support
Decoding support
16 — 48 kHz
8 — 320 kbps
Not supported anywhere
By some audio devices (hardware)
LDAC
A new and actively promoted 'Hi-Res' codec from Sony that supports sampling rates up to 96 kHz and 24-bit depth, with a bitrate of up to 990 kbps. It is marketed as an audiophile codec, designed to replace existing Bluetooth codecs. It features adaptive bitrate adjustment depending on radio conditions.
The LDAC encoder () is included in the standard Android installation, so encoding is supported on any Android smartphone starting from version 8. Software decoders are not available for free, the codec specification is not public, however, a first glance at the encoder shows that the internal structure of the codec is similar to , a codec from Sony used in PlayStation 4 and Vita: both operate in the frequency range, use modified discrete cosine transformation (MDCT), and compress using Huffman coding.
LDAC support is primarily found on Sony headphones. Decoding capability is sometimes found on headphones and DACs from other manufacturers, but very rarely.
Sampling frequency
Bitrate
Encoding support
Decoding support
44.1 — 96 kHz
303/606/909 kbps (for 44.1 and 88.2 kHz), 330/660/990 kbps (for 48 and 96 kHz)
Android 8+
By some Sony headphones and a few devices from other manufacturers (hardware-wise)
Marketing LDAC as a Hi-Res codec undermines its technical aspects: it is foolish to waste bitrate on transmitting frequencies inaudible to the human ear and increased depth when it is not sufficient for lossless CD-quality (44.1/16) transmission. Fortunately, the codec has two operating modes: CD audio transmission and Hi-Res audio transmission. In the first case, only 44.1 kHz/16 bits is transmitted wirelessly.
Since there is no software decoder for LDAC available for free, it is impossible to test the codec without additional devices that decode LDAC. According to tests of LDAC on a DAC with its support, which engineers from SoundGuys.com connected via digital output and recorded the output sound on test signals, LDAC at 660 and 990 kbps in CD-quality mode provides a signal-to-noise ratio slightly better than aptX HD.
Source:
LDAC also supports a 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 have not gained widespread adoption. Their support is either virtually nonexistent, or available only on specific models of headphones and smartphones.
The standardized A2DP codec ATRAC has never been used as a Bluetooth codec even by Sony itself, while Samsung HD, Samsung Scalable, and Samsung UHQ-BT codecs have very limited support from transmitting and receiving devices, and HWA LHDC is too new and only supported by three (?) devices.
Codec Support by Audio Devices
Not all manufacturers provide accurate information about the codecs supported by specific wireless headphones, speakers, receivers, or transmitters. Sometimes, the support for a particular codec exists only for transmission but not for reception (this is relevant for combined transmitter-receiver devices), even though the manufacturer claims simply "support," without any notes (I suspect this is due to the separate licensing of encoders and decoders for some codecs). The cheapest devices may not even exhibit the claimed support for aptX.
Unfortunately, in the interfaces of most operating systems, the used codec is not displayed anywhere. This information is only available on Android, starting from version 8, and macOS. However, even in these OS, only those codecs will be displayed that are supported by both the phone/computer and the headphones.
So how do you find out which codecs a device supports? Record and analyze the A2DP negotiation traffic dump!
This can be done in Linux, macOS, and Android. In Linux, you can use Wireshark or hcidump, in macOS — Bluetooth Explorer, and in Android — the built-in Bluetooth HCI dump saving function available in developer tools. You will get a dump in btsnoop format, which can be uploaded to the Wireshark analyzer.
Note thatA correct dump can only be obtained by connecting your phone/computer to the headphones/speaker (as absurd as it may sound)! The headphones can connect to the phone on their own, and in this case, they will request the list of codecs from the phone, not vice versa. To ensure a proper dump, first disconnect from the device, and then, during the dump recording, pair the phone with the headphones.
Use the following display filter to filter out irrelevant traffic:
btavdtp.signal_idAs a result, you should see something similar:
You can click on each item in the GetCapabilities command to view detailed codec specifications.
Wireshark does not know all codec identifiers, so some codecs will need to be decrypted manually by looking at 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 aptXTo avoid analyzing dumps manually, I created a service that analyzes everything automatically:
Codec Comparison. Which codec is better?
Each codec has its own advantages and disadvantages.
aptX and aptX HD use fixed profiles that cannot be changed without modifying the encoder and decoder. Neither the phone manufacturer nor the headphone manufacturer can alter the bitrate or encoding parameters of aptX. The codec owner, Qualcomm, provides a reference encoder in the form of a library. These facts are a strong point for aptX — you already know what quality of sound you will get, without any "buts."
SBC, on the other hand, has many customizable parameters, a dynamic bitrate (the encoder can reduce the bitpool parameter if the radio airwaves are congested), and does not have hard-set profiles, only recommended 'medium quality' and 'high quality' profiles added to the A2DP specification in 2003. 'High quality' is already not considered high by modern standards, and most Bluetooth stacks do not allow using parameters better than those in the 'high quality' profile, although there are no technical limitations to do so.
Bluetooth SIG does not have a reference SBC encoder in the form of a library, and manufacturers implement it on their own.
These are the weaknesses of SBC — it's never clear in advance what sound quality to expect from a specific device. SBC can deliver both low and very high sound quality, but the latter is unattainable without disabling or bypassing the artificial limitations of Bluetooth stacks.
The situation with AAC is ambiguous: on one hand, theoretically the codec should deliver quality indistinguishable from the original, but practice, as per SoundGuys laboratory tests on various Android devices, does not confirm this. Most likely, it is the fault of low-quality hardware audio encoders integrated into various phone chipsets. It makes sense to use AAC only on Apple devices, while on Android, stick to aptX and LDAC.
Equipment that supports alternative codecs is generally of higher quality, simply because it does not make sense for very cheap low-quality devices to pay licensing fees to use these codecs. In my tests, SBC sounds very good on quality equipment.
I created a web service that encodes audio in SBC, aptX, and aptX HD in real-time, directly in the browser. With it, you can test these audio codecs without actually transmitting audio over Bluetooth, using any wired headphones, speakers, and your favorite music, as well as change encoding parameters while audio is being played:
The service uses SBC encoding libraries from the BlueZ project and libopenaptx from ffmpeg, which have been compiled to WebAssembly and JavaScript from C, using emscripten, for execution in the browser. Who could have dreamed of such a future!
Here’s what it looks like:
Note how the noise level changes after 20 kHz with different codecs. In the original MP3 file, frequencies above 20 kHz are absent.
Try switching between codecs and see if you can hear a difference between the original, SBC 53 Joint Stereo (the standard and most common profile), and aptX/aptX HD.
I can hear the difference between codecs in headphones.!
People who cannot hear differences between codecs when testing through the web service claim they can hear it when listening to music on wireless headphones. Unfortunately, this is not a joke or a placebo effect: the difference is indeed audible, but it is not caused by the differences of the codecs..
The overwhelming majority of Bluetooth audio chipsets used in receiving wireless devices are equipped with a digital signal processor (DSP) that implements an equalizer, compander, stereo widener, and other features designed to enhance (or alter) the sound. Manufacturers of Bluetooth equipment can configure the DSP for each codec separately,, and when switching between codecs, the listener will feel that they are hearing differences in codec performance, when in fact they are listening to different DSP settings.
The DSP audio processing pipeline Kalimba in chips produced by CSR/Qualcomm.
Activating various DSP functions for each codec and output separately.
Some premium segment devices come with software that allows users to adjust DSP settings, but most cheaper headphones lack this capability, and users cannot disable sound post-processing via standard means.
Functional features of devices.
The modern version of the A2DP standard has the 'absolute volume control' feature. — control the device volume using special AVRCP protocol commands, which adjusts the output stage amplification instead of reducing the audio stream volume programmatically. If adjusting the volume on the headphones does not sync with the volume on the phone, it means your headphones or phone do not support this feature. 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 — this way, the signal-to-noise ratio will be better, and the audio quality will improve. should be higher.
In reality, there are unfortunate situations. On my RealForce OverDrive D1 headphones, a strong compander is enabled for SBC, and increasing the volume raises the level of quiet sounds, while the volume of loud sounds remains unchanged (signal compression occurs). Because of this, I have to set the computer volume to about half, and in this case, the compression effect is practically non-existent.
From my observations, all headphones with additional codecs support the function of absolute volume control; apparently, this is one of the requirements for codec certification.
Some headphones support connecting two devices simultaneously. This allows, for example, to listen to music from a computer and take calls from a phone. However, it should be noted that in this mode alternative codecs are disabled, and only SBC is used.
The AVDTP 1.3 Delay Reporting function allows headphones to inform the transmitting device of the delay with which the sound is actually played. This helps to adjust the synchronization of audio with video when watching video files: in case of radio transmission issues, the audio will not lag behind the video; rather, the video will be delayed by the video player until the audio and video synchronize again.
The function is supported by many headphones, Android 9+, and Linux with PulseAudio 12.0+. I'm not aware of support for this function on other platforms.
Bidirectional communication via Bluetooth. Voice transmission.
To transmit voice over Bluetooth, Synchronous Connection Oriented (SCO) is used—a synchronous transmission with pre-established connection agreement. This mode allows for sound and voice to be transmitted strictly in order, with symmetrical send and receive rates, without waiting for acknowledgment of transmission or retransmission of packets. This reduces the overall delay of audio transmission over the radio channel, but imposes serious limitations on the amount of data transmitted per unit of time and negatively impacts quality.
When this mode is used, both voice and audio are transmitted with the same quality.
Unfortunately, as of 2019, the quality of voice transmission over Bluetooth is still low, and it's unclear why Bluetooth SIG is not addressing this issue.
CVSD
The basic speech transmission codec CVSD was standardized in 2002 and is supported by all bidirectional communication devices over Bluetooth. It provides audio transmission at a sampling rate of 8 kHz, which corresponds to the quality of standard wired telephony.
.
mSBC
The additional codec mSBC was standardized in 2009, and by 2010, chips utilizing it for voice transmission began to appear. mSBC is widely supported by various devices.
This is not a standalone codec, but rather a standard SBC from the A2DP specification, with a fixed encoding profile: 16 kHz, mono, bitpool 26.
.
Not outstanding, but much better than CVSD; however, it is still unpleasant to use for communication over the internet, especially when using headphones for gaming chat—the game's sound will also be transmitted at a sampling rate of 16 kHz.
FastStream CSR decided to enhance the idea of reusing SBC. To bypass the limitations of the SCO protocol and utilize higher bitrates, CSR took a different approach—they introduced support for bidirectional SBC audio in the one-way audio transfer standard A2DP, standardized encoding profiles, and named it 'FastStream.'
FastStream transmits stereo sound to speakers at 44.1 or 48 kHz with a bitrate of 212 kbps, and for microphone audio is used mono, 16 kHz, with a bitrate of 72 kbps (slightly better than mSBC). These parameters are much better suited for communication in online games—game sounds and conversations will be of high quality.
(+ ).
The company devised an interesting workaround, but because it contradicts the A2DP standard, support exists only in some of the company’s transmitters (which operate as USB sound cards rather than Bluetooth devices), and it has not been supported in Bluetooth stacks, although the number of headphones with FastStream support is not insignificant.
Currently, FastStream support in operating systems is available only by developer Pali Rohár, which is not included in the main branch of the program.
aptX Low Latency
To great surprise, aptX Low Latency also supports bidirectional audio, implementing the same principle as FastStream.
This codec feature cannot be used anywhere — there is no decoding support for Low Latency in any operating system or any Bluetooth stack known to me.
Bluetooth 5, Classic and Low Energy
There has been significant confusion surrounding Bluetooth specifications and versions due to the presence of two incompatible standards under the same 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 widespread and is not used in consumer devices.
Starting with Bluetooth 4.0, changes in the specification primarily focused 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 the 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: (page 291)
Only one change affected the Classic version within the Bluetooth 5 specification: support for the Slot Availability Mask (SAM) technology, intended to improve radio spectrum division, was added. All other changes concern only Bluetooth LE (and Higher Output Power as well).
All audio devices only use Bluetooth Classic. Headphones and speakers cannot connect via Bluetooth Low Energy: there is no audio transmission standard using LE. The A2DP standard, used for transmitting high-quality audio, only works through Bluetooth Classic, and there is no equivalent in LE.
It is pointless to purchase audio devices with Bluetooth 5 solely due to the new version of the protocol. Bluetooth 4.0/4.1/4.2 will work exactly the same in terms of audio transmission.
If the announcement of new headphones mentions a doubled operational range and reduced power consumption thanks to Bluetooth 5, know that they either don’t understand it themselves or are misleading you. It's no surprise, as even Bluetooth chip manufacturers often confuse the differences in the new version of the standard in their announcements, and some Bluetooth 5 chips support the fifth version only for LE, while using 4.2 for Classic.
Audio transmission delay
The magnitude of audio delay (latency) depends on many factors: the size of the buffers in the audio stack, the Bluetooth stack, and in the playback wireless device itself, as well as the algorithmic delay of the codec.
The delay of simple codecs, such as SBC, aptX, and aptX HD, is very small, ranging from 3 to 6 ms, which can be neglected. However, complex codecs, such as AAC and LDAC, can introduce noticeable delay. The algorithmic delay for AAC at 44.1 kHz is around 60 ms. LDAC has about 30 ms (according to a rough analysis of the source code; I might be mistaken, but not by much).
The final delay heavily depends on the playback device, its chipset, and buffer. During testing, I recorded a range from 150 to 250 ms on different devices (using the SBC codec). Assuming that devices supporting additional codecs like aptX, AAC, and LDAC use high-quality components and a small buffer size, we get the following typical delays:
SBC: 150-250 ms
aptX: 130-180 ms
AAC: 190-240 ms
LDAC: 160-210 ms
I remind you: aptX Low Latency is not supported in operating systems, which means that lower latency can only be achieved with a transmitter+receiver or transmitter+headphones/speaker combo, with all devices needing to support this codec.
Device issues, certification, and Bluetooth logos
How to distinguish a quality audio device from a cheap knockoff? Primarily by its appearance!
Cheap Chinese headphones, speakers, and receivers tend to have:
- No "Bluetooth" wording on the packaging or device; more often, "Wireless" or "BT" is used.
- No Bluetooth logo
on the packaging or device - No blinking blue LED
on the packaging or deviceThe absence of these elements indicates that the device has not gone through certification, meaning it is potentially of low quality and problematic. For example, Bluedio headphones are not Bluetooth certified and do not fully comply with the A2DP specification. They would not pass certification.
Let's consider a few devices and their boxes:
All of these are uncertified devices. The instructions may feature a logo and the name of the Bluetooth technology, but the most important thing is that they are on the box and/or the device itself.
If your headphones or speaker say, "Ze bluetooth dewise is connecteda successfulle," this also does not indicate their quality:
Conclusion
Can Bluetooth completely replace wired headphones and headsets? It can, but at the cost of low quality during calls, increased audio transmission delay that can be annoying in games, and a plethora of proprietary codecs that require licensing fees, thus increasing 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 for the "outdated and poor" SBC, which is not as bad as it is often made out to be.
It turns out that the artificial limitations of Bluetooth stacks on the bitrate of SBC can be bypassed, so that SBC is on par with aptX HD. I took the initiative and created a patch for the LineageOS firmware:
More information can be found on the websites and .
Bonus: . This file was previously published on the Bluetooth website publicly, but is now only available for members of Bluetooth SIG.
Source: habr.com
