Brno Hat

Jiri Eischmann's Blog

Better Bluetooth sound quality on Linux

,
, , , , , , ,

Over a year ago I got my first serious Bluetooth headphones. They worked with Fedora well, they paired, connected, sound was directed to them. Just the sound quality was not overwhelming. I learnt that because of limited bandwidth of Bluetooth a codec with audio compression has to be used. There are quite a few of them to pick from: AAC (very widely supported because it’s the only one iPhone supports, partly freely available), AptX (also very widely supported, but proprietary), AptX-HD (enhanced AptX with a higher bitrate, also proprietary), LDAC (probably the best codec available, highest bitrate, available in Android, supported mostly by Sony devices), MP3 (also possible, but supported by virtually no devices). And also SBC which is a native Bluetooth, first generation compression codec with rather bad sound quality.

My headphones supported SBC, AAC, AptX, AptX-HD, LDAC, so all the advanced codecs. Sadly on Linux it fallbacked to the basic SBC because no other was available for Bluetooth, and headphones for €200 produced rather underwhelming sound. I mostly listen to music on Spotify. Listening to it on my headphones meant transcoding OGG 320 kbps to SBC and losing a lot of sound quality.

Then I recalled that Sony released LDAC as open source in the Android Open Source Project. And they really did because you can find libldac released under Apache 2.0 License there. So it could possibly be made available on Linux, too. Bluez was also able to negotiate LDAC with the end device. What was missing was a plugin for PulseAudio that would utilize the codec and encode the stream into LDAC before sending it over Bluetooth to the headphones.

Today I learnt that such a plugin had been finally created.Β  And besides LDAC it also supports AAC, AptX, and AptX-HD. Those are patent-protected codecs and the plugin relies on ffmpeg to support them, so it’s not likely they will be available in Fedora any time soon. But libldac is already in Fedora package review and is waiting for the final legal approval. The plugin currently depends on ffmpeg, but if it were made optional, we could at least ship LDAC support by default in Fedora Workstation.

I thought we could also support AAC because its decoder/encoder is already available in Fedora, but I learnt that it only supported the original AAC format while what devices support these days is HE-AAC which is still protected by patents.

Anyway, someone already built packages of both the plugin and libldac and I installed them to test it. And it worked on Fedora 29 Workstation, LDAC was used for Bluetooth stream encoding:

ldac

I don’t have bat ears, but I could recognize a difference in sound quality immediately.

If I’m not mistaken it makes Linux the first desktop system to support LDAC. And with support for other codecs it will make it the OS with the best Bluetooth sound quality support because all other systems support only a subset of the list, hence fewer headphones/speakers at their best sound quality.

29 responses to “Better Bluetooth sound quality on Linux”

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

    […] 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 Avatar
    ocrete

    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 Avatar
      sesivany

      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 (η½—δΌŠ)

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

    Reply
  4. Pali Avatar
    Pali

    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 Avatar
      sesivany

      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 Avatar
        Pali

        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 Avatar
          gombosg89

          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 Avatar
            Pali

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

          2. gombosg89 Avatar
            gombosg89

            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 Avatar
            Pali

            “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 Avatar
            eischmann

            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 Avatar
            Pali

            > 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 Avatar
            eischmann

            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 Avatar
          eischmann

          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 Avatar
            Pali

            > 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 Avatar
            eischmann

            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 Avatar
      sesivany

      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 Avatar
        Pali

        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 Avatar
          sesivany

          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 Avatar
            Pali

            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 Avatar
            eischmann

            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

    […] Blueteeth LDAC (Rtheren) […]

    Reply
  6. Aleksandar Kostadinov Avatar
    Aleksandar Kostadinov

    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 Avatar
      gombosg89

      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 Avatar
    Colin Walters

    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 Avatar
      gombosg89

      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 Avatar
    Elbin

    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 Avatar
    Krisztian Szegi

    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

Leave a Reply

Your email address will not be published. Required fields are marked *