Audio via Bluetooth: maximize details on profiles, codecs and devices

    XKCD comic about 14 competing standards: Caption: SITUATION: there are 14 competing standards.  Geek: 14 ?!  Absurd!  We need to develop one universal standard for all occasions.  Geek's companion: Yes!  Caption: Coming soon: SITUATION: There are 15 competing standards.

    This article is also available in English

    Due to the mass production of smartphones without an 3.5 mm audio jack, wireless Bluetooth headsets have become the main way for many to listen to music and communicate in headset mode.
    Manufacturers of wireless devices do not always write detailed product specifications, and articles on Bluetooth audio on the Internet are contradictory, sometimes incorrect, do not talk about all the features, and often copy the same information that does not correspond to reality.
    Let's try to figure out the protocol, the capabilities of the Bluetooth OS stacks, headphones and speakers, Bluetooth codecs for music and speech, find out what affects the quality of transmitted sound and delay, learn how to collect and decode information about supported codecs and other device capabilities.

    TL; DR:
    • SBC - Normal Codec
    • The headphones have their own equalizer and post-processing for each codec separately
    • aptX is not as good as advertisements talk about it
    • LDAC - marketing bullshit
    • Talk quality is still poor
    • You can embed audio encoders in C into the browser by compiling them into WebAssembly via emscripten, and they will not slow down much.





    Bluetooth music

    The functional component of Bluetooth is defined by profiles - specifications of specific functions. Bluetooth music is transmitted using the A2DP high-quality unidirectional audio transmission profile. The A2DP standard was adopted in 2003, and has not changed dramatically since then.
    Within the framework of the profile, 1 obligatory codec of low computational complexity SBC, created specifically for Bluetooth, and 3 additional ones are standardized. The use of undocumented codecs of our own implementation is also allowed.

    As of June 2019, we are in the xkcd comic 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 MP3 used in digital TV MP2 , and the unknown MP1
    • MPEG-2/4 AAC ← standardized in A2DP
    • ATRAC ← old Sony codec standardized in A2DP
    • LDAC ← Sony's new codec
    • aptX ← codec from 1988
    • aptX HD ← Same as aptX, but with different encoding options
    • aptX Low Latency ← a completely different codec, no aptX software implementation with a reduced buffer
    • aptX Adaptive ← another Qualcomm codec
    • FastStream ← pseudo codec , bidirectional SBC modification
    • HWA LHDC ← Huawei's new codec
    • Samsung HD ← 2 devices supported
    • Samsung Scalable ← 2 devices supported
    • Samsung UHQ-BT ← 3 devices supported


    Why codecs are needed at all, you ask, when is EDR available in Bluetooth , which allows you to transfer data at speeds of 2 and 3 Mbps, and 1.4 Mbps is enough for an uncompressed two-channel 16-bit PCM?


    Bluetooth data transfer

    There are two types of data transfer in Bluetooth: Asynchronous Connection Less (ACL) for asynchronous transmission without establishing a connection, and Synchronous Connection Oriented (SCO) for synchronous transmission with preliminary negotiation of the connection.
    Transmission is carried out using a time-sharing scheme and a choice of a transmission channel for each packet separately (Frequency-Hop / Time-Division-Duplex, FH / TDD), for which time is divided into 625-microsecond intervals, called slots. One of the devices transmits in even slot numbers, the other in odd numbers. The transmitted packet can occupy 1, 3, or 5 slots, depending on the size of the data and the type of transmission set, in which case one device transfers in even and odd slots until the end of the transfer. 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 Mbps for EDR, which can be found in announcements and on the Bluetooth website, are the maximum channel data transfer rate for all data in total (including the technical headers of all protocols in which data should be encapsulated), in two directions at the same time. Actual data transfer rates will vary greatly.

    To transfer music, an asynchronous method is used, almost always with the help of 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 slots of the air time division.

    Schematic representation of a transmission using 5 slots by one device and 1 slot by another (DH5 / DH1):
    5 transmission slots, each of which is transmitted 625 microseconds, and one slot for reception, also 625 microseconds.  In total - 3.75 milliseconds.

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

    The need to encapsulate audio in the special transport protocols L2CAP and AVDTP takes 16 bytes from the maximum possible amount of transmitted payload audio.
    Package typeNumber of slotsMax. bytes per packetMax. bytes of payload A2DPMax. A2DP payload bitrate
    2-dh33367351936 kbps
    3-dh335525361429 kbps
    2-DH556796631414 kbps
    3-dh55102110052143 kbps
    1414 and 1429 kbit / s are definitely not enough for transmitting uncompressed sound in real conditions, with a noisy 2.4 GHz band and the need to transfer service data. 3 Mbps EDR is demanding on transmission power and air noise, therefore, even in 3-DH5 mode, comfortable PCM transmission is impossible, there will be short-term interruptions constantly, and everything will work only at a distance of a couple of meters.
    In practice, even 990 kbit / s audio stream (LDAC 990 kbit / s) is difficult to transmit.

    Back to the codecs.

    Sbc

    Codec required for all devices that support the A2DP standard. The best and worst codec at the same time.

    Sampling frequencyCapacityBit rateCoding supportDecoding support
    16, 32, 44.1, 48 kHz16 bit10-1500 kbpsAll devicesAll devices


    SBC is a simple and computationally fast codec, with a primitive psychoacoustic model (only quiet sounds are masked), using adaptive pulse-code modulation (APCM).
    The A2DP specification recommends two profiles for use: Middle Quality and High Quality.
    Mode table Middle Quality and High Quality.  The specified values ​​are bitpool, frame length and bitrate.  For 44.1 kHz Joint Stereo.  Middle Quality: bitpool = 35, frame length = 83, bitrate = 229. High Quality: bitpool = 53, frame length = 119, bitrate = 328.

    The codec has many settings that allow you to control the algorithmic delay, the number of samples in a block, the bit allocation algorithm, but almost everywhere the same parameters recommended in the specification are used: Joint Stereo , 8 frequency bands, 16 blocks in an audio frame, Loudness bit allocation method .
    SBC supports the dynamic change of the Bitpool parameter, which directly affects the bit rate. If the radio is clogged, packets are lost, or devices are far away, the audio source can reduce Bitpool until the connection normalizes.

    Manufacturers of most headphones set the maximum value of the Bitpool parameter to 53, which limits the bit rate to 328 kilobits per second when using the recommended profile.
    Even if the headphone manufacturer 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 using increased bitrates due to set internal limit value 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 - 37, which gives poor sound quality.

    Artificial restrictions on the part of developers of Bluetooth stacks most likely arose due to the incompatibility of some devices with large Bitpool values ​​or atypical profiles, even if they reported their support, and an insufficient number of tests during certification. It was easier for authors of Bluetooth stacks to restrict themselves to agreeing on a recommended profile, rather than creating databases of incorrect devices (although now they do this for other incorrectly working functions).

    SBC dynamically allocates quantization bits for frequency bands, operating on a low-to-high basis with different weights. If the entire bitrate was used for the low and middle frequencies, the higher frequencies will be “cut off” (there will be silence instead).

    SBC example 328 kbps. Above is the original, below is the SBC, periodically switching between tracks. For audio, the video file uses the lossless FLAC compression codec. Using FLAC in the mp4 container is not officially standardized, so it’s not a fact that your browser will play it, but it should work in the latest versions of desktop Chrome and Firefox. If you don’t have sound, you can download the file and open it in a full-fledged video player.
    ZZ Top - Sharp Dressed Man

    The switching moment is visible on the spectrogram: SBC periodically cuts quiet sounds above 17.5 kHz, and does not emit bits at all for the band above 20 kHz. The full spectrogram is available by click (1.7 MB). I do not hear the difference between the original and SBC on this track. Let's take something newer and simulate the audio that would have turned out using the Samsung Gear IconX headphones with Bitpool 37 (at the top is the original signal, at the bottom is SBC 239 kbit / s, the sound is in FLAC).
    image




    Mindless Self Indulgence - Witness

    I hear a pop, a smaller stereo effect and an unpleasant “clatter” of vocals at high frequencies.

    Although SBC is a very flexible codec, it can be configured for low latencies, it provides excellent audio quality at high bitrates (452+ kbps) and is quite good for most people on the standard High Quality (328 kbps), because that the A2DP standard does not specify fixed profiles (but gives only recommendations), the developers of the stacks set artificial restrictions on Bitpool, the parameters of the transmitted audio are not displayed in the user interface, and the headphone manufacturers are free to set their own settings and never indicate the value of Bitpool technically Due to its product characteristics, the codec is famous for its low sound quality, although this is not a problem for the codec as such.
    The Bitpool parameter directly affects the bitrate within a single profile. The same Bitpool 53 value can give either a 328 kbit / s bit rate with the recommended High Quality profile, or 1212 kbit / s with Dual Channel and 4 frequency bands, which is why OS authors, in addition to 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 coordinate the bitrate, not Bitpool.

    Support table for SBC features in different OSs:
    OSSupported sample ratesLimit max. BitpoolLimit max. BitrateTypical bitrateBitpool Dynamic Tuning
    Windows 1044.1 kHz53512 kbps328 kbps✓ *
    Linux (BlueZ + PulseAudio)16, 32, 44.1, 48 kHz64 (for incoming), 53 (for outgoing)No limit328 kbps✓ *
    macOS High Sierra44.1 kHz64, default 53 ***Unknown328 kbps
    Android 4.4-944.1 / 48 kHz **53328 kbps328 kbps
    Android 4.1-4.3.144.1, 48 kHz **53229 kbps229 kbps
    Blackberry OS 1048 kHz53No limit328 kbps
    * Bitpool only decreases, but does not increase automatically, in case of improvement of 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 during compilation, in other versions 44.1 kHz and 48 kHz are supported at the same time.
    *** Bitpool value can be raised in Bluetooth Explorer.


    aptX and aptX HD

    aptX is a simple and computationally fast codec, without psychoacoustics, using adaptive differential pulse-code modulation ( ADPCM ). It appeared around 1988 (the patent filing date is dated February 1988), before Bluetooth it was mainly used in professional wireless audio equipment, ISDN , movie theaters. Currently owned by Qualcomm, requires licensing and royalties. As of 2014: $ 6,000 at a time and ≈ $ 1 for each device, for batches of up to 10,000 devices ( source , 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, however, a choice of the number / mode of channels, but in all devices known to me (70+ pieces) only Stereo is supported.

    CodecSampling frequencyCapacityBit rateCoding supportDecoding support
    aptX16, 32, 44.1, 48 kHz16 bit128/256/352/384 kbps (depending on sample rate)Windows 10 (desktop and mobile), macOS, Android 4.4 + / 7 *, Blackberry OS 10A wide range of audio devices (hardware)
    * Versions prior to 7 require modification of the Bluetooth stack. The codec is supported only if the manufacturer of the Android device licensed Qualcomm to use the codec (if the OS has encoding libraries).

    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 ( digits for a sampling frequency of 44.1 kHz).

    Example aptX-audio (at the top is the source signal, at the bottom is aptX, spectrograms of only the left channels, sound in FLAC):

    The upper frequencies have become a little redder, but no difference is heard.

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

    It should not be considered that using, for example, 2 bits for a band reduces the dynamic range to 12 dB: ADPCM allows you to use up to 96 dB of dynamic range even when using 2 quantization bits, but only with a specific signal.
    ADPCM stores the difference in the numeric representation between the current and the next sample, instead of writing the absolute value, as in PCM. This allows you to reduce the requirements for the number of bits required to store the same (without loss) or almost the same (with a relatively small rounding error) information. To reduce rounding errors, coefficient tables are used.
    When creating the codec, the authors calculated ADPCM coefficients on a set of music audio files. The closer the audio signal 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 produce worse results than music. I made a special synthetic example where aptX shows poor results - a 12.4 kHz sine wave (above is the original signal, below is aptX. Sound in FLAC. Turn down the volume!):

    Spectrum graph:
    Spectrum graph, maximum noise level - -55 dB

    Noises are clearly audible.

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

    Spectrum graph, maximum noise level - -75 dB

    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 specifically for ADPCM it is quite suitable.
    The difference between the original and aptX The
    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 improved aptX codec encoding profile. The changes affected the number of bits allocated for encoding the 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 (digits for 44.1 kHz).

    CodecSampling frequencyCapacityBit rateCoding supportDecoding support
    aptX HD16, 32, 44.1, 48 kHz24 bits192/384/529/576 kbps (depending on sample rate)Android 8 + *Some audio devices (hardware)
    * Versions prior to 7 require modification of the Bluetooth stack. The codec is supported only if the manufacturer of the Android device licensed Qualcomm to use the codec (if the OS has encoding libraries).

    Less common than aptX: it seems to require separate licensing from Qualcomm, and separate license fees.

    Let's repeat the example with the 12.4 kHz sine wave:
    Spectrum graph, maximum noise level - -72 dB

    Much better than with aptX, but still noisy.


    aptX Low Latency

    The Low Latency version of aptX is not a standalone codec, but differs only in the delay and buffer settings that are used on the audio device side. The rest is just aptX.
    The codec is designed for interactive audio transmission with low latency (movies, games), where the audio delay cannot be adjusted programmatically. The software implementation is available as a Dell driver for Intel Bluetooth chips . Also supported by transmitters, receivers, headphones and speakers, but not smartphones.

    Sampling frequencyBit rateCoding supportDecoding support
    44.1 kHz352 kbpsWindows 10 with Dell driver and some transmitters (hardware)Some audio devices (hardware)


    Aac

    AAC, or Advanced Audio Coding, is a computationally complex codec with a serious psychoacoustic model. It is widely used for audio on the Internet, the second most popular after MP3. Requires licensing and royalties: $ 15,000 at a time (or $ 1,000 for companies with less than 15 employees) + $ 0.98 for the first 500,000 devices ( source ).
    The codec is standardized as part of the MPEG-2 and MPEG-4 specifications, and contrary to misconception, does not belong to Apple.

    Sampling frequencyBit rateCoding supportDecoding support
    8 - 96 kHz8 - 576 kbps (for stereo), 256 - 320 kbps (typical for Bluetooth)macOS, Android 7 + *, iOSA wide range of audio devices (hardware)
    * Only on devices whose manufacturers paid royalties

    . iOS and macOS use the best Apple AAC encoder to date, providing the highest possible audio quality. Android uses the second-highest quality Fraunhofer FDK AAC encoder, but various hardware embedded in the platform (SoC) can be used, with unknown encoding quality. According to recent SoundGuys tests , the quality of AAC encoding by different Android phones is very different: Most wireless audio devices for AAC have a maximum bitrate of 320 kbps, some only support 256 kbps. Other bitrates are extremely rare. AAC provides excellent quality at 320 and 256 kbps but is subject to
    AAC coding spectrum graph of various mobile devices.  The Huawei P20 Pro has a sharp decline around 14 kHz, the LG V30 - around 16 kHz, the Samsung Note 8 - 17 kHz, the Apple iPhone 7 - 19 kHz.


    loss of sequential encoding of already compressed content , however, it’s difficult to hear any differences with the original on iOS at a bit rate of 256 kbps even with several consecutive encodings, with a single encoding, for example, MP3 320 kbps in AAC 256 kbps can be neglected.
    As 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 in AAC again, for transmission via Bluetooth. This is necessary for mixing several audio streams, for example, music and notification of a new message. iOS is no exception. On the Internet, you can find many allegations that on iOS AAC music is not transcoded when transmitted via Bluetooth, which is incorrect.

    The AAC standard has many extensions to the standard encoding method. One of them - Scalable To Lossless (SLS) - is standardized for Bluetooth and allows you to transfer audio without loss (lossless). Alas, on real devices, expansion support is not found. The extension to reduce transmission delay AAC-LD (Low Delay) is not standardized for Bluetooth.


    MP1 / 2/3

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

    The old MP1 and MP2 codecs are not supported at all: I could not find any headphones and not a single Bluetooth stack that would encode or decode 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 my installation leads to BSoD on Windows 10. Conclusion - the codec can not actually be used for Bluetooth audio.
    Earlier, in 2006-2008, before the A2DP standard was distributed 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 architecture of the smartphone OS allowed access to many low-level functions, and on Windows Mobile it was completely possible to install third-party Bluetooth stacks.

    The latest MP3 codec patent has expired, the use of the codec does not require royalties from 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 US Patent 6,009,399, held by and administered by Technicolor, expired.
    Source: www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html

    Sampling frequencyBit rateCoding supportDecoding support
    16 - 48 kHz8 - 320 kbpsNot supported anywhereSome audio devices (hardware)


    LDAC

    Sony’s new and actively promoted Hi-Res codec, supporting sampling rates up to 96 kHz and 24-bit resolution, with a bitrate of up to 990 kbps. Advertised as an audiophile codec, as a replacement for existing Bluetooth codecs. It has the function of adaptive adjustment of bitrate, depending on the conditions of the radio.

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

    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 frequencyBit rateCoding supportDecoding support
    44.1 - 96 kHz303/606/909 kbit / s (for 44.1 and 88.2 kHz), 330/660/990 kbit / s (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’s stupid 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 CD-quality (44.1 / 16) without loss. 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 bit is transmitted through the air.

    Since the LDAC software decoder is not freely available, it is impossible to test the codec without additional devices that decode LDAC. According to the LDAC test on the DAC with its support, which was connected by SoundGuys.com engineers via a digital output and recorded the emitted sound on test signals, the LDAC 660 and 990 kbps 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 of established profiles - from 138 kbps to 990 kbps, but, as far as I can tell, Android uses only standardized profiles 303 / 606/909 and 330/660/990 kbit / s.

    LDAC CD 990 kbit / s noise profile




    Other codecs

    Other A2DP codecs are not widely used. Their support is either almost completely absent, or is 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 the HWA LHDC is too new and is supported only three (?) devices.


    Audio Codec Support

    Not all manufacturers publish accurate information about codecs that support certain wireless headphones, speakers, receivers or transmitters. 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 claims simply to be "supported", without comments (I assume that separate licensing of encoders and decoders of some codecs is to blame ) In the cheapest devices, you may not find the declared aptX support at all.

    Unfortunately, in the interfaces of most OSs, the codec used is not displayed anywhere. Information on this is available only in Android, starting with version 8, and macOS. However, even in these OSs, only those codecs that support both the phone / computer and the headphones will be displayed.

    How to find out which codecs the device supports? The most reliable option is to record and analyze a traffic dump with A2DP negotiation parameters!
    This can be done 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 standard Bluetooth HCI dump save function, which is available in the developer's tools. You will receive a btsnoop dump, which can be downloaded to the Wireshark analyzer.
    note: You can get the correct dump only by connecting from the phone / computer to the headphones / speaker (no matter how funny it sounds)! 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 you record the correct dump, first disconnect the pairing with the device, and then, while recording the dump, pair the phone with the headphones.

    Use the following display filter to filter out irrelevant traffic:
    btavdtp.signal_id


    As a result, you should see something similar: At each point of the GetCapabilities command, you can click and see the detailed characteristics of the codec. Wireshark does not know all the codec identifiers, so some codecs will have to be decrypted manually, looking at the identifier table below:
    Wireshark with a loaded dump and filter to display the A2DP GetCapabilities command


    Characteristics of one of the selected items.  The codec identifier is visible.


    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

    To find out if your device supports EDR speeds of 3 Mbps, you can filter:
    bthci_evt.code==0x0b

    image

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

    For Windows there is a simple but useful Bluetooth Tweaker utility , which, among other things, shows the current and supported codecs.
    On Linux, you can also use the avinfo program included with BlueZ.


    Comparison of codecs. Which codec is better?

    Each codec has its advantages and disadvantages.
    aptX and aptX HD use hardcoded profiles that cannot be changed without modifying the encoder and decoder. Neither the phone manufacturer nor the headphone manufacturer can change the bit rate or aptX coding coefficients. The owner of the codec, Qualcomm, provides a reference encoder in the form of a library. These facts are the strong point of aptX - you know in advance what quality of sound you will get, without any “buts”.

    SBC, on the contrary, has many configurable parameters, a dynamic bit rate (an encoder can reduce the bitpool parameter if the radio is loaded), and does not have hardcodes, but only the recommended “average quality” and “high quality”, which were added to the A2DP specification in 2003 year. “High quality” is not so high by modern standards, and most Bluetooth-stacks do not allow to use the parameters better than in the “high quality” profile, although there are no technical limitations for this.
    Bluetooth SIG does not have a SBC reference encoder in the form of a library, and manufacturers implement it themselves.
    These are the weaknesses of SBC - it is never in advance clear what sound quality to expect from a particular device. 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, the codec should theoretically give out quality indistinguishable from the original, but practice, judging by the tests of the SoundGuys laboratory on different Android devices, does not confirm this. Most likely, the fault is on low-quality hardware audio encoders built into various phone chipsets. It makes sense to use AAC only on Apple devices, and on Android it is limited to aptX and LDAC.

    Equipment that supports alternative codecs, as a rule, is of higher quality, simply because for absolutely cheap low-quality devices it does not make sense to pay license fees for using these codecs. According to my tests, SBC sounds very good on high-quality equipment.

    I made a web service encoding 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 the encoding settings directly during audio playback:
    btcodecs.valdikss.org.ru/sbc-encoder
    The service uses the SBC coding libraries from the BlueZ project and libopenaptx from ffmpeg, which are compiled into WebAssembly and JavaScript from C, via emscripten, to execute in the browser. Who could dream of such a future!

    Here's what it looks like:

    Please note how the noise level changes after 20 kHz for different codecs. There are no frequencies above 20 kHz in the original MP3 file.

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


    I hear the difference between the codecs in the 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 the differences in the codecs .

    The vast majority of Bluetooth audio chipsets used in receiving wireless devices are equipped with a Digital signal processor (DSP), which implements an equalizer, compander , stereo expander and other things designed to improve (or change) the sound. Bluetooth hardware manufacturers can configure DSP for each codec separately, and when switching between codecs, it will seem to the listener that he hears the difference in the codecs when he actually listens 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 are equipped with a program that allows you to configure DSP settings, but most cheaper headphones do not have this feature, and users cannot turn off the sound processing by regular means.

    In the picture: DECODER - Parametric equalizer - stereo enhancement - compander - post mastering - output enhancement


    In the picture: checkboxes for activating different DSP functions separately for each codec.





    Device Features

    The modern version of the A2DP standard has the function of "absolute volume control" - device volume control with special commands of the AVRCP protocol, which controls the gain of the output stage, instead of programmatically reducing the volume of the audio stream. If, when changing the volume on the headphones, the change does not synchronize with the volume on the phone, it means that your headphones or the phone do not support this function. In this case, it makes sense to listen to music always with the 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 higher.
    In reality, there are sad situations. A strong compander is turned on on my RealForce OverDrive D1 for SBC headphones, and increasing the volume increases the level of quiet sounds, but the volume of the 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 function of absolute volume control, apparently this is one of the requirements for certification of codecs.

    Some headphones support connecting two devices at the same time.. This allows, for example, listening to music from a computer and receiving calls from a telephone. 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 the headphone to report a delay to the transmitting device from which the sound actually plays. This allows you to adjust the synchronization of audio with video while watching video files: if there are problems with broadcasting, 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 don’t know about function support on other platforms.


    Bidirectional communication via Bluetooth. Voice transmission.

    For voice transmission in Bluetooth, Synchronous Connection Oriented (SCO) and its improved version of Enhanced Synchronous Connection Oriented (eSCO) are used - synchronous transmission with preliminary coordination of the connection. The mode allows you to transmit sound and voice in order, with a symmetric speed of sending and receiving, without waiting for confirmation of transmission and re-sending packets. This reduces the overall delay in transmitting 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 voice from the microphone and audio to the headphones are transmitted with the same quality.
    The transfer of the data itself is standardized by the HSP profile, which also describes additional functions, such as the operation of the volume buttons, pick-up and end-call buttons.
    Unfortunately, as of 2019, the quality of voice over Bluetooth is still poor, and it is not clear why Bluetooth SIG does nothing with it.

    CVSD
    CVSD's basic voice codec 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 a record in this codec .

    mSBC
    An additional mSBC codec was standardized in 2009, and in 2010 chips appeared that use it to transmit voice. 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.

    An example of recording in this codec .

    Not shine, but much better than CVSD, but it’s still unpleasant to use it to communicate via the Internet, especially when you use headphones to communicate in the game - the game sound will also be transmitted with a sampling frequency of 16 kHz.

    Faststream
    CSR decided to develop the idea of ​​reusing SBC. To circumvent the limitations of the SCO protocol and use higher bitrates, CSR went the other way - they implemented support for two-way SBC audio in the standard for transmitting one-way audio A2DP, standardized encoding profiles, and called it “FastStream”.

    FastStream transmits 44.1 or 48 kHz stereo sound with 212 kbit / s bitrate to the speakers, and mono, 16 kHz, with a bitrate of 72 kbit / s (slightly better than mSBC) is used to transmit audio from the microphone. Such parameters are much better suited for communicating in online games - the sound of the game and the interlocutors will be of high quality.

    An example of recording in this codec (+ microphone sound, the same as mSBC ).

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

    At the moment, support for FastStream in the OS is only in the form of a patch for Linux PulseAudio from the developer Pali Rohár, which is not included in the main branch of the program.

    aptX Low Latency
    Much to our surprise, aptX Low Latency also supports bidirectional audio, implementing the same principle as FastStream.
    It will not work to use this feature of the codec - there is no support for Low Latency decoding in any OS or in any Bluetooth stack I know.


    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 the same brand, both of which are widely used for different purposes.

    There are two different, not compatible, 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 household devices.

    Starting with Bluetooth 4.0, the changes in the specification concerned mainly Bluetooth Low Energy, and 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: www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=421043 (page 291)

    Only one change was made to the Classic version within the Bluetooth 5 specification: they added support for the Slot Availability Mask (SAM) technology, which was designed to improve the separation of the air . All other changes affect only Bluetooth LE (and 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 audio transmission using LE. The A2DP standard, used to transmit high-quality audio, works only through Bluetooth Classic, and there is no analogue in LE.

    Conclusion - to purchase audio devices with Bluetooth 5 only because of the new version of the protocol is pointless. Bluetooth 4.0 / 4.1 / 4.2 in the context of audio transmission will work the same way.
    If the announcement of new headphones mentions a double radius of operation 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 in their announcements are confused about the differences in the new version of the standard, and some Bluetooth 5 chips support the fifth version only for LE, and for Classic they use 4.2.

    Audio Delay

    The amount of delay (lag) of the audio depends on many factors: the size of the buffer in the audio stack, in the Bluetooth stack and in the most reproducing wireless device, the algorithmic delay of the codec.

    The delay of simple codecs, such as SBC, aptX and aptX HD, is very small and is 3-6 ms, which can be neglected, but complex codecs, such as AAC and LDAC, can cause a noticeable delay. 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 may be mistaken, but not by 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 the SBC codec). Assuming 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-250 ms
    aptX: 130-180 ms
    AAC: 190-240 ms
    LDAC: 160- 210 ms. I

    remind you: aptX Low Latency is not supported on operating systems, because of which a lower delay can be obtained only by a bunch of transmitter + receiver or transmitter + headphones / speaker, and all devices must support this codec.


    Bluetooth device certifications and logos issues

    How to distinguish a high-quality audio device from a cheap craft? In appearance, first of all!

    Cheap Chinese headphones, speakers, and receivers:
    1. The word “Bluetooth” is missing on the box and device, most often used “Wireless” and “BT”
    2. There is no Bluetooth logo Bluetooth logoon the box or device
    3. No blue flashing LED

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

    Consider several devices and boxes from them: These are all non-certified devices. The instructions may include the logo and 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 mean their quality:












    Conclusion

    Is Bluetooth able to completely replace wired headphones and headsets? It is capable, but at the cost of low quality talk time, increased audio transmission delay, which can be annoying in games, and many 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 for the "obsolete and bad" SBC, which is far from being as bad as it is commonly thought of.

    As it turned out, the artificial limitations of Bluetooth stacks on the SBC bitrate can be circumvented, so that SBC will not be inferior to aptX HD. I took the initiative in my own hands and made a patch for LineageOS firmware: We modify the Bluetooth stack to improve the sound on headphones without AAC, aptX and LDAC codecs

    More information can be found on SoundGuys and SoundExpert .

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


    Also popular now: