[pulseaudio-discuss] Bluetooth A2DP aptX codec quality

[Pali Rohár]

Hello!

I would like to let you know that Serge from soundexpert.org did in last
month some research on aptX and its quality. Detailed article is on the
following website, specially see parts added around "August 2018":

http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx

============
Conclusions:

aptX codec used in BT applications is no better than ***@328. Despite
slightly lower algorithmic delay of aptX both SBC and aptX codecs
provide the same 100-150ms latency in real-life BT applications.

If you hear the difference between SBC and aptX in some BT product,
there can be only two explanations - placebo effect or using SBC in
Middle or Low Quality modes.

AptX is just a copper-less overpriced audio cable.

aptX HD is high-bitrate version of aptX. It has clearly noticeable
increase in sound quality (not dramatic though taking into account the
increase in bitrate)
============

And it just confirms my own testing. Whatever I did I was not able to
either hear or see difference between aptX and SBC encoded-->decoded
audio.

I had discussion with Serge and there are some ideas which Linux
Bluetooth A2DP software could supports:

1) Allow user to specify SBC codec quality. In most cases, including
pulseaudio, SBC quality is chosen either to middle or low, not to
maximum bitpool. In some cases SBC at high quality can provide better
quality as aptX and more important -- SBC is supported by all headsets.

2) Show user current SBC codec quality. So user would know what was
chosen and what should expect. I was told that Windows's Toshiba
bluetooth stack has support for this indication.

3) In some cases SBC SNR bit allocation method can provide better
quality as SBC loudness method.

So then I could ask question:

1) What to do with aptX? It is really useful for users to have it in
Linux & pulseaudio? Because it looks like that the only thing which it
has better is lower latency. But can pulseaudio on Linux system really
achieve it?

2) Should we rather look at increasing quality of SBC codec in
pulseaudio? And if yes, how should be quality of SBC configured? Via
profiles? Or to invent some new protocol options? Can we increase
default SBC bitpool allocation?

3) If aptX is decided as useless, what about aptX HD codec? aptX HD
codec is supported by less products (currently I do not own any), but
this one may provide better quality as SBC according to that research.

PS: That aptX research is the first and the only one about which I know.
All other information about quality or other details which I found on
internet are just marking informations.

[Luiz Augusto von Dentz]

Hi Pali,

Post by Pali Rohár
Hello!
I would like to let you know that Serge from soundexpert.org did in last
month some research on aptX and its quality. Detailed article is on the
http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
============
slightly lower algorithmic delay of aptX both SBC and aptX codecs
provide the same 100-150ms latency in real-life BT applications.
If you hear the difference between SBC and aptX in some BT product,
there can be only two explanations - placebo effect or using SBC in
Middle or Low Quality modes.
AptX is just a copper-less overpriced audio cable.
aptX HD is high-bitrate version of aptX. It has clearly noticeable
increase in sound quality (not dramatic though taking into account the
increase in bitrate)
============
And it just confirms my own testing. Whatever I did I was not able to
either hear or see difference between aptX and SBC encoded-->decoded
audio.
I had discussion with Serge and there are some ideas which Linux
1) Allow user to specify SBC codec quality. In most cases, including
pulseaudio, SBC quality is chosen either to middle or low, not to
maximum bitpool. In some cases SBC at high quality can provide better
quality as aptX and more important -- SBC is supported by all headsets.
2) Show user current SBC codec quality. So user would know what was
chosen and what should expect. I was told that Windows's Toshiba
bluetooth stack has support for this indication.
3) In some cases SBC SNR bit allocation method can provide better
quality as SBC loudness method.
1) What to do with aptX? It is really useful for users to have it in
Linux & pulseaudio? Because it looks like that the only thing which it
has better is lower latency. But can pulseaudio on Linux system really
achieve it?

I don't think, not the level of latency necessary for speech and to
avoid lip sync issues, so that would leave aptX at the same category
as SBC.

Post by Pali Rohár
2) Should we rather look at increasing quality of SBC codec in
pulseaudio? And if yes, how should be quality of SBC configured? Via
profiles? Or to invent some new protocol options? Can we increase
default SBC bitpool allocation?

I recall setting it to 64 before, but perhaps we are using 53 given
that most headset set that as maximum influenced by the spec suggested
values, I wouldn't go above 512kbit/s since then leave very little
room for any other traffic.

Post by Pali Rohár
3) If aptX is decided as useless, what about aptX HD codec? aptX HD
codec is supported by less products (currently I do not own any), but
this one may provide better quality as SBC according to that research.

