[How to do instruction] Moode 8: Add bluetooth codec support for AAC, aptX & aptX-HD to bluez-alsa package

[Tim Curtis]

So true. Hearing does not improve with age like red wine is supposed to do, lol.

I'm just trying to verify whether the OP's recipe does in fact work and under what usage scenarios.

[jenzd]

Hello,

I followed your clear guide however when I connect my aptX HD/LDAC capable POCO F5 Pro to moOde it defaults to AAC codec. I removed AAC from the rules source file, repackaged bluez-alsa-utils and reinstalled it and it defaults to SBC.

Note, that my phone successfully negotiates the LDAC codec with my SMSL SU-9 PRO DAC.

Did I miss something to get LDAC or AptX HD instead of ACC or SBC by default ?

Thanks in advance,
Romain

This issue is discussed in bluez-alsa issue #581. Apparently this build links to a library which supports aptX encoding but not decoding (issue #581 discusses LDAC, actually, but the situation is the same). I don't know if such a library exists for Linux in general and Raspberry Pi OS in particular.

Regards,
Kent

I forgot about that.

If there is no decoding for LDAC and AptX then what usage scenario if any applies?

ETA: OP states "The following guide shows how to additionally include support for the bluetooth codecs AAC, aptX and aptX-HD (each for receive & playback)"

Very confusing :-0

Hi all,

Sorry for the late answer, I was off for a few days. I can reproduce the issue with aptX and aptX-HD and it seems to be caused by a change introduced with bluez-alsa version 4.0.0.

