« Back

Audio quality of SBC XQ Bluetooth audio codec

Published Date 6/29/19 10:02 PM
SBC XQ logo

SBC XQ is not just a new Bluetooth (BT) audio codec, it is a lifehack.

Standard BT audio codec SBC is incorporated into all BT stereo audio devices as mandatory [1][2]. It can work at arbitrary high bitrates but BT documents, however, recommend 328 kbit/s (44.1/16) for high quality mode. This mode provides just acceptable audio quality according to SE ratings. In order to increase quality of audio transmission over BT:

  • CSR plc, a multinational semiconductor company acquired APT Licensing Ltd. and introduced aptX audio codec, then aptX HD, then Qualcomm bought all these and additionally introduced aptX Low Lattency and aptX Adaptive codecs
  • Sony introduced its proprietary Hi-Rez LDAC
  • Samsung introduced three new BT audio codecs: HD/Scalable/UHQ-BT
  • Huawei introduced HWA LHDC audio codec
  • Apple uses AAC in its products
  • a guy under the nick ValdikSS wrote the patch for Android and another guy - Pali Rohár - for Linux; these patches unlock higher bitrates of SBC encoder.

It turned out that almost all modern BT headphones, speakers, receivers ... support SBC bitrates up to 730 kbit/s just out of the box. And that patch (SBC XQ) helps to encode BT audio on Andriod smartphones at the following bitrates:

  • BT EDR 2 - 452.0 kbit/s for 44.1/16, 492.0 kbit/s for 48/16
  • BT EDR 3 - 551.2 kbit/s for 44.1/16, 600.0 kbit/s for 48/16

The choice of bitrates looks like a reasonable compromise between audio quality, compatibility with current BT devices and stability of BT connection [3][4].

The SBC XQ codec (at bitrates for 44.1/16) was added to our live listening tests:

SBC XQ CBR@452.0 (Bluetooth) - Subband codec for Bluetooth A2DP profile, CBR, 452.0 kbit/s FBR
CODER: SBC Encoder LIB Version 1.5 (Philips)
- usage: sbc_encoder -v -p -r453000 -oout.sbc ref.wav
- SBC XQ default setting for BT EDR2
- 44100 Hz, Dual Channel
- bitpool: 38, bands: 8, blk_len: 16, allocation method: Loudness
DECODER: SBC Decoder LIB Version 1.5 (Philips)

SBC XQ CBR@551.2 (Bluetooth) - Subband codec for Bluetooth A2DP profile, CBR, 551.2 kbit/s FBR
CODER: SBC Encoder LIB Version 1.5 (Philips)
- usage: sbc_encoder -v -p -r552000 -oout.sbc ref.wav
- SBC XQ default setting for BT EDR3
- 44100 Hz, Dual Channel
- bitpool: 47, bands: 8, blk_len: 16, allocation method: Loudness
DECODER: SBC Decoder LIB Version 1.5 (Philips)

Early ratings (inaccurate so far) are available on the page Encoders 320+ kbit/s. For more accurate results, please, participate in SE listening tests - there is a short instruction on that page below the ratings.

 

Df-measurements of SBC XQ with music signal

If the text below seems a bit confusing, please, refer to the previous article - Audio quality of Bluetooth aptX and aptX HD

Once again, assessment of perceived sound quality by means of any objective measurements should be made with great care. In df-metric we have the criterion, which defines whether df-measurements can be used as such or not. It is similarity of sound signatures or artifact signatures of devices under test. If their artifact signatures are close enough, then their df-measurements correlate well to the scores of perceived sound quality.

For broader perspective we will compare artifact signatures of SBC XQ@452.0 and SBC XQ@551.2 with SBC@201 (Low Quality), SBC229 (Middle Quality), SBC@328 (High Quality), aptX@352, aptX HD@529, ADPCM IMA@354, AAC@256. As in previous articles we will use Pink Floyd album “The Dark Side of The Moon” as the test signal.