That is probably useful as something that provides a quality
improvement compared to SBC.

Post by Pali Rohár
PS: That aptX research is the first and the only one about which I know.
All other information about quality or other details which I found on
internet are just marking informations.

I had some suspicion before given that no manufacturer provided any
evidence aptX would beat SBC at the same bitrate, it is probably
better just because we are stuck at 53 bitpool with SBC while aptX can
probably have much higher bitrate. Anyway thanks to the researcher for
putting the time to evaluate the codecs we now have a good reference
for the quality each codec provides.

Post by Pali Rohár
--
Pali Rohár
_______________________________________________
pulseaudio-discuss mailing list
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[Tanu Kaskinen]

Post by Luiz Augusto von Dentz
Hi Pali,

Post by Pali Rohár
Hello!
I would like to let you know that Serge from soundexpert.org did in last
month some research on aptX and its quality. Detailed article is on the
http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
============
slightly lower algorithmic delay of aptX both SBC and aptX codecs
provide the same 100-150ms latency in real-life BT applications.
If you hear the difference between SBC and aptX in some BT product,
there can be only two explanations - placebo effect or using SBC in
Middle or Low Quality modes.
AptX is just a copper-less overpriced audio cable.
aptX HD is high-bitrate version of aptX. It has clearly noticeable
increase in sound quality (not dramatic though taking into account the
increase in bitrate)
============
And it just confirms my own testing. Whatever I did I was not able to
either hear or see difference between aptX and SBC encoded-->decoded
audio.
I had discussion with Serge and there are some ideas which Linux
1) Allow user to specify SBC codec quality. In most cases, including
pulseaudio, SBC quality is chosen either to middle or low, not to
maximum bitpool. In some cases SBC at high quality can provide better
quality as aptX and more important -- SBC is supported by all headsets.
2) Show user current SBC codec quality. So user would know what was
chosen and what should expect. I was told that Windows's Toshiba
bluetooth stack has support for this indication.
3) In some cases SBC SNR bit allocation method can provide better
quality as SBC loudness method.
1) What to do with aptX? It is really useful for users to have it in
Linux & pulseaudio? Because it looks like that the only thing which it
has better is lower latency. But can pulseaudio on Linux system really
achieve it?

I don't think, not the level of latency necessary for speech and to
avoid lip sync issues, so that would leave aptX at the same category
as SBC.

How likely is it that a device that supports aptX only supports lower
SBC bitrates? In such situation aptX would apparently be an
improvement, but maybe that doesn't happen in real life.

Post by Luiz Augusto von Dentz

Post by Pali Rohár
2) Should we rather look at increasing quality of SBC codec in
pulseaudio? And if yes, how should be quality of SBC configured? Via
profiles? Or to invent some new protocol options? Can we increase
default SBC bitpool allocation?

I recall setting it to 64 before, but perhaps we are using 53 given
that most headset set that as maximum influenced by the spec suggested
values, I wouldn't go above 512kbit/s since then leave very little
room for any other traffic.

It seems that PulseAudio advertises 64 as the max bitpool it supports,
but when negotiating the parameters, the a2dp_default_bitpool()
function chooses at most 53. There's a comment in that function saying
that the values are chosen as recommended by the A2DP spec. What would
be the downside of choosing 64 instead of 53? Is 64 the absolute
maximum that can be used?

How is the bitrate calculated? I'd like to write a section on the
Bluetooth wiki page[1] that explains the SBC codec with a table showing
how the different parameters affect the bitrate.

[1] https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/

[Pali Rohár]

Post by Tanu Kaskinen

Post by Luiz Augusto von Dentz

Post by Pali Rohár
1) What to do with aptX? It is really useful for users to have it in
Linux & pulseaudio? Because it looks like that the only thing which it
has better is lower latency. But can pulseaudio on Linux system really
achieve it?

I don't think, not the level of latency necessary for speech and to
avoid lip sync issues, so that would leave aptX at the same category
as SBC.

How likely is it that a device that supports aptX only supports lower
SBC bitrates? In such situation aptX would apparently be an
improvement, but maybe that doesn't happen in real life.

Such combination does not make sense for me. I do not see reason why
headset would support only low SBC mode which is either due to slow
bluetooth stack or slow DSP and also aptX at higher bitrate...

I have not heard about such hardware.

[Luiz Augusto von Dentz]

Hi Pali,