Support for aptX and aptX-HD via libopenaptx (both for playback and receive) is avaiable since version 3.1.0 of bluez-alsa and used to work perfectly together with Moode. I actually used this configuration quite often in the past with several versions of Moode (at least since Moode 7) where my Sony Xperia XZ1 Compact reliably connected via the best available codec (aptx-HD in this case). Unfortunately, I did not test aptX again when writing the guide, but only used an AAC capable device instead. (And didn't expect negative surprises due to the stable behaviour in the past.)

With the current version of Moode (8.3.2) I get the following test results with the Sony Xperia phone:

• bluez-alsa 4.0.0 installed as a package (following the guide) => connects via AAC only
  
• bluez-alsa 3.1.0 installed from source code configured with "--enable-aptx --enable-aptx-hd --with-libopenaptx" => connects via aptX-HD
  
• bluez-alsa 4.0.0 installed from source code configured with "--enable-aptx --enable-aptx-hd --with-libopenaptx" => connects via AAC only
  
• bluez-alsa 4.1.0 installed from source code configured with "--enable-aptx --enable-aptx-hd --with-libopenaptx" => connects via AAC only
  

So currently only bluez-alsa 3.1.0 seems to work properly. I will try to dig deeper into the issue when I can find some more time (e.g. install and test bluez-alsa on a clean Rasperry Pi OS Lite image to see if I can reproduce the issue there as well).

Sorry for the (unexpected) inconveniece.

Best regards
Jens

[romain]

Hello,

I followed your clear guide however when I connect my aptX HD/LDAC capable POCO F5 Pro to moOde it defaults to AAC codec. I removed AAC from the rules source file, repackaged bluez-alsa-utils and reinstalled it and it defaults to SBC.

Note, that my phone successfully negotiates the LDAC codec with my SMSL SU-9 PRO DAC.

Did I miss something to get LDAC or AptX HD instead of ACC or SBC by default ?

Thanks in advance,
Romain

This issue is discussed in bluez-alsa issue #581. Apparently this build links to a library which supports aptX encoding but not decoding (issue #581 discusses LDAC, actually, but the situation is the same). I don't know if such a library exists for Linux in general and Raspberry Pi OS in particular.

Regards,
Kent

I forgot about that.

If there is no decoding for LDAC and AptX then what usage scenario if any applies?

ETA: OP states "The following guide shows how to additionally include support for the bluetooth codecs AAC, aptX and aptX-HD (each for receive & playback)"

Very confusing :-0

Hi all,

Sorry for the late answer, I was off for a few days. I can reproduce the issue with aptX and aptX-HD and it seems to be caused by a change introduced with bluez-alsa version 4.0.0.

Support for aptX and aptX-HD via libopenaptx (both for playback and receive) is avaiable since version 3.1.0 of bluez-alsa and used to work perfectly together with Moode. I actually used this configuration quite often in the past with several versions of Moode (at least since Moode 7) where my Sony Xperia XZ1 Compact reliably connected via the best available codec (aptx-HD in this case). Unfortunately, I did not test aptX again when writing the guide, but only used an AAC capable device instead. (And didn't expect negative surprises due to the stable behaviour in the past.)

With the current version of Moode (8.3.2) I get the following test results with the Sony Xperia phone:

• bluez-alsa 4.0.0 installed as a package (following the guide) => connects via AAC only
  
• bluez-alsa 3.1.0 installed from source code configured with "--enable-aptx --enable-aptx-hd --with-libopenaptx" => connects via aptX-HD
  
• bluez-alsa 4.0.0 installed from source code configured with "--enable-aptx --enable-aptx-hd --with-libopenaptx" => connects via AAC only
  
• bluez-alsa 4.1.0 installed from source code configured with "--enable-aptx --enable-aptx-hd --with-libopenaptx" => connects via AAC only
  

So currently only bluez-alsa 3.1.0 seems to work properly. I will try to dig deeper into the issue when I can find some more time (e.g. install and test bluez-alsa on a clean Rasperry Pi OS Lite image to see if I can reproduce the issue there as well).

Sorry for the (unexpected) inconveniece.

Best regards
Jens

No problem Jens, thanks

[TheOldPresbyope]

Huh. I'm surprised I don't recall libopenaptx. In any case, since I have neither aptX nor aptX-HD senders available, the issue is moot for me.

I have to say I'm nonplussed by this statement about the library I found at https://github.com/Arkq/openaptx

This project is for research purposes only. Without a proper license private and commercial usage might be a case of a patent infringement. If you are looking for a library, which can be installed and used legally (commercial, private and educational usage), go to the Qualcomm® aptX™ homepage and contact Qualcomm customer service.

The source code itself is licensed under the terms of the MIT license. However, compression algorithms are patented and licensed under the terms of a proprietary license. Hence, compilation and redistribution in a binary format is forbidden!

Regards,
Kent

[jenzd]

Hi all,

Sorry for the late answer, I was off for a few days. I can reproduce the issue with aptX and aptX-HD and it seems to be caused by a change introduced with bluez-alsa version 4.0.0.

Support for aptX and aptX-HD via libopenaptx (both for playback and receive) is avaiable since version 3.1.0 of bluez-alsa and used to work perfectly together with Moode. I actually used this configuration quite often in the past with several versions of Moode (at least since Moode 7) where my Sony Xperia XZ1 Compact reliably connected via the best available codec (aptx-HD in this case). Unfortunately, I did not test aptX again when writing the guide, but only used an AAC capable device instead. (And didn't expect negative surprises due to the stable behaviour in the past.)

With the current version of Moode (8.3.2) I get the following test results with the Sony Xperia phone:

• bluez-alsa 4.0.0 installed as a package (following the guide) => connects via AAC only
  
• bluez-alsa 3.1.0 installed from source code configured with "--enable-aptx --enable-aptx-hd --with-libopenaptx" => connects via aptX-HD
  
• bluez-alsa 4.0.0 installed from source code configured with "--enable-aptx --enable-aptx-hd --with-libopenaptx" => connects via AAC only
  
• bluez-alsa 4.1.0 installed from source code configured with "--enable-aptx --enable-aptx-hd --with-libopenaptx" => connects via AAC only
  

So currently only bluez-alsa 3.1.0 seems to work properly. I will try to dig deeper into the issue when I can find some more time (e.g. install and test bluez-alsa on a clean Rasperry Pi OS Lite image to see if I can reproduce the issue there as well).

Sorry for the (unexpected) inconveniece.

Best regards
Jens

Finally found the solution after diigging a bit deeper into the bluez-alsa documentation (and will update the guide soon).

Since version 4.0.0 all additional codecs other than SBC and (if installed) AAC are inactive by default. They need to be activated in the config file of the bluealsa service first.

You can see this by comparing the result of

Code:

bluealsa-cli status

with

Code:

bluealsa --help

The first command shows which codecs are activated (SBC, AAC only) while the second one shows all codecs with which the package has been built (last lines of the respective outputs).

To activate aptX, aptX-HD and LDAC you additionally have to change the file /etc/systemd/system/bluealsa.service

Code:

sudo nano /etc/systemd/system/bluealsa.service

and change the line

Code:

ExecStart=/usr/bin/bluealsa -p a2dp-source -p a2dp-sink

to

Code:

ExecStart=/usr/bin/bluealsa -p a2dp-source -p a2dp-sink -c aptx -c aptx-hd -c ldac

After rebooting, "bluealsa-cli status" finally shows

Code:

Service: org.bluealsa
Version: v4.0.0
Adapters: hci0
Profiles:
 A2DP-source : SBC AAC aptX aptX-HD LDAC
 A2DP-sink   : SBC AAC aptX aptX-HD

and my Sony Xperia connects with aptx-HD again.
 

Unfortunately the file /etc/systemd/system/bluealsa.service belongs to the moode-player package and will be overwritten with each update of Moode - so this last step needs to repeated after each in-place update.

Best regards
Jens

[jenzd]

Huh. I'm surprised I don't recall libopenaptx. In any case, since I have neither aptX nor aptX-HD senders available, the issue is moot for me.

I have to say I'm nonplussed by this statement about the library I found at https://github.com/Arkq/openaptx

This project is for research purposes only. Without a proper license private and commercial usage might be a case of a patent infringement. If you are looking for a library, which can be installed and used legally (commercial, private and educational usage), go to the Qualcomm® aptX™ homepage and contact Qualcomm customer service.

The source code itself is licensed under the terms of the MIT license. However, compression algorithms are patented and licensed under the terms of a proprietary license. Hence, compilation and redistribution in a binary format is forbidden!

Regards,
Kent

openaptx by Arkq is actually an alternative to libopenaptx (https://github.com/pali/libopenaptx). Prior to verion 3.1.0 of bluez-alsa only openaptx was supported (and would have to be built from source). Version 3.1.0 introduced the switch "--with-libopenaptx" to use libopenaptx instead. A binary version of libopenaptx is available from the normal Raspberry Pi OS repositoriy (package libopenaptx0).

Best regards
Jens

[jenzd]

There is even an (experimental) implementation of an LDAC decoder which iis supported by bluealsa as an LDAC sink (https://github.com/anonymix007/libldacdec). see also the bluealsa issue https://github.com/arkq/bluez-alsa/issues/482.

Cheers, Jens

[Tim Curtis]

We could include libopenaptx and the systemd config in the bluez-alsa package shipped with moOde but according to Qualcomm only encoding is free open source and that decode is still proproetary.

@jenzd it's very confusing to me since you mentioned "Support for aptX and aptX-HD via libopenaptx (both for playback and receive)".

[jenzd]

@jenzd it's very confusing to me since you mentioned "Support for aptX and aptX-HD via libopenaptx (both for playback and receive)".

The libopenaptx liibrary which is included in Raspberry Pi OS (seems to be a standard debian package) is apparently capable of both. So I guess it should be ok to just link against it?

The situation seems to be different for LDAC, where only the encoder is freely avaiable as a binary package.

Regards
Jens

[Tim Curtis]

@jenzd it's very confusing to me since you mentioned "Support for aptX and aptX-HD via libopenaptx (both for playback and receive)".

The libopenaptx liibrary which is included in Raspberry Pi OS (seems to be a standard debian package) is apparently capable of both. So I guess it should be ok to just link against it?

The situation seems to be different for LDAC, where only the encoder is freely avaiable as a binary package.

Regards
Jens

Right, it was picked up by Debian and thus also by downstream RaspiOS so it would appear that it's ok to distribute :-)

Have you tested that receive works i.e., by connecting client to moOde and verifying that aptX codec is being used by bluez-alsa?