Figure 1. The dendrogram shows how different BT audio codecs relate to each other according to their artifact signatures. The shorter the link between two codecs, the more similar their artifact signatures. The Spearman distance 0.1 is critical for relation of Df measurements to subjective scores. Similarity dendrogram of tested BT codecs

 

We can see that SBC and aptX codecs have similar artifact signatures (distance<0.1), so their df-measurements are indicative of their perceived sound quality.

Figure 2. Histograms of df-sequences for the codecs under test. Medians and 25/75 percentiles are indicated. Median Df is an estimator of average waveform degradation. Shape of histogram relates to character/type of waveform degradation - artifact signature.

 

Looking at Df medians we can safely conclude that audio quality of SBC XQ is comparable to aptX HD. And for BT EDR3 devices SBC XQ slightly surpasses aptX HD. It will be impossible to tell them apart in a blind listening test. SBC codec uses primitive psychoacoustic model for encoding and aptX does not use it at all, so their perceived audio quality is determined mostly by bitrate. Different settings of SBC, including SBC XQ, can be compared to aptX and aptX HD aurally with the help of Bluetooth A2DP SBC/aptX online encoder [5].

All current BT stereo devices could use this higher quality encoding. It just suffices to modify BT stack of sending device. Receiving BT devices that support only mandatory SBC codec will benefit most from this trick.

At the moment the required patch is included into LineageOS, Resurrection Remix and crDroid forks of Android. The patch for Linux PulseAudio from Pali Rohár besides SBC XQ also adds support for aptX, aptX HD and FastStream codecs [6]. This extra quality is for free. It's hard to imagine any objection to including this option into all BT stacks and the main Android branch. You can request this feature in your operating system:

Future versions of SBC XQ will include more bitrate choices. So, manufacturers of BT headphones, speakers and receivers can further improve audio quality of their BT products simply by removing all limits to SBC decoding parameters, thus providing full support for SBC XQ.

References

[1] Bluetooth SIG, Specification of the Bluetooth System, Profiles, Advanced Audio Distribution Profile, v1.3.2, 2019-01-21, https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=457083

[2] Christian Hoene, Mansoor Hyder, “Considering Bluetooth’s Subband Codec (SBC) for Wideband Speech and Audio on the Internet”, Technical Report WSI-2009-3, 2009-10, https://pdfs.semanticscholar.org/1f19/561d03bc88b67728375566c95bbf77e730d5.pdf

[3] ValdikSS, “Bluetooth stack modifications to improve audio quality on headphones without AAC, aptX, or LDAC codecs”, 2019-06-18, https://habr.com/en/post/456476/

[4] ValdikSS, “Improve Bluetooth audio quality on headphones without aptX or LDAC”, since 2018-08-22, https://forum.xda-developers.com/android/software-hacking/improve-bluetooth-audio-quality-t3832615

[5] Bluetooth A2DP SBC/aptX online encoder, https://btcodecs.valdikss.org.ru/sbc-encoder/

[6] Pali Rohár, New API for Bluetooth A2DP codecs, since 2019-01-12, https://patchwork.freedesktop.org/series/55117/

 

Update

September 2019

Another patch for PulseAudio BT stack is available now from JP Guillemin - https://github.com/JPGuillemin/pulseaudio/tree/SBC-XQ. This patch activates SBC XQ mode in Linux systems in the most simple end effective way - it allows to transmit audio using standard SBC codec in the highest possible quality supported by receiving BT device.

 

By Serge Smirnoff
1266358 Views, 30 Comments
aptx aptxhd audio quality bluetooth sbc sbcxq
  • Bookmark and Share
  • Clip to Evernote
Average (0 Votes)
The average rating is 0.0 stars out of 5.
Comments
Add Comment
resom
Hi,