Post by Pali Rohár

Post by Tanu Kaskinen

Post by Luiz Augusto von Dentz

Post by Pali Rohár
1) What to do with aptX? It is really useful for users to have it in
Linux & pulseaudio? Because it looks like that the only thing which it
has better is lower latency. But can pulseaudio on Linux system really
achieve it?

I don't think, not the level of latency necessary for speech and to
avoid lip sync issues, so that would leave aptX at the same category
as SBC.

How likely is it that a device that supports aptX only supports lower
SBC bitrates? In such situation aptX would apparently be an
improvement, but maybe that doesn't happen in real life.

Such combination does not make sense for me. I do not see reason why
headset would support only low SBC mode which is either due to slow
bluetooth stack or slow DSP and also aptX at higher bitrate...
I have not heard about such hardware.

We should probably check, perhaps some manufacturers are favoring aptX
believing the OSes don't support bitpool past 53, which is exactly the
situation with PA.

[Luiz Augusto von Dentz]

Hi Tanu,

Post by Tanu Kaskinen

Post by Luiz Augusto von Dentz
Hi Pali,

Post by Pali Rohár
Hello!
I would like to let you know that Serge from soundexpert.org did in last
month some research on aptX and its quality. Detailed article is on the
http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
============
slightly lower algorithmic delay of aptX both SBC and aptX codecs
provide the same 100-150ms latency in real-life BT applications.
If you hear the difference between SBC and aptX in some BT product,
there can be only two explanations - placebo effect or using SBC in
Middle or Low Quality modes.
AptX is just a copper-less overpriced audio cable.
aptX HD is high-bitrate version of aptX. It has clearly noticeable
increase in sound quality (not dramatic though taking into account the
increase in bitrate)
============
And it just confirms my own testing. Whatever I did I was not able to
either hear or see difference between aptX and SBC encoded-->decoded
audio.
I had discussion with Serge and there are some ideas which Linux
1) Allow user to specify SBC codec quality. In most cases, including
pulseaudio, SBC quality is chosen either to middle or low, not to
maximum bitpool. In some cases SBC at high quality can provide better
quality as aptX and more important -- SBC is supported by all headsets.
2) Show user current SBC codec quality. So user would know what was
chosen and what should expect. I was told that Windows's Toshiba
bluetooth stack has support for this indication.
3) In some cases SBC SNR bit allocation method can provide better
quality as SBC loudness method.
1) What to do with aptX? It is really useful for users to have it in
Linux & pulseaudio? Because it looks like that the only thing which it
has better is lower latency. But can pulseaudio on Linux system really
achieve it?

I don't think, not the level of latency necessary for speech and to
avoid lip sync issues, so that would leave aptX at the same category
as SBC.

How likely is it that a device that supports aptX only supports lower
SBC bitrates? In such situation aptX would apparently be an
improvement, but maybe that doesn't happen in real life.

Post by Luiz Augusto von Dentz

Post by Pali Rohár
2) Should we rather look at increasing quality of SBC codec in
pulseaudio? And if yes, how should be quality of SBC configured? Via
profiles? Or to invent some new protocol options? Can we increase
default SBC bitpool allocation?

I recall setting it to 64 before, but perhaps we are using 53 given
that most headset set that as maximum influenced by the spec suggested
values, I wouldn't go above 512kbit/s since then leave very little
room for any other traffic.

It seems that PulseAudio advertises 64 as the max bitpool it supports,
but when negotiating the parameters, the a2dp_default_bitpool()
function chooses at most 53. There's a comment in that function saying
that the values are chosen as recommended by the A2DP spec. What would
be the downside of choosing 64 instead of 53? Is 64 the absolute
maximum that can be used?

It influences the bitrate see:

http://soundexpert.org/news/-/blogs/bluetooth-audio-quality-a2dp

I recall 64 was kind acceptable since some headset do support it,
going past that probably don't make much sense if we don't have
headset supporting it. Note that we can reduce the bitpool on the fly.

Post by Tanu Kaskinen
How is the bitrate calculated? I'd like to write a section on the
Bluetooth wiki page[1] that explains the SBC codec with a table showing
how the different parameters affect the bitrate.
[1] https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/
--
Tanu
https://www.patreon.com/tanuk
https://liberapay.com/tanuk
_______________________________________________
pulseaudio-discuss mailing list
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[ValdikSS]

