Due to the mass production of smartphones without a 3.5 mm audio jack, wireless Bluetooth headphones have become the main way for many to listen to music and communicate in headset mode.
Wireless device manufacturers do not always write detailed product specifications, and articles about Bluetooth audio on the Internet are contradictory, sometimes incorrect, do not cover all the features, and often copy the same information that is not true.
Let's try to understand the protocol, the capabilities of Bluetooth OS stacks, headphones and speakers, Bluetooth codecs for music and speech, find out what affects the quality of the transmitted sound and delay, learn how to collect and decode information about supported codecs and other device capabilities.
TL; DR:
- SBC is a normal codec
- Headphones have their own equalizer and post-processing for each codec separately
- aptX is not as good as advertised
- LDAC is marketing bullshit
- Talk audio quality is still poor
- You can embed audio encoders in C into the browser by compiling to WebAssembly via emscripten, and they will not slow down too much.
Music via Bluetooth
The functional component of Bluetooth is set by profiles - specifications of specific functions. Music transmission in Bluetooth is carried out using the A2DP high-quality unidirectional audio transmission profile. The A2DP standard was adopted in 2003 and has not changed dramatically since then.
The profile standardizes 1 mandatory codec of low computational complexity SBC, created specifically for Bluetooth, and 3 additional ones. It is also allowed to use undocumented codecs of your own implementation.
As of June 2019 we are with 14 A2DP codecs:
- SBC ← standardized in A2DP, supported by all devices
- MPEG-1/2 Layer 1/2/3 ← standardized in A2DP: well-known used in digital TV , and unknown
- MPEG-2/4 AAC ← standardized in A2DP
- ATRAC ← old codec from Sony, standardized in A2DP
- LDAC ← new codec from Sony
- aptX ← codec from 1988
- aptX HD ← same as aptX but with different encoding options
- aptX Low Latency ← completely different codec, no software implementation
- aptX Adaptive ← another codec from Qualcomm
- faststream ← pseudo-codec, 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
Why do you need codecs at all, you ask, when Bluetooth has EDR, which allows you to transfer data at speeds of 2 and 3 Mbps, and 16 Mbps is enough for uncompressed two-channel 1.4-bit PCM?
Data transfer via Bluetooth
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 pre-negotiated connection.
Transmission is carried out using a time division scheme and transmission channel selection for each packet separately (Frequency-Hop / Time-Division-Duplex, FH / TDD), for which time is divided into 625 microsecond intervals, called slots (slot). One of the devices transmits in even slot numbers, the other in odd ones. The transmitted packet can occupy 1, 3 or 5 slots, depending on the size of the data and the type of transmission set, in this case, the transmission by one device is carried out in even and odd slots until the end of the transmission. In total, up to 1600 packets can be received and sent per second, if each of them occupies 1 slot, and both devices transmit and receive something without stopping.
2 and 3 Mbit / s for EDR, which can be found in announcements and on the Bluetooth website, are the maximum channel transfer rate of all data in total (including the technical headers of all protocols in which data needs to be encapsulated), in two directions at the same time. The actual data transfer rate will vary greatly.
To transfer music, an asynchronous method is used, almost always using packets like 2-DH5 and 3-DH5, which carry the maximum amount of data in the EDR mode of 2 Mbps and 3 Mbps, respectively, and occupy 5 time division slots of the air.
Schematic representation of transmission using 5 slots by one device and 1 slot by another (DH5/DH1):
Due to the principle of time division of the air, we are forced to wait 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 transmits large packets. If more than one device is connected to the phone (for example, headphones, watch and fitness bracelet), then the transfer time is divided between all of them.
The need to encapsulate audio in special transport protocols L2CAP and AVDTP takes 16 bytes from the possible maximum amount of transmitted audio payload.
Package type
Number of slots
Max. number of bytes in a packet
Max. bytes of A2DP payload
Max. A2DP payload bitrate
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 definitely not enough to transmit uncompressed audio in real conditions, with a noisy 2.4 GHz band and the need to transmit service data. EDR 3 Mbps is demanding on transmission power and noise on the air, therefore, even in 3-DH5 mode, comfortable PCM transmission is impossible, there will always be short-term interruptions, and everything will work only at a distance of a couple of meters.
In practice, even a 990 kbit/s audio stream (LDAC 990 kbit/s) is difficult to transmit.
Let's get back to codecs.
SBC
A codec required for all devices that support the A2DP standard. The best and worst codec at the same time.
Sampling frequency
Digit
Bit rate
Encoding Support
Decode support
16, 32, 44.1, 48 kHz
16 bit
10-1500 kbps
All devices
All devices
SBC is a simple and computationally fast codec, with a primitive psychoacoustic model (only masking of quiet sounds is applied), using adaptive pulse code modulation (APCM).
The A2DP specification recommends two profiles for use: Middle Quality and High Quality.
The codec has many settings that allow you to control the algorithmic delay, the number of samples in a block, the bit distribution algorithm, but the same parameters recommended in the specification are almost universally used: Joint Stereo, 8 frequency bands, 16 blocks in an audio frame, Loudness bit distribution method.
SBC supports dynamic change of the Bitpool parameter, which directly affects the bitrate. If the radio is clogged, packets are lost, or the devices are far away, the audio source may decrease the Bitpool until the link returns to normal.
Most headphone manufacturers set the maximum Bitpool value to 53, which limits the bitrate to 328 kbps when using the recommended profile.
Even if the headphone manufacturer has set the maximum Bitpool value above 53 (such models are found, for example: Beats Solo³, JBL Everest Elite 750NC, Apple AirPods, also happens on some receivers and car head units), then most operating systems will not allow you to use increased bitrates due to set internal value limit in Bluetooth stacks.
In addition, some manufacturers set a low maximum Bitpool value for some devices. For example, for Bluedio T it is 39, for Samsung Gear IconX it is 37, which gives poor sound quality.
Artificial restrictions on the part of Bluetooth stack developers most likely arose due to the incompatibility of some devices with large Bitpool values or atypical profiles, even if they reported support for them, and insufficient certification tests. It was easier for the authors of the Bluetooth stacks to confine themselves to agreeing on the recommended profile, and not to create bases of incorrect devices (although they now do this for other incorrectly working functions).
The SBC dynamically allocates quantization bits to the frequency bands in a bottom-to-top fashion with different weights. If the entire bitrate was used for the lower and middle frequencies, the upper frequencies will be "cut off" (there will be silence instead).
Example SBC 328 kbps. Above - the original, below - SBC, periodically switching between tracks. The audio in the video file uses the FLAC lossless compression codec. The use of FLAC in an mp4 container is not officially standardized, so it's not guaranteed that your browser will play it, but it should work in the latest desktop versions of Chrome and Firefox. If you do not have sound, you can download the file and open it in a full-fledged video 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 bits for the band above 20 kHz at all. The full spectrogram is available by click (1.7 MB).
I can't hear any difference between original and SBC on this track.
Let's take something newer and simulate the audio that would be obtained using Samsung Gear IconX headphones with Bitpool 37 (top - original signal, bottom - SBC 239 kbps, audio in FLAC).
Mindless Self Indulgence - Witness
I hear crackling, less stereo effect, and an unpleasant "clatter" of vocals in the high frequencies.
Although SBC is a very flexible codec, it can be tuned for low latency, gives excellent audio quality at high bitrates (452+ kbps) and is quite good for most people at standard High Quality (328 kbps), due to the fact that that the A2DP standard does not set fixed profiles (but only gives recommendations), stack developers have set artificial restrictions on Bitpool, transmitted audio parameters are not displayed in the user interface, and headphone manufacturers are free to set their own settings and never indicate the Bitpool value in product specifications, codec became famous for its poor sound quality, although this is not a problem with the codec as such.
The Bitpool parameter directly affects the bitrate only within one profile. The same value of Bitpool 53 can give both a bitrate of 328 kbps with the recommended High Quality profile, and 1212 kbps with Dual Channel and 4 frequency bands, which is why the authors of the OS, in addition to the restrictions on Bitpool, set a limit and on Bitrate. As I see it, this situation arose due to a flaw in the A2DP standard: it was necessary to negotiate the bitrate, not Bitpool.
Table of support for SBC features in different OS:
OS
Supported sample rates
Max. Bitpool
Max. bitrate
Typical Bitrate
Bitpool Dynamic 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
✗
* Bitpool only decreases, but does not increase automatically, in case of improved transfer 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 during compilation, in other versions, 44.1 kHz and 48 kHz are supported simultaneously.
*** The Bitpool value can be raised in the Bluetooth Explorer program.
aptX and aptX HD
aptX is a simple and computationally fast codec, without psychoacoustics, using adaptive differential PCM (). Appeared around 1988 (date of filing dated February 1988), before Bluetooth was used primarily in professional wireless audio equipment. Currently owned by Qualcomm, requires licensing and royalties. As of 2014: $6000 lump sum and ≈$1 per device, for batches up to 10000 devices (, p. 16).
aptX and aptX HD are the same codec, with different encoding profiles.
The codec has only one parameter - the choice of sampling rate. There is, however, a choice of the number / mode of channels, but in all devices I know (70+ pieces) only Stereo is supported.
Codec
Sampling frequency
Digit
Bit rate
Encoding Support
Decode support
aptX
16, 32, 44.1, 48 kHz
16 bit
128 / 256 / 352 / 384 kbps (depending on sample rate)
Windows 10 (desktop and mobile), macOS, Android 4.4+/7*, Blackberry OS 10
Wide range of audio devices (hardware)
* Versions prior to 7 require Bluetooth stack modification. The codec is only supported if the Android device manufacturer has licensed the codec from Qualcomm (if the OS has encoding libraries).
aptX splits audio into 4 frequency bands and quantizes them with the same number of bits all the time: 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 ( figures for 44.1 kHz sample rate).
An example of aptX audio (top - original signal, bottom - aptX, spectrograms of only left channels, sound in FLAC):
The upper frequencies have become a little redder, but the difference is not audible.
Due to the fixed distribution of quantization bits, the codec cannot "transfer the bits" to those frequencies that need them most. Unlike SBC, aptX will not "cut" frequencies, but will add quantization noise to them, reducing the dynamic range of the audio.
It should not be assumed 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 when using 2 bits of quantization, but only with a certain signal.
ADPCM stores the difference in numeric representation between the current and next reading, instead of writing an absolute value as in PCM. This reduces the requirements for the number of bits required to store the same (lossless) or almost the same (with relatively small rounding error) information. Factor tables are used to reduce rounding errors.
When creating the codec, the authors calculated the ADPCM coefficients on a set of music audio files. The closer the audio signal is to the set of music on which the tables were built, the less quantization errors (noise) aptX creates.
Because of this, synthetic tests will always give worse results than music. I made a special synthetic example on which aptX shows poor results - a 12.4 kHz sine wave (top - original signal, bottom - aptX. Sound in FLAC. Turn down the volume!):
Spectrum Plot:
Noises are clearly audible.
However, if we generate a sine wave with a smaller amplitude so that it is quieter, the noises also become quieter, which indicates a wide dynamic range:
To hear the difference between the original music track and the compressed one, you can invert one of the signals and add the tracks channel by channel. This approach, in general, is incorrect, and would not give a sane result with more complex codecs, but it is quite suitable for ADPCM specifically.
The RMS 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. The changes affected 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).
Codec
Sampling frequency
Digit
Bit rate
Encoding Support
Decode support
aptX HD
16, 32, 44.1, 48 kHz
24 bits
192 / 384 / 529 / 576 kbps (depending on sample rate)
Android 8+*
Some audio devices (hardware)
* Versions prior to 7 require Bluetooth stack modification. The codec is only supported if the Android device manufacturer has licensed the codec from Qualcomm (if the OS has encoding libraries).
Less common than aptX: apparently requires separate licensing from Qualcomm, and separate license fees.
Let's repeat the example with a sine wave at 12.4 kHz:
Much better than with aptX, but still noisy.
aptX Low Latency
Codec from Qualcomm, which has nothing in common with standard aptX and aptX HD, judging by the few information from the people involved in its development. Designed for interactive transmission of audio with low latency (movies, games), where the audio delay cannot be adjusted by software. There are no known software implementations of encoders and decoders, it is supported exclusively by transmitters, receivers, headphones and speakers, but not by smartphones and computers.
Sampling frequency
Bit rate
Encoding Support
Decode support
44.1 kHz
276/420 kbps
Some transmitters (hardware)
Some audio devices (hardware)
AAC
AAC, or Advanced Audio Coding, is a computationally complex codec with a serious psychoacoustic model. It has become widespread for audio on the Internet, the second most popular after MP3. Requires licensing and royalties: $15000 lump sum (or $1000 for companies with fewer than 15 employees) + $0.98 for the first 500000 devices ().
The codec is standardized within the MPEG-2 and MPEG-4 specifications, and contrary to common misconception, does not belong to Apple.
Sampling frequency
Bit rate
Encoding Support
Decode support
8 - 96 kHz
8 - 576 kbps (for stereo), 256 - 320 kbps (typical for Bluetooth)
macOS, Android 7+*, iOS
Wide range of audio devices (hardware)
* only on devices whose manufacturers have paid royalties
iOS and macOS use Apple's best AAC encoder to date, delivering the highest possible audio quality. Android uses the second best quality Fraunhofer FDK AAC encoder, but may use various hardware built into the platform (SoC) with unknown encoding quality. , the quality of AAC encoding by different Android phones is very different:
Most wireless audio devices for AAC have a maximum bit rate of 320 kbps, some only support 256 kbps. Other bitrates are extremely rare.
AAC provides excellent quality at 320 and 256 kbps, but is susceptible to , however, it is difficult to hear any differences from the original on iOS at 256 kbps even with several consecutive encodings, with a single encoding, for example, MP3 320 kbps to AAC 256 kbps, losses can be neglected.
As is the case with other Bluetooth codecs, any music is first decoded, then encoded by the codec. When listening to music in AAC format, it is first decoded by means of the OS, then encoded into AAC again, for transmission via Bluetooth. This is necessary for mixing multiple audio streams such as music and new message notification. iOS is no exception. There are many claims on the Internet that on iOS, AAC music is not transcoded when transferred via Bluetooth, which is not true.
MP1/2/3
The MPEG-1/2 Part 3 family of codecs consists of the well-known and widely used MP3, the less common MP2 (used mainly in digital TV and radio), and the completely unknown MP1.
The older MP1 and MP2 codecs are not supported at all: I couldn't find any headphones or any Bluetooth stack that encodes or decodes them.
MP3 decoding is supported by some headphones, but encoding is not supported on any stack of modern operating systems. It seems that the third-party BlueSoleil stack for Windows can encode to MP3 if you manually change the configuration file, but installing it leads to BSoD on Windows 10 for me. The conclusion is that the codec cannot actually be used for Bluetooth audio.
Previously, in 2006-2008, before the A2DP standard was widespread 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 smartphone OS architecture allowed access to many low-level functions, and third-party Bluetooth stacks could be installed on Windows Mobile at all.
The latest patent of the MP3 codec has expired, the use of the codec is royalty-free as of 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 US Patent 6,009,399, held by and administered by Technicolor, expired.
Source:
Sampling frequency
Bit rate
Encoding Support
Decode support
16 - 48 kHz
8 - 320 kbps
Not supported anywhere
Some audio devices (hardware)
LDAC
A new and actively promoted "Hi-Res" codec from Sony that supports sample rates up to 96 kHz and 24 bits, with bit rates up to 990 kbps. Advertised as an audiophile codec, as a replacement for existing Bluetooth codecs. It has the function of adaptive adjustment of the bitrate, depending on the radio conditions.
Encoder LDAC () is included in the standard delivery of Android, so encoding is supported on any Android smartphone starting from OS version 8. There are no freely available software decoders, the codec specification is not available to the general public, however, at first glance at the encoder, the internal structure of the codec is similar to - a codec from Sony used in the PlayStation 4 and Vita: both operate in the frequency range, use a modified discrete cosine transform (MDCT) and compression using the Huffman algorithm.
LDAC support is represented almost exclusively by Sony headphones. The ability to decode LDAC is sometimes found on headphones and DACs from other manufacturers, but very rarely.
Sampling frequency
Bit rate
Encoding Support
Decode 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 +
Some Sony headphones and single devices from other manufacturers (hardware)
Marketing LDAC as a Hi-Res codec harms its technical component: it is foolish to spend bitrate on transmitting frequencies that are not audible to the human ear and increased bit depth, as long as it is not enough to transmit lossless CD quality (44.1/16). 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 software LDAC decoder is not freely available, it is impossible to test the codec without additional devices that decode LDAC. According to the results of the LDAC test on a DAC with its support, which the engineers of the site SoundGuys.com connected via a digital output and recorded the output sound on test signals, LDAC 660 and 990 kbps in CD-quality mode provides a signal-to-noise ratio slightly better than that of aptX HD.
Source:
LDAC also supports dynamic bitrate outside of established profiles - from 138 kbps to 990 kbps, but as far as I can tell, Android only uses standardized 303/606/909 and 330/660/990 kbps profiles.
Other codecs
Other A2DP codecs are not widely used. Their support is either almost completely absent, or available only on certain models of headphones and smartphones.
The ATRAC codec standardized in A2DP has never been used as a Bluetooth codec even by Sony themselves, the 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 is supported by only three(?) devices.
Support for codecs by audio devices
Not all manufacturers publish accurate information about the codecs that certain wireless headphones, speakers, receivers or transmitters support. Sometimes it happens that support for a certain codec is only for transmission, but not for reception (relevant for combined transmitter-receivers), although the manufacturer simply declares “support”, without notes (I assume that separate licensing of encoders and decoders of some codecs is to blame for this ). In the cheapest devices, you may not find the declared support for aptX at all.
Unfortunately, in the interfaces of most operating systems, the codec used is not displayed anywhere. Information about this is available only in Android, starting from 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? Capture and analyze a traffic dump with A2DP negotiation options!
You can do this on Linux, macOS and Android. On Linux, you can use Wireshark or hcidump, on macOS you can use Bluetooth Explorer, and on Android you can use the native Bluetooth HCI dump saving function, which is available in the developer tools. You will get a btsnoop dump that can be loaded into the Wireshark analyzer.
Note: the correct dump can only be obtained by connecting from the phone / computer to the headphones / speaker (no matter how curious it may sound)! Headphones can independently establish a connection with the phone, in which case they will request a list of codecs from the phone, and not vice versa. To ensure that a correct dump is written, first unpair the device and then pair the phone with the headphones while the dump is being written.
Use the following display filter to weed out irrelevant traffic:
btavdtp.signal_idAs a result, you should see something similar to:
You can click on each item of the GetCapabilities command and see the detailed characteristics of the codec.
Wireshark does not know all codec identifiers, so some codecs will have to be decrypted manually, looking at the identifier table 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 aptXIn order not to analyze the dumps manually, I made a service that will analyze everything automatically:
Comparison of codecs. Which codec is better?
Each codec has its own advantages and disadvantages.
aptX and aptX HD use hard-coded profiles that cannot be changed without modifying the encoder and decoder. Neither the phone manufacturer nor the headphone manufacturer has the power to change the bitrate or aptX encoding factors. The owner of the codec, Qualcomm, provides a reference encoder as a library. These facts are the strength of aptX - you know in advance what sound quality you will get, without any "buts".
SBC, on the contrary, has a lot of configurable parameters, dynamic bitrate (the encoder can reduce the bitpool parameter if the radio is loaded), and does not have hard-coded profiles, but only the recommended "medium quality" and "high quality" that were added to the A2DP specification in 2003 year. "High Quality" is no longer as high quality by modern standards, and most Bluetooth stacks do not allow you to use settings better than the "High Quality" profile, although there are no technical restrictions for this.
The Bluetooth SIG does not have a reference SBC encoder in the form of a library, and manufacturers implement it themselves.
These are the weaknesses of the SBC - it is never clear in advance what sound quality to expect from a particular device. The SBC can produce 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 the one hand, theoretically, the codec should produce quality that is indistinguishable from the original, but in practice, judging by the tests of the SoundGuys laboratory on various Android devices, this is not confirmed. Most likely, the fault lies with low-quality hardware audio encoders built into various phone chipsets. It makes sense to use AAC only on Apple devices, and limit yourself to aptX and LDAC on Android.
Hardware that supports alternative codecs is generally higher quality, simply because it doesn't make sense for very cheap, low quality devices to pay royalties to use these codecs. In my tests, the SBC sounds very good on quality hardware.
I made a web service that encodes audio in SBC, aptX and aptX HD in real time, right in the browser. With it, you can test these audio codecs without actually transmitting audio via Bluetooth, on any wired headphones, speakers, and your favorite music, as well as change encoding parameters right during audio playback:
The service uses the SBC coding libraries from the BlueZ project and libopenaptx from ffmpeg, which are compiled to WebAssembly and JavaScript from C, via emscripten, to run in the browser. Who could dream of such a future!
Here's how it looks:
Notice how the noise level changes after 20 kHz for different codecs. There are no frequencies above 3 kHz in the original MP20 file.
Try switching codecs and see if you can hear the difference between the original, SBC 53 Joint Stereo (the default and most common profile), and aptX/aptX HD.
I hear the difference between codecs in headphones!
People who do not hear the difference between codecs during testing through a web service claim that they hear it when listening to music in wireless headphones. Alas, this is not a joke or a placebo effect: the difference is really audible, but it is not caused by differences. codecs.
The vast majority of Bluetooth audio chipsets used in wireless receiving devices are equipped with a Digital Signal Processor (DSP) that implements an equalizer, compander, stereo expander, and other things designed to improve (or change) the sound. Bluetooth manufacturers can customize the DSP for each codec separately, and when switching between codecs, it will seem to the listener that he hears the difference in how the codecs work, when in reality he is listening to different DSP settings.
Kalimba DSP audio processing pipeline in CSR/Qualcomm chips
Activating various DSP functions for each codec and output separately
Some premium devices come with a program that allows you to adjust DSP settings, but most cheaper headphones do not have this option, and users cannot turn off sound post-processing using the pants.
Functional features of devices
The current version of the A2DP standard has "absolute volume control" function — device volume control by special commands of the AVRCP protocol, which regulates the gain of the output stage, instead of programmatically reducing the volume of the audio stream. If when you change the volume on the headphones, the change does not sync with the volume on the phone, then this means that your headphones or phone do not support this function. In this case, it makes sense to listen to music always at maximum volume on the phone, adjusting the actual volume with the headphone buttons - in this case, the signal-to-noise ratio will be better and the audio quality should be above.
In reality, there are sad situations. I have a strong compander on my RealForce OverDrive D1 headphones for SBC, and increasing the volume leads to an increase in the level of quiet sounds, while the volume of loud sounds does not change (the signal is compressed). Because of this, you have 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 the absolute volume control function, apparently this is one of the requirements for codec certification.
Some headphones support connect two devices at the same time. This allows you, for example, to listen to music from your computer and receive calls from your phone. However, you should be aware that in this mode, alternative codecs are disabled, and only SBC is used.
AVDTP 1.3 Delay Reporting Feature allows the headphones to communicate the delay to the transmitting device at which sound is actually played. This allows you to adjust the synchronization of audio with video while watching video files: if there are problems with transmission over the air, 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 am not aware of the feature's support on other platforms.
Bi-directional communication via Bluetooth. Voice transmission.
For voice transmission in Bluetooth, Synchronous Connection Oriented (SCO) is used - synchronous transmission with preliminary connection negotiation. The mode allows you to transmit sound and voice strictly in order, with a symmetrical sending and receiving speed, without waiting for transmission confirmation and resending packets. This reduces the overall audio transmission delay over the radio channel, but imposes serious restrictions on the amount of data transmitted per unit of time, and negatively affects the quality.
When this mode is used, both voice and audio are transmitted with the same quality.
Unfortunately, as of 2019, Bluetooth voice quality is still poor, and it's unclear why the Bluetooth SIG does nothing about it.
CVSD
The basic CVSD speech codec was standardized in 2002 and is supported by all Bluetooth bidirectional devices. It provides audio transmission with a sampling rate of 8 kHz, which corresponds to the quality of conventional wired telephony.
.
mSBC
An additional mSBC codec was standardized in 2009, and in 2010 there were already chips using it for voice transmission. mSBC is widely supported by various devices.
This is not an independent codec, but a regular SBC from the A2DP standard, with a fixed encoding profile: 16 kHz, mono, bitpool 26.
.
Not brilliant, but much better than CVSD, but it's still annoying to use it to chat over the Internet, especially when you use headphones to chat in a game - game audio will also be transmitted at a sample rate of 16 kHz.
FastStreamCSR decided to develop the idea of reusing SBC. To get around the limitations of the SCO protocol and use higher bitrates, CSR went the other way - they introduced support for two-way SBC audio into the A2DP one-way audio transmission standard, standardized encoding profiles, and called it "FastStream".
FastStream transmits 44.1 or 48 kHz stereo sound at 212 kbps to the speakers, and mono, 16 kHz, at 72 kbps is used to transmit audio from the microphone (slightly better than mSBC). Such parameters are much better suited for communication in online games - the sound of the game and interlocutors will be of high quality.
(+ ).
The company came up with an interesting crutch, but due to the fact that it contradicts the A2DP standard, only some of the company's transmitters (which work as a USB audio card, not a Bluetooth device) support it, but it did not receive support in Bluetooth stacks, although the number of FastStream-enabled headphones is not that small.
At the moment, FastStream support in the OS is only from the developer Pali Rohár, who is not included in the main branch of the program.
aptX Low Latency
Surprisingly, aptX Low Latency also supports bi-directional audio, implementing the same principle as FastStream.
You won't be able to use this feature of the codec anywhere - there is no support for Low Latency decoding in any OS and in any Bluetooth stack I know.
Bluetooth 5, Classic and Low Energy
Much confusion has arisen around 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, aka Bluetooth Smart). There is also a third protocol, Bluetooth High Speed, but it is not common and is not used in consumer devices.
Starting with Bluetooth 4.0, the specification changes were predominantly Bluetooth Low Energy, with the Classic version receiving 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: (291 page)
Only one change has affected the Classic version within the Bluetooth 5 specification: they added support for Slot Availability Mask (SAM) technology, designed to improve radio separation. All other changes affect only Bluetooth LE (and Higher Output Power too).
All audio devices only use Bluetooth Classic. Headphones and speakers cannot be connected via Bluetooth Low Energy: there is no standard for audio transmission using LE. The A2DP standard, which is used to transmit high-quality audio, works only through Bluetooth Classic, and there is no analogue in LE.
Conclusion - it makes no sense to purchase audio devices with Bluetooth 5 just because of the new version of the protocol. Bluetooth 4.0/4.1/4.2 will work in the same way in the context of audio transmission.
If the announcement of new headphones mentions doubled range and reduced power consumption thanks to Bluetooth 5, then you should know that they either do not understand themselves or mislead you. No wonder, because even manufacturers of Bluetooth chips get confused in their announcements about the differences between the new version of the standard, and some Bluetooth 5 chips support the fifth version only for LE, while for Classic they use 4.2.
Audio transmission delay
The amount of delay (lag) of audio depends on many factors: the size of the buffer in the audio stack, in the Bluetooth stack and in the reproducing wireless device itself, the algorithmic delay of the codec.
Simple codecs like SBC, aptX and aptX HD have very low latency of 3-6ms, which is negligible, but complex codecs like AAC and LDAC can experience noticeable latency. The AAC algorithmic delay for 44.1 kHz is 60 ms. LDAC - about 30 ms (according to a rough analysis of the source code. I could be wrong, but not much.)
The resulting 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 SBC codec). Assuming that devices supporting additional aptX, AAC, and LDAC codecs use high-quality components and a small buffer size, we get the following typical delays:
SBC: 150-250ms
aptX: 130-180ms
AAC: 190-240ms
LDAC: 160-210ms
I remind you: aptX Low Latency is not supported in operating systems, which is why a lower delay can only be obtained by a combination of transmitter + receiver or transmitter + headphones / speaker, and all devices must support this codec.
Bluetooth device, certification, and logo issues
How to distinguish a high-quality audio device from a cheap craft? In appearance, first of all!
For cheap Chinese headphones, speakers and receivers:
- Missing the word "Bluetooth" on the box and device, most commonly used "Wireless" and "BT"
- Bluetooth logo missing on the box or device
- No blue blinking LED
The absence of these elements indicates that the device has not been certified, which means that it is potentially low-quality and problematic. For example, Bluedio headphones are not Bluetooth certified and do not fully comply with the A2DP specification. They would not be certified.
Consider several devices and boxes from them:
These are all uncertified devices. The instructions may contain a logo and the name of Bluetooth technology, but the most important thing is that they be on the box and / or the device itself.
If your headphones or speaker say “Ze bluetooth dewise is connecteda successfulle”, this does not mean their quality either:
Conclusion
Can Bluetooth completely replace wired headphones and headsets? Capable, but at the cost of poor call quality, increased audio latency that can be annoying in games, and a plethora of proprietary codecs that require royalties 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 for the "outdated and bad" SBC, which is not nearly as bad as people think it is.
As it turned out, the artificial limitations of Bluetooth stacks on the SBC bitrate can be bypassed, so that the SBC will not be inferior to aptX HD. I took the initiative in my own hands and made a patch for the LineageOS firmware:
More information can be found on the websites и .
Bonus: . This file was previously posted publicly on the Bluetooth website, but is now only available to members of the Bluetooth SIG.
Source: habr.com