I tried the Toshiba Bluetooth Stack on windows, but exept the sound quality option, I don’t find the one to enable Dual Channel Mode!! Where is it hidden? Thanks for your help!
Posted on 8/20/19 4:43 PM.
Serge Smirnoff
I've never heard about Dual Ch. mode being implemented somewhere. For BT detailes, please refer to the article "Audio over Bluetooth: most detailed information about profiles, codecs, and devices" - https://habr.com/en/post/456182/ by ValdikSS
Posted on 8/22/19 10:20 AM in reply to resom.
JP Guillemin
Hi,

I have made this patch for Pulseaudio 13.0 that extend SBP bitpool negociation to XQ quality.

here are the features of the (very simple and non intrusive) patch :
- allow to use bitpool 76 on devices that support it, aka SBC XQ
- harmless for devices limited to bitpool 53
- deprecates the need for APTX & APTX HD support, which are not better than SBC XQ, are not Open Source, and less supported by devices

Tested on 10 different devices : headsets, stereo speakers, mono speakers

The patch : http://download.zenwalk.org/x86_64/testing/pulseaudio-13.0-SBC-XQ_V2.patch

Could you eventually test it and/or add this patch as reference to the article ?

All the best
JP
Posted on 9/18/19 1:03 PM.
Serge Smirnoff
Cool. Thanks. Will do. But seems I will need your help. Please, contact me in any way - http://soundexpert.org/contact-us
Posted on 9/19/19 10:48 AM in reply to JP Guillemin.
ValdikSS
I suppose the patch is created to be included in Zenwalk Linux distro. Please don't to that, this is a terrible idea, it will definitely introduce regressions with some of the hardware.

1. Some hardware can't handle Dual Channel even if reports to support it. The audio will stutter or distort. I know 6 devices which act like this.
2. You've increased Joint Stereo max bitpool to 94. This will introduce regression with some hardware, too (see https://review.lineageos.org/c/LineageOS/android_packages_apps_Bluetooth/+/22931­0/4#message-366b72d29e7d0cdb273304b791317035bb2a1560)
3. You've chosen max bitpool 94, which produces bitstream which cannot be effectively packed in a Bluetooth packet. See https://btcodecs.valdikss.org.ru/sbc-bitrate-calculator/ (200 wasted bytes for EDR3).

Are you aware of Pali Rohar patchset, which among other things introduces SBC XQ support?
https://patchwork.freedesktop.org/series/55117/
If yes, what was the reason for making your own patch?
Posted on 9/20/19 8:25 PM in reply to JP Guillemin.
JP Guillemin
Thanks for your answer. Of course I have read all the articles you point above.

This patch is very simple, and won't affect any device which doesn't support dual Chanel or high bitpools. It just allow devices that clearly advertise that they support high bitpool : to actually be allowed to play SBC XQ. Everything remains negociated and won't cause any device to play SBC XQ if it doesn't advertise being able to do it during négociation. My Harman Kardon speaker advertise bitpool 94, and I wanted to provide a way to use these kind of higheend speaker corectlyto everyone. I agree with you that many devices still advertise bitpool 53 : my patch doesn't impact those devices. Pali's patch does differently : beside being a complete rewrite of the BT stack : it forces SBC XQ when XQ1 or XQ2 is selected, causing distorsion on devices that can't do more than bitpool 53. Please note that many devices that claim not being able to go higher than 53, actually perform vert well in dual Chanel, but I finally chose not to force them.
I hope it's clear now ;)
All the best
Jp
Posted on 9/20/19 9:16 PM in reply to ValdikSS.
JP Guillemin
ValdikSS,
Your answer made me want to try to fill the gap between devices announcing max53 bitpool and those rare that announce more than 53 (ie : 94 in the case of my main speakers).

So I spent some time playing with SBC parameters, and finally managed to find a solution to (hopefully) make all devices support dual channel at 2x38 bitpool (~ 450kbps).

With this new version, even the devices that previously distorded : are playing very well in dual channel mode.

I would be very thankfull if you could test it ;)