Post by Tanu Kaskinen
How is the bitrate calculated? I'd like to write a section on the
Bluetooth wiki page[1] that explains the SBC codec with a table showing
how the different parameters affect the bitrate.
[1] https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/

Bitrate formula could be found in A2DP specification:
https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=303201
Page 70.

Here's a convenient calculator:
https://btcodecs.valdikss.org.ru/sbc-bitrate-calculator/

[Tanu Kaskinen]

Post by ValdikSS

Post by Tanu Kaskinen
How is the bitrate calculated? I'd like to write a section on the
Bluetooth wiki page[1] that explains the SBC codec with a table showing
how the different parameters affect the bitrate.
[1] https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/

https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=303201
Page 70.
https://btcodecs.valdikss.org.ru/sbc-bitrate-calculator/

Thanks for the links! The calculator is great!

[Pali Rohár]

Post by Luiz Augusto von Dentz
Hi Pali,

Post by Pali Rohár
Hello!
I would like to let you know that Serge from soundexpert.org did in last
month some research on aptX and its quality. Detailed article is on the
http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
============
slightly lower algorithmic delay of aptX both SBC and aptX codecs
provide the same 100-150ms latency in real-life BT applications.
If you hear the difference between SBC and aptX in some BT product,
there can be only two explanations - placebo effect or using SBC in
Middle or Low Quality modes.
AptX is just a copper-less overpriced audio cable.
aptX HD is high-bitrate version of aptX. It has clearly noticeable
increase in sound quality (not dramatic though taking into account the
increase in bitrate)
============
And it just confirms my own testing. Whatever I did I was not able to
either hear or see difference between aptX and SBC encoded-->decoded
audio.
I had discussion with Serge and there are some ideas which Linux
1) Allow user to specify SBC codec quality. In most cases, including
pulseaudio, SBC quality is chosen either to middle or low, not to
maximum bitpool. In some cases SBC at high quality can provide better
quality as aptX and more important -- SBC is supported by all headsets.
2) Show user current SBC codec quality. So user would know what was
chosen and what should expect. I was told that Windows's Toshiba
bluetooth stack has support for this indication.
3) In some cases SBC SNR bit allocation method can provide better
quality as SBC loudness method.
1) What to do with aptX? It is really useful for users to have it in
Linux & pulseaudio? Because it looks like that the only thing which it
has better is lower latency. But can pulseaudio on Linux system really
achieve it?

I don't think, not the level of latency necessary for speech and to
avoid lip sync issues, so that would leave aptX at the same category
as SBC.

That is what I thought. So seems that aptX (non-HD) has no benefit over
SBC in pulseaudio.

Post by Luiz Augusto von Dentz

Post by Pali Rohár
2) Should we rather look at increasing quality of SBC codec in
pulseaudio? And if yes, how should be quality of SBC configured? Via
profiles? Or to invent some new protocol options? Can we increase
default SBC bitpool allocation?

I recall setting it to 64 before, but perhaps we are using 53 given
that most headset set that as maximum influenced by the spec suggested
values, I wouldn't go above 512kbit/s since then leave very little
room for any other traffic.

So... seems that maximum value is 53:
https://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/bluetooth/bluez5-util.c#n1599
https://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/bluetooth/bluez5-util.c#n1260

Even when headset advertise higher value. Should not we increase when
headset support higher value?

Also question about allocation method SNR vs loudness. Default is
loudness.

Post by Luiz Augusto von Dentz

Post by Pali Rohár
3) If aptX is decided as useless, what about aptX HD codec? aptX HD
codec is supported by less products (currently I do not own any), but
this one may provide better quality as SBC according to that research.

That is probably useful as something that provides a quality
improvement compared to SBC.

Ok, I would let this part to other people as currently I do not have
aptX HD native hardware.

Post by Luiz Augusto von Dentz

Post by Pali Rohár
PS: That aptX research is the first and the only one about which I know.
All other information about quality or other details which I found on
internet are just marking informations.

I had some suspicion before given that no manufacturer provided any
evidence aptX would beat SBC at the same bitrate, it is probably
better just because we are stuck at 53 bitpool with SBC while aptX can
probably have much higher bitrate. Anyway thanks to the researcher for
putting the time to evaluate the codecs we now have a good reference
for the quality each codec provides.

[ValdikSS]

Post by Luiz Augusto von Dentz

Post by Pali Rohár
2) Should we rather look at increasing quality of SBC codec in
pulseaudio? And if yes, how should be quality of SBC configured? Via
profiles? Or to invent some new protocol options? Can we increase
default SBC bitpool allocation?

