Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On Friday 14 September 2018 15:28:55 ValdikSS wrote: > 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/ I think this "SBC HD" should be possible to implement via v3 model API patch series. Looks very promising for increasing bluetooth sound quality. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
Hi Arun, On Tue, Sep 18, 2018 at 9:02 PM, Arun Raghavan wrote: > On Wed, 12 Sep 2018, at 4:12 PM, Pali Rohár wrote: >> 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 SBC@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. > > Thanks for sharing, this is very interesting. > >> 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? > > What would prevent us from doing so? > >> 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 > >> 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. > >> 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/ -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On Wed, 12 Sep 2018, at 4:12 PM, Pali Rohár wrote: > 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 SBC@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. Thanks for sharing, this is very interesting. > 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? What would prevent us from doing so? > 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 > 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. > 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On Fri, 2018-09-14 at 15:43 +0300, ValdikSS wrote: > On 13/09/2018 11:23, Tanu Kaskinen wrote: > > > > 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/ Thanks for the links! The calculator is great! -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On 14/09/2018 16:42, Luiz Augusto von Dentz wrote: >> 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 > >> 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? 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. signature.asc Description: OpenPGP digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
Hi Valdik On Fri, Sep 14, 2018 at 3:39 PM, ValdikSS wrote: > On 12/09/2018 19:03, Luiz Augusto von Dentz wrote: >>> 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. > 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? >> >>> 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. >> >>> 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. >> >> >>> -- >>> Pali Rohár >>> pali.ro...@gmail.com >>> ___ >>> pulseaudio-discuss mailing list >>> pulseaudio-discuss@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss >> >> >> > > -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On 13/09/2018 11:23, Tanu Kaskinen wrote: > > 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/ signature.asc Description: OpenPGP digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On 12/09/2018 19:03, Luiz Augusto von Dentz wrote: >> 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). > >> 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. > >> 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. > > >> -- >> Pali Rohár >> pali.ro...@gmail.com >> ___ >> pulseaudio-discuss mailing list >> pulseaudio-discuss@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > signature.asc Description: OpenPGP digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On 12/09/2018 13:42, Pali Rohár wrote: > 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 SBC@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. 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. Here's Sergey's reply: > 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=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/ > > 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. > > 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. I don't know why SNR method shows
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
Hi Pali, On Thu, Sep 13, 2018 at 11:29 AM, Pali Rohár wrote: > On Thursday 13 September 2018 11:23:58 Tanu Kaskinen wrote: >> On Wed, 2018-09-12 at 19:03 +0300, Luiz Augusto von Dentz wrote: >> > On Wed, Sep 12, 2018 at 1:42 PM, Pali Rohár wrote: >> > > 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
Hi Tanu, On Thu, Sep 13, 2018 at 11:23 AM, Tanu Kaskinen wrote: > On Wed, 2018-09-12 at 19:03 +0300, Luiz Augusto von Dentz wrote: >> Hi Pali, >> >> On Wed, Sep 12, 2018 at 1:42 PM, Pali Rohár wrote: >> > 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 SBC@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? >> >> 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. > >> > 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. > 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 > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On Thursday 13 September 2018 11:23:58 Tanu Kaskinen wrote: > On Wed, 2018-09-12 at 19:03 +0300, Luiz Augusto von Dentz wrote: > > On Wed, Sep 12, 2018 at 1:42 PM, Pali Rohár wrote: > > > 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. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On Wednesday 12 September 2018 19:03:41 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Wed, Sep 12, 2018 at 1:42 PM, Pali Rohár wrote: > > 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 SBC@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? > > 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. > > 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. > > 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. > > 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. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
On Wed, 2018-09-12 at 19:03 +0300, Luiz Augusto von Dentz wrote: > Hi Pali, > > On Wed, Sep 12, 2018 at 1:42 PM, Pali Rohár wrote: > > 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 SBC@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? > > 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. > > 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/ -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth A2DP aptX codec quality
Hi Pali, On Wed, Sep 12, 2018 at 1:42 PM, Pali Rohár wrote: > 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 SBC@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? 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. > 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. > 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. > 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. > -- > Pali Rohár > pali.ro...@gmail.com > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