Thanks
JP
Posted on 9/21/19 10:21 AM in reply to ValdikSS.
JP Guillemin
ValdikSS : here's the source code : http://download.zenwalk.org/x86_64/testing/pulseaudio-SBC-XQ.tar.gz
Posted on 9/21/19 10:26 AM in reply to ValdikSS.
ValdikSS
Some headphones and speakers announce to support high max bitpool values, but does not really support them, producing distort sound or hiccups.
The same applies to Dual Channel: I have hardware which announce its support but can't handle it at all (no sound), with any bitpool value.

That's why applying these modifications by default is not a good idea.
Posted on 9/24/19 5:42 AM in reply to JP Guillemin.
JP Guillemin
ValdikSS,

Have you tested my code ?

The problems you describe should not happen with the way bitpool is negociated.

Enjoy
Jp
Posted on 9/24/19 6:22 AM.
JP Guillemin
Some infos :

SBC XQ is standard SBC codec operating at high bitrates and thus reaching the transparent audio transport quality of AptX (HD)
and other proprietary codecs.
According to http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-­codec , AptX quality can be reached
either :

in STEREO MODE, with bitpool ~ 76
in DUAL CHANNEL MODE, with bitpool ~ 38 per channel

APTX-HD quality is achieved with values :

in STEREO MODE, with bitpool ~ 94
in DUAL CHANNEL MODE, with bitpool ~ 47 / channel

A2DP specification (A2DP SPEC) defines SBC parameters. These parameters are negotiated between the source (SRC) and the receiver (SNK) at connection time :

Audio channel mode : Joint Stereo, Stereo, Dual Channel, Mono : all modes are MANDATORY for the SNK according to A2DP specification
Number of subbands: 4 or 8 - both MANDATORY for the SNK implementation
Blocks Length: 4, 8, 12, 16 - all MANDATORY for the SNK implementation
Allocation Method: Loudness, SNR - both MANDATORY for the SNK implementation
Maximum and minimum bit pool : between 2 to 250, expressed in 8 bit uint (Unsigned integer, Most significant bit first) :
-- A2DP spec v1.2 states that requires all SNK implementation shall handle bitrates of up to 512 kbps (which correspond to bitpool = 76).
-- A2DP spec v1.3 doesn't specify any bitrate limit, and some high-end SNK devices announce bitpool between 62 and 94 (bitpool 94 = 551kbps bitrate).

These high end devices should not be limited to low bitrates because of arbitrary SRC bitpool limit.
The A2DP specification V1.3 provides RECOMMENDATIONS for bitpool implementation for the encoder of the SRC : it is required to support AT LEAST the following settings :

STEREO MODE : 53
MONO MODE : 31
DUAL CHANNEL : unspecified, so let's assume that the MONO value can be used : 31

In the implementation of this patch : bitpool IS ALWAYS NEGOCIATED, never forced, and the maximum value announced by the SNK device IS safely followed WHATEVER MAXIMAL BITPOOL VALUE IS ALLOWED ON SRC SIDE.
I propose the following safe maximal values (can be discussed) :

STEREO MODE : <= 94
MONO MODE : <= 32
DUAL CHANNEL : <= 38 (always inferior to any device capability, since 90% of them announce max bitpool = 53 and the remaining devices : more than 53. Very few announce ~ 40).

The negotiation policy is as follow :

Any SNK device announcing max bitpool > 53 is allowed to reach 94 (if the SNK device announce 57 then 57 will be used)
Any SNK device announcing max bitpool > 53 is offered STEREO MODES first, and DUAL CHANNEL as fall back
Any SNK device announcing max bitpool <= 53 is allowed to reach 53 (if the SNK device announce 47 then 47 will be used)
Any SNK device announcing max bitpool <= 53 is FIRST offered DUAL CHANNEL at bitpool 38, so that the 512 kbps is never exceeded (if the SNK device announce 47 then 38 will be used, if the SNK device announce 31 then 31 will be used)
Any SNK device announcing max bitpool <= 53 is THEN offered STEREO MODES if DUAL CHANNEL is announced unsupported (if the SNK device announce 47 then 47 will be used).
Posted on 9/27/19 12:39 PM in reply to JP Guillemin.
ValdikSS
I understand what do you say, but it seems you don't understand me.
I'll try once more.