I recall setting it to 64 before, but perhaps we are using 53 given
that most headset set that as maximum influenced by the spec suggested
values, I wouldn't go above 512kbit/s since then leave very little
room for any other traffic.

I propose to use 76 bitpool as a default maximum (454.8 kbps for Joint Stereo, 44.1 kHz, 8 subbands, 16 blocks). This bitpool is optimal for both EDR 2 mbit/s and EDR 3 mbit/s modes, since it packs audio frames with least wasted bytes possible.
EDR 2 mbit/s: up to 4 audio frames, 11.7 ms, 2 wasted bytes
EDR 3 mbit/s: up to 6 audio frames, 17.5 ms, 14 wasted bytes.

Note that Pulseaudio/bluez (not sure which) does not manage L2CAP MTU correctly. For EDR 2 mbit/s, MTU should be set to 679 (ignoring higher values upon negotiation), and EDR 3 mbit/s should use 1021 (right now something like 800 is used).

Post by Luiz Augusto von Dentz

Post by Pali Rohár
3) If aptX is decided as useless, what about aptX HD codec? aptX HD
codec is supported by less products (currently I do not own any), but
this one may provide better quality as SBC according to that research.

That is probably useful as something that provides a quality
improvement compared to SBC.

Post by Pali Rohár
PS: That aptX research is the first and the only one about which I know.
All other information about quality or other details which I found on
internet are just marking informations.

I had some suspicion before given that no manufacturer provided any
evidence aptX would beat SBC at the same bitrate, it is probably
better just because we are stuck at 53 bitpool with SBC while aptX can
probably have much higher bitrate. Anyway thanks to the researcher for
putting the time to evaluate the codecs we now have a good reference
for the quality each codec provides.

Post by Pali Rohár
--
Pali Rohár
_______________________________________________
pulseaudio-discuss mailing list
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[Luiz Augusto von Dentz]

Hi Valdik

Post by ValdikSS

Post by Luiz Augusto von Dentz

Post by Pali Rohár
2) Should we rather look at increasing quality of SBC codec in
pulseaudio? And if yes, how should be quality of SBC configured? Via
profiles? Or to invent some new protocol options? Can we increase
default SBC bitpool allocation?

I recall setting it to 64 before, but perhaps we are using 53 given
that most headset set that as maximum influenced by the spec suggested
values, I wouldn't go above 512kbit/s since then leave very little
room for any other traffic.

I propose to use 76 bitpool as a default maximum (454.8 kbps for Joint Stereo, 44.1 kHz, 8 subbands, 16 blocks). This bitpool is optimal for both EDR 2 mbit/s and EDR 3 mbit/s modes, since it packs audio frames with least wasted bytes possible.
EDR 2 mbit/s: up to 4 audio frames, 11.7 ms, 2 wasted bytes
EDR 3 mbit/s: up to 6 audio frames, 17.5 ms, 14 wasted bytes.

That is a bit too hight I would say, and not sure if there would be
any headset to make use of it.

Post by ValdikSS
Note that Pulseaudio/bluez (not sure which) does not manage L2CAP MTU correctly. For EDR 2 mbit/s, MTU should be set to 679 (ignoring higher values upon negotiation), and EDR 3 mbit/s should use 1021 (right now something like 800 is used).

We could do that if we know the packet type used by the link but that
is not how it is currently done in BlueZ, we always use L2CAP default
in case the socket don't set it:

https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/include/net/bluetooth/l2cap.h#n34

Where did you get these values from btw?

Post by ValdikSS

Post by Luiz Augusto von Dentz

Post by Pali Rohár
3) If aptX is decided as useless, what about aptX HD codec? aptX HD
codec is supported by less products (currently I do not own any), but
this one may provide better quality as SBC according to that research.

That is probably useful as something that provides a quality
improvement compared to SBC.

Post by Pali Rohár
PS: That aptX research is the first and the only one about which I know.
All other information about quality or other details which I found on
internet are just marking informations.

I had some suspicion before given that no manufacturer provided any
evidence aptX would beat SBC at the same bitrate, it is probably
better just because we are stuck at 53 bitpool with SBC while aptX can
probably have much higher bitrate. Anyway thanks to the researcher for
putting the time to evaluate the codecs we now have a good reference
for the quality each codec provides.

Post by Pali Rohár
--
Pali Rohár
_______________________________________________
pulseaudio-discuss mailing list
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[ValdikSS]

