29 responses to “Better Bluetooth sound quality on Linux”

1. PulseAudio Plugin Allows For Better Bluetooth Audio Quality On Linux – Dunia IT

   February 11, 2019

   […] Eischmann of Red Hat wrote a blog post about this find where he commented, “I don’t have bat ears, but I could recognize a […]

   Reply
2. 

   ocrete

   February 12, 2019

   HE-AAC is a strict superset of the old AAC, so it should be fine to send the older version to the headsets.

   Reply
   1. 

      sesivany

      February 12, 2019

      I didn’t really dig too deep into this, but from what I’ve heard and read the AAC codec in Fedora doesn’t support all profiles which has impact on quality of streams, so not really very suitable here.

      Reply
3. Better #Bluetooth sound quality on #Linux https://eischmann.wordpre… | Dr. Roy Schestowitz (罗伊)

   February 12, 2019

   […] Better #Bluetooth sound quality on #Linux https://eischmann.wordpress.com/2019/02/11/better-bluetooth-sound-quality-on-linux/ […]

   Reply
4. 

   Pali

   February 12, 2019

   Just to note that there are two independent attempts to extend pulseaudio bluetooth codecs. One is that EHfive’s attempt described in this article which seems to be some personal fork of pulseaudio without large communication with pulseaudio developers. And another one is mine. I have started working on extra A2DP codecs support in summer 2018 and publically on pulseaudio mailing list. Originally WIP patch for aptX codec https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030198.html involved after review to the last V6 version https://lists.freedesktop.org/archives/pulseaudio-discuss/2019-February/030849.html which implements modular API for defining new pulseaudio bluetooth codecs and support for aptX, aptX HD, SBC ultra high quality and FastStream codecs. There are still some technical issues which needs to be resolved, but patches are ready to use. As EHfive was not discussed on list too deeply, I guess that those patches are not going to be included into upstream pulseaudio… It is pity that somebody is doing on some fork of pulseaudio without cooperation with other developers… But at least I’m planning to finish and resolve all issues in my attempt to have better API for new bluetooth codecs. About LDAC in pulseaudio, there is open question about licensing. LGPLv2 is not compatible with Apache License under which is LDAC encoder released. Until this issue is resolved I guess that LDAC codec support would not appear in distributed version of pulseaudio.

   Reply
   1. 

      sesivany

      February 12, 2019

      Thank you for valuable information, Pali! I’m glad to hear that you’re taking the time to upstream your work. Even if AptX and LDAC codecs can’t be part of PA, I think having SBC ultra high quality will help greatly.

      Reply
      1. 

         Pali

         February 12, 2019

         I guess that aptX and aptX HD would not be a problem as libopenaptx is licensed under LGPLv2.1. At least nobody complained about it yet.

         LDAC is a bit problematic but my understanding is that GPLv2+ and LGPLv2+ code can be (optionally) upgraded to GPLv3 and Apache License, under which is LDAC, is compatible with GPLv3. I’m not lawyer but maybe some build option “–compile-as-gplv3” could generate GPLv3 binary of pulseaudio and then it could use LDAC encoder.

         But SBC in High Quality (“High Quality” is a term defined in A2DP spec and has fixed params) has same quality as aptX. “Ultra High Quality” is just name which I used for SBC bitpool values above well-defined “High Quality”. Bitrate of SBC in Ultra High Quality is higher then bitrate of aptX and should be supported by most of headset. But I’m not sure if somebody would hear a difference…

         About aptX I suggest to read research result at http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx (jump to updated “August 2018” section). On internet are lot of marketing information about aptX but almost no serious research.

         Important parts from that research:
         “AptX is just a copperless overpriced audio cable.”
         “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.”

         And it matches my testing, whatever I did I was not able to hear difference between aptX and SBC.

         Anyway, it would be great if legal team of some linux distributions investigate situation about AAC or LDAC libraries and possible usage by pulseaudio. Do you know if Red Hat legal team would be willing to look at it?

         Reply
         1. 

            gombosg89

            March 20, 2019

            Thanks for your hard work, Pali. I hope your patches get into upstream this year.

            I already packaged libldac for Fedora and it was fine. But I know it’s not compatible with Pulseaudio license.

            I have also submitted pulseaudio-modules-bt to RPMFusion (https://bugzilla.rpmfusion.org/show_bug.cgi?id=5155) but they are reluctant to approve it partly because of the licensing mess and partly because it replaces a Fedora package. (Both would be true for your patches, too :))

            All this license mess is very bad, this is how I see it currently: https://github.com/EHfive/pulseaudio-modules-bt/issues/20#issuecomment-474910894

            Ps. I do this whole thing because I do hear a difference on my Sennheiser HD4.50 BTNC headset when using aptX. Of course, A/B testing would be needed to get real results. 😀

            Reply
            1. 

               Pali

               March 20, 2019

               Are you able to hear difference between “SBC Ultra High Quality” and “aptX” (non HD variant)?

            2. 

               gombosg89

               March 20, 2019

               Hi Pali, AFAIK my headset only supports non-HD SBC and non-HD aptX. With SBC the highest frequencies (vocal hissing, cymbals etc.) became distorted and it was a nuisance. This could improve though later.

               The best is wired mode though. 🙂

               Update: RPMFusion effectively denied adding the package due to dependency on FDK-AAC. Licensing can become really messy…

            3. 

               Pali

               March 20, 2019

               “SBC Ultra High Quality” should be supported by almost all headsets (via dual-channel mode instead of joint-stereo). And it is implemented in my last version of pulseaudio patches. UH uses larger bitpool values so also higher frequences should be improved.

            4. 

               eischmann

               March 21, 2019

               Pali, I suppose the patches are in master, not in the latest stable release (12.2), right? Because SBC still sounds pretty bad with PA 12.2.
               BTW we’re going to move to PipeWire for sound server in the future. For apps it will be a drop-in replacement for PA, but internally all this will have to be reimplemented. Fortunately there we can still do something with the license.

            5. 

               Pali

               March 21, 2019

               > I suppose the patches are in master, not in the latest stable release (12.2), right?

               Patches are on mailing list, not merged nor reviewed yet.

               > we’re going to move to PipeWire for sound server in the future. … internally all this will have to be reimplemented.

               So you are dropping bluetooth support? 😀 Or is somebody already working on reimplementation of whole bluetooth patches, including those on which I have been working for more months? If not just do not expect anything useful… This is really not something trivial.

            6. 

               eischmann

               March 21, 2019

               It’s a long-term goal, it makes sense to have a video and audio server together, moreover PipeWire is covering the JACK usecases as well. That’s what PA has never intended to do. But there is a lot of work to do before PipeWire can replace PA. Until then it will only be used as a video server.

         2. 

            eischmann

            March 21, 2019

            I think the strong part of AptX is not sound quality, but flexibility, bitrate scaling based on connection quality. Reportedly it does that better than LDAC. Also bitrate != sound quality, different codecs produce different sound quality at the same bittrate. I doubt that SBC would produce the same quality at the same bittrate as AptX. But I can believe that a difference between SBC High Quality and AptX is not noticable on most headphones.
            I’m not sure Red Hat legal would look into it, generally they rarely publish legal opinions or advisories.

            Reply
            1. 

               Pali

               March 21, 2019

               > I think the strong part of AptX is not sound quality, but flexibility, bitrate scaling based on connection quality.

               There is no flexibility, no bitrate scaling, nothing,… in aptX. It is 20 years old codec when these things was not largely used. All what you wrote is untruth. aptX codec does not relay on anything like connection quality. There is no such input either for QMF or for predictor. aptX has fixed bitrate which does not depend on anything. The only thing are synchronization bits injected into aptX stream to detect dropped packets. Where you get all those false information (source please)?

               > I doubt that SBC would produce the same quality at the same bittrate as AptX.

               According to tests it should produce. But SBC must not be in middle or low quality.

               Have you looked at some research about aptX? As there are lot of marketing bullshits about aptX on Internet and all those information looks like another marketing or PR manager campaign.

               Something interesting to read (look at August 2018 update):
               http://soundexpert.org/articles/-/blogs/audio-quality-of-bluetooth-aptx

            2. 

               eischmann

               March 21, 2019

               I read it in some LDAC vs AptX/AptX-HD test (I cannot find it any more), LDAC was way more often dropping to lower bitrates than AptX, but yeah, it’s not actually characteristic of the codec itself, but rather some logic around it, but I personally don’t really care much about AptX and don’t want to defend it.
               My headphones can do LDAC, that’s what I care about. Currently I can hear a clear difference between SBC and LDAC in PA 12.2. If SBC improves so much that the difference will be hardly noticable, I’ll be satisfied. Probably good enough for default.

   2. 

      sesivany

      February 12, 2019

      BTW is LGPLv2 necessarily incompatible with Apache License? Some interpretations say it is not. Or a project can grant an exception to the license by just relying on Apache License. There is a ton of LGPLv2 software that relies on Apache licensed libraries.

      Reply
      1. 

         Pali

         February 12, 2019

         Some people say incompatible, some compatible. So it is a problem. Project can grant an exception only if all copyright holders agree with it. And this is complicated, take lot of time and is with questionable result. I have experience with this “relicense” problem, in past I (successfully) got permission to relicense igmpproxy project from proprietary to BSD+GPLv2…

         Reply
         1. 

            sesivany

            February 12, 2019

            How is PulseAudio going to deal with other codecs such as AptX? I suppose they have implementation in ffmpeg which is under (L)GPL, but they’re protected by patents, so it’s not really safe to ship PA with them either.

            Reply
            1. 

               Pali

               February 12, 2019

               In my patch series, I’m using libopenaptx library (LGPL; https://github.com/pali/libopenaptx) which is just modified implementation from ffmpeg. IIRC, originally it was clean room implementation. Patented is not only aptX but also LDAC.

               But now I’m looking at aptX patent https://patents.google.com/patent/EP0398973B1/en and it seems to be already expired. So it is a real problem?

            2. 

               eischmann

               February 12, 2019

               If it’s the only patent protecting the codec, then it should be fine, but in my experience there are usually multiple patents around codecs. AptX is old enough, so maybe it’s really expired. But it would need a legal review (at least for Fedora). LDAC is also patented, but the Apache License has a patent grant clause, so it’s safe to use the libldac implementation.
               BTW I wonder if the license problem can’t be avoided by some plugin or wrapper solution.

5. LWDW 157: Dirty Snap – LinuxGameCast

   February 14, 2019

   […] Blueteeth LDAC (Rtheren) […]

   Reply
6. 

   Aleksandar Kostadinov

   August 2, 2019

   In pavucontrol I only see SBC, LDAC, aptX and aptX HD. But next to all but SBC I see (unavailable). Does it mean the device does not support it, or PulseAudio does not support it?

   Reply
   1. 

      gombosg89

      August 3, 2019

      Hi, HSP is the “headset” codec and SBC is the higher quality audio. The system would automatically choose aptX over SBC if the device supports it. You may only need to manually select HSP sometimes if you want to make calls.
      More info about codecs: https://github.com/EHfive/pulseaudio-modules-bt/wiki

      Reply
7. 

   Colin Walters

   August 2, 2019

   For anyone running Silverblue (rpm-ostree), the incantation to run after enabling the RPMFusion repos is:

   `rpm-ostree override remove pulseaudio-module-bluetooth –install pulseaudio-module-bluetooth-freeworld`

   Reply
   1. 

      gombosg89

      August 3, 2019

      Thanks! Tried it in a VM and it works. (With –install)
      I will get the wiki updated here: https://github.com/EHfive/pulseaudio-modules-bt/issues/68

      Reply
8. 

   Elbin

   August 13, 2020

   Does pulseaudio-module-bluetooth-freeworld from rpmfusion for fedora give the high bitrate SBC mode? How can I check what bitrate my headphone is receiving in. I don’t hear much difference in clarity between AAC and SBC, neither with Fedora, nor on Android.

   Reply
9. 

   Krisztian Szegi

   March 24, 2021

   Hi!

   I just wanted to mention something nobody seems to care here.
   It is already mentioned that SBC can provide quite high bitrates too (too lazy to look up the exaxt numbers), so streaming quality should be compareable – or even better – with other codecs. AptX by itself only has only better marketing (mostly). LineageOs and derivative android ROMs have a setting for defaulting to dual-channel on SBC, and that worked for me.

   The very big chunk of the picture that very few people talk about (and I could not find this topic in the comments) that your headset is the culprit!
   I hate those “premium” manufacturers – such as your headsets’ one – who artificially destroy SBC quality.
   Most headsets use different sound presets/equalizers for different codecs. If you hear a big difference, than you headset just wrecks the sound profile of SBC streams.
   That way you can force the user to buy the next great smartphone etc.: “look (I mean hear) how much better is the sound with this as the bluetooth source! You know, it because has LDAC support.”

   320 kbps spotify tracks shouldn’t need anything more than SBC, although if you want to predict the audio quality based on the codec and it’s bitrate you need to be versed in informational entropy and human hearing.
   Or you could just empirically measure the decoded stream (that hasn’t been crapped on it by the receptable’s “equalizer”):
   http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec

   I’d protest by never buying anything from that overpriced headset’s manufaturer if I were in your shoes.
   I think you could have better results with SBC and another headset, as unopinionated data strongly hints it.

   Please, don’t spread misinfos…

   Reply