There are devices which negotiate high max bitpool, but can't really handle it. They either stutter while playing, don't play any sound at all or just can't decode the stream correctly, introducing crackling or even slight pitch-shifting. Apparently, nobody tested them with high bitpools (because all stacks, except Linux, has max bitpool 53, you just can't test higher bitpools with real hardware).
See
https://review.lineageos.org/c/LineageOS/android_packages_apps_Blue­tooth/+/22931­0/4#message-366b72d29e7d0cdb273304b791317035bb2a1560

There are devices which negotiate Dual Channel, but does not produce any sound at all. I own such device. I bought it for testing, after the report from the user of my patch that it breaks his device.
See
https://4pda.ru/forum/index.php?s=&showtopic=914135&view=findpost&p=76­551847
https://4pda.ru/forum/index.php?s=&showtopic=914135&view=findpost&p=889592­14
https://4pda.ru/forum/index.php?s=&showtopic=19447&view=findpost&p=76126352

The­ bitpool is locked to 53 on all stacks (except on Linux) due to devices' bugs, it has a reason.
You shouldn't enable Dual Channel or higher bitpools by default, unless you want to break some of the existing devices.
Posted on 9/27/19 10:00 PM in reply to JP Guillemin.
JP Guillemin
Hi,
Won't worry, I got your point from the beginning, and I know that you master the subject very well. I will add an option to disable XQ mode for devices that have a broken SBC implementation. These devices are rare, but we can not leave the end user without a solution in case he's the lucky owner of a headset that negociates dual channel without realy being able to play in dual channel. But MY POINT OF VIEW, as an engineer, is that the Pulseaudio SBC IMPLEMENTATION MUST NOT BE DESIGNED UPON BROKEN DEVICES. The implementation SHOULD follow the specifications at their best, and provide a way to the user to eventually use a broken device. Like you did for Lineage. I never design based on exceptions, but on the good standard. Once the base patch is discussed, improved, and merged : I will code the config option as a workaround.

All the best.
Jp
Posted on 9/27/19 10:32 PM in reply to ValdikSS.
Gabriel Bouvigne
Hello,

I'd like to provide a bit a "semantic" information regarding the stereo modes. From a general POV (ie: experience with other audio codecs such as MP3 or AAC), the semantic is the following:

- dual channel:
Means that there are two channels, each carrying a different content. An example is a track with Swedish language audio on the first channel and English languate on the second channel. There is thus a wide range of possible behavior of client devices/decoders. Some will simply consider the track in the same way as stereo, some will only output one of the channels, and some will unfortunately choke on the content.
In some cases the encoder will also act in a specific way, such as allocating exactly half of the available bits for each of the channels.

- stereo:
Means that the two channels are L/R. If the codec also provides a joint stereo option, then stereo is to be interpreted as meaning that bit allocation can be dynamically balanced between both channels, depending of the needs: based on the complexity, one channel could be allocated more bits than the other one in a given frame, if required.
For codecs which don't present different options for stereo and joint-stereo, sometimes what is referred as "stereo" is actually "joint stereo".

- joint stereo:
Means that channels are L/R, but can be partially combined in order to reach higher coding efficiency (by techniques such as mid/side stereo or intensity stereo).
On some codecs, joint stereo is quite more efficient than stereo, with no negative consequences. As an example, in the MP3 case, joint stereo required about 1.6x the mono bitrate to provide a similar quality, while stero required 2x the mono bitrate.

Thus, we could possibly infer that:
- using dual channel configuration for stereo content might lead to undesired interoperability effects.
- For the same overall bitrate, joint-stereo could provide higher quality than stereo (if the coding tools are appropriate).