Post by Luiz Augusto von Dentz

Post by ValdikSS
I propose to use 76 bitpool as a default maximum (454.8 kbps for Joint Stereo, 44.1 kHz, 8 subbands, 16 blocks). This bitpool is optimal for both EDR 2 mbit/s and EDR 3 mbit/s modes, since it packs audio frames with least wasted bytes possible.
EDR 2 mbit/s: up to 4 audio frames, 11.7 ms, 2 wasted bytes
EDR 3 mbit/s: up to 6 audio frames, 17.5 ms, 14 wasted bytes.

That is a bit too hight I would say, and not sure if there would be
any headset to make use of it.

This bitrate utilizes 2-DH5 and 3-DH5 packet types (the most common ones for audio streaming) as optimally as possible.

2-DH5 maximum payload size is 679 bytes. With bitpool 64, you can fill the packet with 4 audio frames (11.7 ms), which will take 564 bytes, and 98 bytes are wasted (679 - 12 L2CAP header - 4 RTP header - 1 SBC header). With bitpool 76, you can fill the packet with the same 4 audio frames and 11.7 ms audio, but it will take 660 bytes, and only 2 bytes are wasted.

Bluetooth uses TDMA and transfers DH5 packets in 3.75 ms. You won't get higher packet rate or higher reliability if you send packets with less data than the packet can possible contain.

There are some headsets with higher or unlimited bitpool value:

Beats Solo³: bitpool 2..250
AirPods: bitpool 2..250
JBL Everest Elite 750NC: bitpool 10..80

Post by Luiz Augusto von Dentz

Post by ValdikSS
Note that Pulseaudio/bluez (not sure which) does not manage L2CAP MTU correctly. For EDR 2 mbit/s, MTU should be set to 679 (ignoring higher values upon negotiation), and EDR 3 mbit/s should use 1021 (right now something like 800 is used).

We could do that if we know the packet type used by the link but that
is not how it is currently done in BlueZ, we always use L2CAP default
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/include/net/bluetooth/l2cap.h#n34
Where did you get these values from btw?

These are max payload sizes for 2-DH5 and 3-DH5
http://www.osted.dk/bluetooth/bt_transfer_rate.html
It's reasonable to use these values as an MTU to prevent packet fragmentation on a lower levels.
Android does that.

[ValdikSS]

Post by Pali Rohár
Hello!
I would like to let you know that Serge from soundexpert.org did in last
month some research on aptX and its quality. Detailed article is on the
http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
============
slightly lower algorithmic delay of aptX both SBC and aptX codecs
provide the same 100-150ms latency in real-life BT applications.
If you hear the difference between SBC and aptX in some BT product,
there can be only two explanations - placebo effect or using SBC in
Middle or Low Quality modes.

This is not exactly true. I believe Sergey's tests are not suited well for ADPCM codecs, since almost all modern phycho acoustic lossy codecs are trying to hide unhearable details while ADPCM works differently.
So I'm not sure if ADPCM (aptX) and SBC codecs should be compared with the waveforms, as SBC will introduce less distortion in most cases but aptX may be better for the ears, especially for the people who complain for the lack of high frequencies using SBC. For me, it's almost the same, but 2 of my friends differs aptX from SBC (Joint Stereo, 328 kbit/s) 100% of the time on certain due to lack of high frequencies. I personally can't hear more than 16.5 kHz, so I pitch-shift encoded audio down to hearable frequency to hear what my friends can hear.
SBC can provide better results than aptX. On average, compared to SBC 328k, aptX makes less distortion in music with a wide frequency range, but on music with a narrow frequency range and a wide dynamic range SBC 328k sometimes wins.

Post by Pali Rohár
Yes, in general case assessment of sound quality by comparing waveforms is a bad practice. In my research I contend that this could be done only in some special cases. When sound signatures (which are, in fact, artifact signatures) are close. Analysis of the codecs similarity showed that in this case sound quality can be judged by the level of the initial waveform distortion (provided that sufficient amount of music material is used). The criteria of similarity was taken from my earlier research which is still in progress. I don't know, whether there is some fundamental flaw in my approach or it is just a natural accuracy of the method (1.5dB is relatively small value of difference). Anyway, that are the results as they are, you may consider them with a grain of salt.

