Hello. I'm researching A2DP lately and I don't know anybody who deeply understands Bluetooth and Bluetooth codecs, hope you don't mind my questions.
A lot of people on the internet complain about SBC audio quality. Not all headphones negotiate high bitpool values, which usually leads to more or less distorted high frequencies.
Almost all of the time in my tests with laptop, smartphones and different headphones, SBC was negotiated with the following parameters: 8 subbands, 16 blocks, 53 max bitpool value. These parameters give 328 kbit/s bitrate for 44.1 kHz, 345 kbit/s for 48 kHz. While these parameters produce pretty decent audio, you can clearly see 17 kHz cutoff due to lack of free quantization bytes for higher frequencies. The majority of headsets have 53 max bitpool value.
I'm confused of bitpool. After reading A2DP specification, SBC RTP incapsulation RFC and some other documents, I still can't understand why it was decided to use bitpool and not bitrate in the codec parameters negotiation process. It doesn't describe maximum bitrate constraints and limits maximum possible audio quality because it's not bound to other codec parameters, which have a lot of influence on the bitrate. You can almost double the bitrate by using dual_channel instead of stereo/joint stereo, or set 4 subbands for stereo, with the same max bitpool value, and get higher audio quality/bitrate.
By patching pulseaudio, I was able to use 4 subbands dual_channel SBC with my headphones with 730+ kbit/s overall bitrate, much higher compared to stock 328 kbit/s for 44.1 kHz 51 max bitpool value from the specification. Audio is full bandwidth now, and not cut off at 17 kHz, and I'm still not exceeding maximum bitpool value supported by the headphones (Overdrive RealForce D1, CSR chipset).
Interesting that android bluetooth stack (bluedroid) operates with bitrate. It has bitpool constraints (max 53) and bitrate constraints (max 328, even for 48 kHz), and it won't use e.g. bitpool 53 with 48 kHz (as pulseaudio do on my headphones), but would downgrade it to 51 to fit it into 328 kbit/s. With a patched Android Bluetooth stack, I was able to use 660 kbit/s SBC audio on an old Android phone with Bluetooth 2.1 without any problems.
A2DP v1.2 specification states the following:
>The decoder of the SNK shall support all possible bitpool values that do not result in excess of the maximum bit rate. This profile limits the available maximum bit rate to 320kb/s for mono, and 512kb/s for two-channel modes.
Current version of the specification does not have this statement, but contains the following:
>A SNK device may support bitpools larger than the High Quality value in Table 4.7, but shall be required to demonstrate the ability to acceptably render the resulting media.
As far as I understand, A2DP v1.2 compatible decoders should support bitrates up to 512 kbit, and the following profile is valid for them: DUAL_CHANNEL, 8 subbands, 16 blocks, 43 max bitpool, which results in 507 kbit/s bitrate.
The majority of the headphones set bitpool max to 53, but there are some with 80 or even 250 values. For example:
Beats Solo³: bitpool: 2..250
JBL Everest Elite 750NC: bitpool 10..80
To me it feels that bitpool should be an internal variable. Is it a specification design fault that bitpool value is not bound to other codec parameters and only defined as a global value, or am I missing something? Do you have an idea why all current bluetooth stacks prefer, for example, joint stereo and not dual_channel with twice the bitrate? Would it be safe to switch current implementations to use dual_channel with bitrate limit of 512 kbit/s?
Thanks.
On 16.08.2018 23:23, ValdikSS wrote:
> On 16.08.2018 22:53, Luiz Augusto von Dentz wrote:
>> The reason of 53 bitpool is probably due to the spec. suggesting it as
>> high quality, which as you said is not quite right, so BlueZ never
>> really imposed any limitation on what you can configure, even going
>> above 512 kbit/s. As for not using dual channel that is known to
>> consume more bandwidth which may have an impact on airtime and
>> coexisting with wifi which is why joint stereo is preferred, the real
>> problem I would say is limiting to just 53 especially because the
>> bitpool can be adjusted on the fly so this is on the headset
>> manufacturers, perhaps because they actually want SBC to be perceived
>> as a bad codec so user would favor their proprietary codec? Or perhaps
>> because SBC has a quite bad compression rate and latency compared to
>> other codecs, still there is no reason to limit the bitpool.
>>
> I see the problem in the specification. Imagine you're a headphones manufacturer and your chip limitation is 512 kbit/s. There's no way to properly indicate this constraint. If you return bitpool max 53 in GetConfiguration/GetAllConfiguration
GetCapabilities/GetAllCapabilities*
> for the connecting device, everything would be fine with joint stereo/stereo/mono, 8 subbands and 16 blocks, but the connecting device can use DUAL_CHANNEL with bitpool 53, which will produce 617 kbit/s SBC audio for 44.1 kHz, or even just use 4 subbands with joint stereo, which will produce 633 kbit/s and is higher than a bitrate constraint.
>
> The decoder should support all channel types, all block sizes and all subbands. The headphone manufacturer can't restrict connection only to joint stereo/stereo as it wouldn't be compatible with the specification.
>
> As far as I know, only source can decrease the bitpool, the headphones have no way to notify the source that high bitrate audio can't be decoded and played properly.
>
> To circumvent max bitpool 53 found on most headphones, bluetooth stacks could use either DUAL_CHANNEL, or joint stereo with 4 subbands. I prefer the former.
>
On 16.08.2018 22:53, Luiz Augusto von Dentz wrote:
>
> The reason of 53 bitpool is probably due to the spec. suggesting it as
> high quality, which as you said is not quite right, so BlueZ never
> really imposed any limitation on what you can configure, even going
> above 512 kbit/s. As for not using dual channel that is known to
> consume more bandwidth which may have an impact on airtime and
> coexisting with wifi which is why joint stereo is preferred, the real
> problem I would say is limiting to just 53 especially because the
> bitpool can be adjusted on the fly so this is on the headset
> manufacturers, perhaps because they actually want SBC to be perceived
> as a bad codec so user would favor their proprietary codec? Or perhaps
> because SBC has a quite bad compression rate and latency compared to
> other codecs, still there is no reason to limit the bitpool.
>
I see the problem in the specification. Imagine you're a headphones manufacturer and your chip limitation is 512 kbit/s. There's no way to properly indicate this constraint. If you return bitpool max 53 in GetConfiguration/GetAllConfiguration for the connecting device, everything would be fine with joint stereo/stereo/mono, 8 subbands and 16 blocks, but the connecting device can use DUAL_CHANNEL with bitpool 53, which will produce 617 kbit/s SBC audio for 44.1 kHz, or even just use 4 subbands with joint stereo, which will produce 633 kbit/s and is higher than a bitrate constraint.
The decoder should support all channel types, all block sizes and all subbands. The headphone manufacturer can't restrict connection only to joint stereo/stereo as it wouldn't be compatible with the specification.
As far as I know, only source can decrease the bitpool, the headphones have no way to notify the source that high bitrate audio can't be decoded and played properly.
To circumvent max bitpool 53 found on most headphones, bluetooth stacks could use either DUAL_CHANNEL, or joint stereo with 4 subbands. I prefer the former.
Hi,
On Thu, Aug 16, 2018 at 9:45 PM ValdikSS <[email protected]> wrote:
>
> Hello. I'm researching A2DP lately and I don't know anybody who deeply un=
derstands Bluetooth and Bluetooth codecs, hope you don't mind my questions.
>
> A lot of people on the internet complain about SBC audio quality. Not all=
headphones negotiate high bitpool values, which usually leads to more or l=
ess distorted high frequencies.
>
> Almost all of the time in my tests with laptop, smartphones and different=
headphones, SBC was negotiated with the following parameters: 8 subbands, =
16 blocks, 53 max bitpool value. These parameters give 328 kbit/s bitrate f=
or 44.1 kHz, 345 kbit/s for 48 kHz. While these parameters produce pretty d=
ecent audio, you can clearly see 17 kHz cutoff due to lack of free quantiza=
tion bytes for higher frequencies. The majority of headsets have 53 max bit=
pool value.
>
> I'm confused of bitpool. After reading A2DP specification, SBC RTP incaps=
ulation RFC and some other documents, I still can't understand why it was d=
ecided to use bitpool and not bitrate in the codec parameters negotiation p=
rocess. It doesn't describe maximum bitrate constraints and limits maximum =
possible audio quality because it's not bound to other codec parameters, wh=
ich have a lot of influence on the bitrate. You can almost double the bitra=
te by using dual_channel instead of stereo/joint stereo, or set 4 subbands =
for stereo, with the same max bitpool value, and get higher audio quality/b=
itrate.
>
> By patching pulseaudio, I was able to use 4 subbands dual_channel SBC wit=
h my headphones with 730+ kbit/s overall bitrate, much higher compared to s=
tock 328 kbit/s for 44.1 kHz 51 max bitpool value from the specification. A=
udio is full bandwidth now, and not cut off at 17 kHz, and I'm still not ex=
ceeding maximum bitpool value supported by the headphones (Overdrive RealFo=
rce D1, CSR chipset).
>
>
> Interesting that android bluetooth stack (bluedroid) operates with bitrat=
e. It has bitpool constraints (max 53) and bitrate constraints (max 328, ev=
en for 48 kHz), and it won't use e.g. bitpool 53 with 48 kHz (as pulseaudio=
do on my headphones), but would downgrade it to 51 to fit it into 328 kbit=
/s. With a patched Android Bluetooth stack, I was able to use 660 kbit/s SB=
C audio on an old Android phone with Bluetooth 2.1 without any problems.
>
>
> A2DP v1.2 specification states the following:
>
> >The decoder of the SNK shall support all possible bitpool values that do=
not result in excess of the maximum bit rate. This profile limits the avai=
lable maximum bit rate to 320kb/s for mono, and 512kb/s for two-channel mod=
es.
>
> Current version of the specification does not have this statement, but co=
ntains the following:
>
> >A SNK device may support bitpools larger than the High Quality value in =
Table 4.7, but shall be required to demonstrate the ability to acceptably r=
ender the resulting media.
>
> As far as I understand, A2DP v1.2 compatible decoders should support bitr=
ates up to 512 kbit, and the following profile is valid for them: DUAL_CHAN=
NEL, 8 subbands, 16 blocks, 43 max bitpool, which results in 507 kbit/s bit=
rate.
>
> The majority of the headphones set bitpool max to 53, but there are some =
with 80 or even 250 values. For example:
> Beats Solo=C2=B3: bitpool: 2..250
> JBL Everest Elite 750NC: bitpool 10..80
>
>
> To me it feels that bitpool should be an internal variable. Is it a speci=
fication design fault that bitpool value is not bound to other codec parame=
ters and only defined as a global value, or am I missing something? Do you =
have an idea why all current bluetooth stacks prefer, for example, joint st=
ereo and not dual_channel with twice the bitrate? Would it be safe to switc=
h current implementations to use dual_channel with bitrate limit of 512 kbi=
t/s?
The reason of 53 bitpool is probably due to the spec. suggesting it as
high quality, which as you said is not quite right, so BlueZ never
really imposed any limitation on what you can configure, even going
above 512 kbit/s. As for not using dual channel that is known to
consume more bandwidth which may have an impact on airtime and
coexisting with wifi which is why joint stereo is preferred, the real
problem I would say is limiting to just 53 especially because the
bitpool can be adjusted on the fly so this is on the headset
manufacturers, perhaps because they actually want SBC to be perceived
as a bad codec so user would favor their proprietary codec? Or perhaps
because SBC has a quite bad compression rate and latency compared to
other codecs, still there is no reason to limit the bitpool.
--=20
Luiz Augusto von Dentz