If someone has a link to an SBC specification, I could check what is underneath its joint-stereo option...
Posted on 11/19/19 12:33 PM.
Serge Smirnoff
https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=457083
Posted on 11/19/19 2:52 PM in reply to Gabriel Bouvigne.
Gabriel Bouvigne
Thanks!

Based on this doc, a coder following the description from this doc would exhibit the following behavior:

- Dual channel splits the available bits in half between both channels. Thus if at some point one of the channels is easier to encode than the other, dual channel does not allocate more bits to the more complex channel. Thus, it is better to use stereo than dual channel, as stereo can balance bit needs between channels.

- Joint stereo is using mid/side stereo, in a similar way as MP3 and AAC. (it does not use intensity stereo such as what is used in MPEG audio Layer II). The encoder can decide per block and per subband if stereo or joint stereo should be used. Thus, in theory, joint stereo should be a better choice than stereo, as this setting actually enable the encoder to switch between both modes.

SBC looks to be a relatively simple codec, but there is room for quality variation between encoders (even though it will always be a simple codec, with limited coding efficiency).

Based on this decoding spec, it's very likely that, using the same bitrate, joint stereo would be the best choice.


note:
If you have a very simple encoder, it could fail badly in a tricky case for joint stereo: if left and right channels have inverted phases, a "dumb" encoder would output a near-silent stream. That would be an interesting test....
Posted on 11/19/19 3:42 PM in reply to Serge Smirnoff.
ValdikSS
You're forgetting that with Dual Channel it's possible to get twice the bitrate which is possible with Stereo or Joint Stereo, because of its different interpretation of bitpool. It does not split the available bits in half, instead, it doubles the available bits.
Please see my post here:
https://forum.xda-developers.com/showpost.php?p=81058729&postcount=234
Posted on 11/30/19 5:52 AM in reply to Gabriel Bouvigne.
Gabriel Bouvigne
Indeed.
In theory I'm right (with the same bitrate, better use joint stereo than dial channel), but practically you are right (as strangely most devices have a max bitpool instead of a max bitrate).

It looks to me that devices having a limit on bitpool instead of bitrate is a bit strange (even though it's the reality). Why would the limit not be physical (actual bitrate / buffer)? There is a possibility that all of those devices are using the same bluetooth/SBC implementation, as the bitpool limit seems to be exactly the same one on many devices.
If they can sustain about twice stereo/JS bitrate in dual channel, in theory they should also be able to sustain this higher bitrate in stereo/JS, which would be a vast quality improvement....
Posted on 11/30/19 7:15 AM in reply to ValdikSS.
ValdikSS
>Why would the limit not be physical (actual bitrate / buffer)?

I've absolutely no idea. That's what I asked people from Android and Broadcom, who are related to Bluetooth development, but received no reply. I can't even guess why the specification ended up negotiating bitpool, not bitrate.

>If they can sustain about twice stereo/JS bitrate in dual channel, in theory they should also be able to sustain this higher bitrate in stereo/JS, which would be a vast quality improvement....

Sure, using high-bitrate Joint Stereo would be ideal. I assume that most devices have max bitpool set to 53 due to compatibility reasons with devices which violate specification (or just buggy), but which could not be replaced easily (car stereo).
See https://review.lineageos.org/c/LineageOS/android_packages_apps_Bluetooth/+/22931­0/4#message-366b72d29e7d0cdb273304b791317035bb2a1560 for example.
Posted on 11/30/19 1:30 PM in reply to Gabriel Bouvigne.
Arkq
Since commit 1771b9e BlueALSA (https://github.com/Arkq/bluez-alsa) supports SBC XQ as well. If someone is using RPi with Raspbian, please compile bluez-alsa from master branch by yourself, in order to suport HD SBC sound quality.
Posted on 12/16/19 1:34 PM.
Showing 1 - 20 of 30 results.
of 2
First Previous Last
Audio-Transparency Initiative