Here are my simple tests:
https://forum.xda-developers.com/showpost.php?p=77408975&postcount=4
While they are also not great, I thought it's sane to compare encoding results with spectrograms of ADPCM/APCM codecs.
I tried to use EAQUAL software to compare SBC and aptX. Some results are very relevant (Noise-To-Mask-Ratio, Relative Disturbed Frames, various differences) but some are controversial (Objective Difference Grade).

Please also read other information in this link. I made a patch for Android LineageOS for Dual Channel support, and thinking on adding this functionality to Pulseaudio.
https://review.lineageos.org/#/c/LineageOS/android_system_bt/+/228548/

Post by Pali Rohár
AptX is just a copper-less overpriced audio cable.

aptX and aptX HD have a strictly defined profiles which could not be changed without encoder and decoder modifications. Neither headphone manufacturer nor Bluetooth stack manufacturer can change them. This is a strong side of the codec, you always know what audio quality you will get with them, no buts.
With SBC you don't know what audio quality you will get before trying. SBC can produce very low quality audio to very high quality audio (on par or better than aptX HD), but you'll almost never get very high quality audio without disabling or circumventing artificial limitations.

Post by Pali Rohár
aptX HD is high-bitrate version of aptX. It has clearly noticeable
increase in sound quality (not dramatic though taking into account the
increase in bitrate)
============
And it just confirms my own testing. Whatever I did I was not able to
either hear or see difference between aptX and SBC encoded-->decoded
audio.
I had discussion with Serge and there are some ideas which Linux
1) Allow user to specify SBC codec quality. In most cases, including
pulseaudio, SBC quality is chosen either to middle or low, not to
maximum bitpool. In some cases SBC at high quality can provide better
quality as aptX and more important -- SBC is supported by all headsets.
2) Show user current SBC codec quality. So user would know what was
chosen and what should expect. I was told that Windows's Toshiba
bluetooth stack has support for this indication.
3) In some cases SBC SNR bit allocation method can provide better
quality as SBC loudness method.

I don't know why SNR method shows better results in Sergey's tests, but it's just not true in the real life.
Loudness is a "simple psycho acoustic model", while SNR mode is "no phycho acoustic model". SNR just uses maximum subband sample as a scalefactor, which then assigned for the "needed bits" variable of that subband.
Loudness uses coefficients for different subbands, so most hearable subbands get more bits and less hearable less bits, that's what they call "simple phycho acoustic".

Try to make test encodes for SNR and Loudness with medium bitrate, you'll hear cracklings on mid and high frequencies, and less audio quality in high frequencies. Loudness would be much better in this case.

Post by Pali Rohár
1) What to do with aptX? It is really useful for users to have it in
Linux & pulseaudio? Because it looks like that the only thing which it
has better is lower latency. But can pulseaudio on Linux system really
achieve it?

aptX is still useful. Some (at least my) headphones have additional signal processing for SBC, while nothing for aptX. For some reason, the headphones enable some kind of compressor + limiter for SBC, and audio is very compressed unless you decrease audio volume down to 2/3.
aptX sounds fine will full volume. And don't forget that aptX has strictly defined profiles.

Post by Pali Rohár
2) Should we rather look at increasing quality of SBC codec in
pulseaudio? And if yes, how should be quality of SBC configured? Via
profiles? Or to invent some new protocol options? Can we increase
default SBC bitpool allocation?
3) If aptX is decided as useless, what about aptX HD codec? aptX HD
codec is supported by less products (currently I do not own any), but
this one may provide better quality as SBC according to that research.
PS: That aptX research is the first and the only one about which I know.
All other information about quality or other details which I found on
internet are just marking informations.>

[Arun Raghavan]

Post by Pali Rohár
Hello!
I would like to let you know that Serge from soundexpert.org did in last
month some research on aptX and its quality. Detailed article is on the
http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
============
slightly lower algorithmic delay of aptX both SBC and aptX codecs
provide the same 100-150ms latency in real-life BT applications.
If you hear the difference between SBC and aptX in some BT product,
there can be only two explanations - placebo effect or using SBC in
Middle or Low Quality modes.
AptX is just a copper-less overpriced audio cable.
aptX HD is high-bitrate version of aptX. It has clearly noticeable
increase in sound quality (not dramatic though taking into account the
increase in bitrate)
============
And it just confirms my own testing. Whatever I did I was not able to
either hear or see difference between aptX and SBC encoded-->decoded
audio.
I had discussion with Serge and there are some ideas which Linux
1) Allow user to specify SBC codec quality. In most cases, including
pulseaudio, SBC quality is chosen either to middle or low, not to
maximum bitpool. In some cases SBC at high quality can provide better
quality as aptX and more important -- SBC is supported by all headsets.
2) Show user current SBC codec quality. So user would know what was
chosen and what should expect. I was told that Windows's Toshiba
bluetooth stack has support for this indication.
3) In some cases SBC SNR bit allocation method can provide better
quality as SBC loudness method.

Thanks for sharing, this is very interesting.

Post by Pali Rohár
1) What to do with aptX? It is really useful for users to have it in
Linux & pulseaudio? Because it looks like that the only thing which it
has better is lower latency. But can pulseaudio on Linux system really
achieve it?

What would prevent us from doing so?

Post by Pali Rohár
2) Should we rather look at increasing quality of SBC codec in
pulseaudio? And if yes, how should be quality of SBC configured? Via
profiles? Or to invent some new protocol options? Can we increase
default SBC bitpool allocation?

My preference is to not expose things to the user but try to move towards

Post by Pali Rohár
3) If aptX is decided as useless, what about aptX HD codec? aptX HD
codec is supported by less products (currently I do not own any), but
this one may provide better quality as SBC according to that research.

Right, could still be worth it indeed.

Post by Pali Rohár
PS: That aptX research is the first and the only one about which I know.
All other information about quality or other details which I found on
internet are just marking informations.

In general, it seems the work to support other codecs could still be valuable for AAC and maybe in the future, LDAC? Is anyone aware of a similar comparison for the either of these codecs?

AAC is still interesting for passthrough media, of course (I hope to have more on the ability to support that in coming weeks/months). Any objective information on LDAC would be interesting too.

Cheers,
Arun

[Luiz Augusto von Dentz]

Hi Arun,

Post by Arun Raghavan

Post by Pali Rohár
Hello!
I would like to let you know that Serge from soundexpert.org did in last
month some research on aptX and its quality. Detailed article is on the
http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx
============
slightly lower algorithmic delay of aptX both SBC and aptX codecs
provide the same 100-150ms latency in real-life BT applications.
If you hear the difference between SBC and aptX in some BT product,
there can be only two explanations - placebo effect or using SBC in
Middle or Low Quality modes.
AptX is just a copper-less overpriced audio cable.
aptX HD is high-bitrate version of aptX. It has clearly noticeable
increase in sound quality (not dramatic though taking into account the
increase in bitrate)
============
And it just confirms my own testing. Whatever I did I was not able to
either hear or see difference between aptX and SBC encoded-->decoded
audio.
I had discussion with Serge and there are some ideas which Linux
1) Allow user to specify SBC codec quality. In most cases, including
pulseaudio, SBC quality is chosen either to middle or low, not to
maximum bitpool. In some cases SBC at high quality can provide better
quality as aptX and more important -- SBC is supported by all headsets.
2) Show user current SBC codec quality. So user would know what was
chosen and what should expect. I was told that Windows's Toshiba
bluetooth stack has support for this indication.
3) In some cases SBC SNR bit allocation method can provide better
quality as SBC loudness method.

Thanks for sharing, this is very interesting.

Post by Pali Rohár
1) What to do with aptX? It is really useful for users to have it in
Linux & pulseaudio? Because it looks like that the only thing which it
has better is lower latency. But can pulseaudio on Linux system really
achieve it?

What would prevent us from doing so?

Post by Pali Rohár
2) Should we rather look at increasing quality of SBC codec in
pulseaudio? And if yes, how should be quality of SBC configured? Via
profiles? Or to invent some new protocol options? Can we increase
default SBC bitpool allocation?

My preference is to not expose things to the user but try to move towards

Post by Pali Rohár
3) If aptX is decided as useless, what about aptX HD codec? aptX HD
codec is supported by less products (currently I do not own any), but
this one may provide better quality as SBC according to that research.

Right, could still be worth it indeed.

Post by Pali Rohár
PS: That aptX research is the first and the only one about which I know.
All other information about quality or other details which I found on
internet are just marking informations.

In general, it seems the work to support other codecs could still be valuable for AAC and maybe in the future, LDAC? Is anyone aware of a similar comparison for the either of these codecs?
AAC is still interesting for passthrough media, of course (I hope to have more on the ability to support that in coming weeks/months). Any objective information on LDAC would be interesting too.

Afaik Android supports LDAC so at least for headset/carkits using PA
that would be a good addition, though it requires even higher bitrate:

https://www.androidauthority.com/sony-ldac-codec-790690/