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

[TheOldPresbyope]

I was interested enough to trace the origin of the libopenaptx package in Debian / Raspberry Pi OS. It turns out not to be the code in Arkq's  repo. Instead, it's code developed by GitHub user pali https://github.com/pali/libopenaptx (Full disclosure: I looked only at the file headers).

I guess if the library is in the general distros it's fair game for us since we would just be linking to it. Bummer that the libopenaptx package has no Debian package maintainer; he backed out over a year ago. I note that pali hasn't touched his repo in 2 years either. The rev in the Debian repo (0.2.0-5) is slightly behind the latest rev in pali's repo (0.2.1). Judging from the comment on the 0.2.1 release, there's been a kerfuffle over who's been doing what with the code. I don't think this affects us since Debian stands between.

As I said before, it's not a feature I'm likely to use, but if you decide to go forward I'm happy to try to test as best I can with the gear at my disposal.

Regards,
Kent

[Tim Curtis]

I was interested enough to trace the origin of the libopenaptx package in Debian / Raspberry Pi OS. It turns out not to be the code in Arkq's  repo. Instead, it's code developed by GitHub user pali https://github.com/pali/libopenaptx (Full disclosure: I looked only at the file headers).

I guess if the library is in the general distros it's fair game for us since we would just be linking to it. Bummer that the libopenaptx package has no Debian package maintainer; he backed out over a year ago. I note that pali hasn't touched his repo in 2 years either. The rev in the Debian repo (0.2.0-5) is slightly behind the latest rev in pali's repo (0.2.1). Judging from the comment on the 0.2.1 release, there's been a kerfuffle over who's been doing what with the code. I don't think this affects us since Debian stands between.

As I said before, it's not a feature I'm likely to use, but if you decide to go forward I'm happy to try to test as best I can with the gear at my disposal.

Regards,
Kent

I've reviewed that as well.

I think I'll make a test release so we can see what works and what doesn't. 

Isn't there a bluez-alsa command that shows which codec is being used?

[TheOldPresbyope]

I was interested enough to trace the origin of the libopenaptx package in Debian / Raspberry Pi OS. It turns out not to be the code in Arkq's  repo. Instead, it's code developed by GitHub user pali https://github.com/pali/libopenaptx (Full disclosure: I looked only at the file headers).
...
Regards,
Kent

I've reviewed that as well.

I think I'll make a test release so we can see what works and what doesn't. 

Isn't there a bluez-alsa command that shows which codec is being used?

@jenzd may well know a better command. Here's one I gleaned from the bluez-alsa issues long ago which queries the dbus

gdbus call --system -d org.bluealsa -o /org/bluealsa -m org.bluealsa.Manager1.GetPCMs

So, for example, with a stock moOde player paired and connected to a JBL Flip2 BT speaker, I get

Code:

pi@moode:~ $ gdbus call --system -d org.bluealsa -o /org/bluealsa -m org.bluealsa.Manager1.GetPCMs
({objectpath '/org/bluealsa/hci0/dev_00_1D_DF_AA_27_37/a2dpsrc/sink': {'Device': <objectpath '/org/bluez/hci0/dev_00_1D_DF_AA_27_37'>, 'Transport': <'A2DP-source'>, 'Mode': <'sink'>, 'Format': <uint16 33296>, 'Channels': <byte 0x02>, 'Sampling': <uint32 48000>, 'Codec': <'SBC'>, 'Delay': <uint16 150>, 'SoftVolume': <true>, 'Volume': <uint16 32639>}},)

whereas, with the same player connected as BT speaker for my iPad

Code:

pi@moode:~ $ gdbus call --system -d org.bluealsa -o /org/bluealsa -m org.bluealsa.Manager1.GetPCMs
({objectpath '/org/bluealsa/hci0/dev_D0_D2_B0_DB_13_78/a2dpsnk/source': {'Device': <objectpath '/org/bluez/hci0/dev_D0_D2_B0_DB_13_78'>, 'Transport': <'A2DP-sink'>, 'Mode': <'source'>, 'Format': <uint16 33296>, 'Channels': <byte 0x02>, 'Sampling': <uint32 44100>, 'Codec': <'SBC'>, 'Delay': <uint16 150>, 'SoftVolume': <true>, 'Volume': <uint16 1799>}},)

In both cases here the SBC codec is being used.

As Jens said, bluealsa --help tells us which codecs are available and in this stock moOde player they are just

Code:

pi@moode:~ $ bluealsa --help

Available BT profiles:
 - a2dp-source    Advanced Audio Source (LDAC, SBC)
 - a2dp-sink    Advanced Audio Sink (SBC)
...

Since this is stock moOde, bluealsa-cli isn't present.

Regards,
Kent

[TheOldPresbyope]

As a follow-up to my previous post, I followed Jens's instructions to add the extra codecs. Then I paired and connected to my Sennheiser 4.50BT headphones (which contain SBC and aptX codecs)

Code:

# check that the codecs are available
pi@moode:~ $ bluealsa-cli status
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

# check UUID of my headphones
pi@moode:~ $ bluetoothctl info
Device 00:16:94:29:7F:10 (public)
    Name: HD 4.50BTNC
    Alias: HD 4.50BTNC
    Class: 0x00240404
    Icon: audio-card
    Paired: yes
    Trusted: yes
    Blocked: no
    Connected: yes
    ...

# look to see which codec was negotiated in the pairing process (noting it's the right UUID)
pi@moode:~ $ gdbus call --system -d org.bluealsa -o /org/bluealsa -m org.bluealsa.Manager1.GetPCMs
({objectpath '/org/bluealsa/hci0/dev_00_16_94_29_7F_10/a2dpsrc/sink': {'Device': <objectpath '/org/bluez/hci0/dev_00_16_94_29_7F_10'>, 'Sequence': <uint32 0>, 'Transport': <'A2DP-source'>, 'Mode': <'sink'>, 'Format': <uint16 33296>, 'Channels': <byte 0x02>, 'Sampling': <uint32 48000>, 'Codec': <'aptX'>, 'Delay': <uint16 150>, 'SoftVolume': <true>, 'Volume': <uint16 32639>}},)

Yay. The "higher" quality aptX codec was selected during the negotiation rather than the SBC.

However, moOde seems to think it's connected to a Bluetooth source rather than sink because the webUI is overlaid with "Bluetooth Active: HD 4.50BTNC" and the Bluetooth control button?!? ETA: self-induced error. BT's working fine.

Regards,
Kent

[Tim Curtis]

As a follow-up to my previous post, I followed Jens's instructions to add the extra codecs. Then I paired and connected to my Sennheiser 4.50BT headphones (which contain SBC and aptX codecs)

Code:

# check that the codecs are available
pi@moode:~ $ bluealsa-cli status
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

# check UUID of my headphones
pi@moode:~ $ bluetoothctl info
Device 00:16:94:29:7F:10 (public)
    Name: HD 4.50BTNC
    Alias: HD 4.50BTNC
    Class: 0x00240404
    Icon: audio-card
    Paired: yes
    Trusted: yes
    Blocked: no
    Connected: yes
    ...

# look to see which codec was negotiated in the pairing process (noting it's the right UUID)
pi@moode:~ $ gdbus call --system -d org.bluealsa -o /org/bluealsa -m org.bluealsa.Manager1.GetPCMs
({objectpath '/org/bluealsa/hci0/dev_00_16_94_29_7F_10/a2dpsrc/sink': {'Device': <objectpath '/org/bluez/hci0/dev_00_16_94_29_7F_10'>, 'Sequence': <uint32 0>, 'Transport': <'A2DP-source'>, 'Mode': <'sink'>, 'Format': <uint16 33296>, 'Channels': <byte 0x02>, 'Sampling': <uint32 48000>, 'Codec': <'aptX'>, 'Delay': <uint16 150>, 'SoftVolume': <true>, 'Volume': <uint16 32639>}},)

Yay. The "higher" quality aptX codec was selected during the negotiation rather than the SBC.

However, moOde seems to think it's connected to a Bluetooth source rather than sink because the webUI is overlaid with "Bluetooth Active: HD 4.50BTNC" and the Bluetooth control button?!? 


Regards,
Kent

Thats strange. Check the audio output setting in Bluetooth Config.

[TheOldPresbyope]

As a follow-up to my previous post, I followed Jens's instructions to add the extra codecs. Then I paired and connected to my Sennheiser 4.50BT headphones (which contain SBC and aptX codecs)

Code:

# check that the codecs are available
pi@moode:~ $ bluealsa-cli status
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

# check UUID of my headphones
pi@moode:~ $ bluetoothctl info
Device 00:16:94:29:7F:10 (public)
    Name: HD 4.50BTNC
    Alias: HD 4.50BTNC
    Class: 0x00240404
    Icon: audio-card
    Paired: yes
    Trusted: yes
    Blocked: no
    Connected: yes
    ...

# look to see which codec was negotiated in the pairing process (noting it's the right UUID)
pi@moode:~ $ gdbus call --system -d org.bluealsa -o /org/bluealsa -m org.bluealsa.Manager1.GetPCMs
({objectpath '/org/bluealsa/hci0/dev_00_16_94_29_7F_10/a2dpsrc/sink': {'Device': <objectpath '/org/bluez/hci0/dev_00_16_94_29_7F_10'>, 'Sequence': <uint32 0>, 'Transport': <'A2DP-source'>, 'Mode': <'sink'>, 'Format': <uint16 33296>, 'Channels': <byte 0x02>, 'Sampling': <uint32 48000>, 'Codec': <'aptX'>, 'Delay': <uint16 150>, 'SoftVolume': <true>, 'Volume': <uint16 32639>}},)

Yay. The "higher" quality aptX codec was selected during the negotiation rather than the SBC.

However, moOde seems to think it's connected to a Bluetooth source rather than sink because the webUI is overlaid with "Bluetooth Active: HD 4.50BTNC" and the Bluetooth control button?!? 


Regards,
Kent

Thats strange. Check the audio output setting in Bluetooth Config.

Well, that's embarrassing. Guess who forgot to switch to Bluetooth speaker output  

All's well. Now to jury-rig some BT sources with advanced codecs.

Regards,
Kent

[TheOldPresbyope]

So I've followed up with several tests:

Let's refer to the moOde 8.3.2 player I just built on and played with yesterday as the "the receiver."

1. copied the new .deb files over to another moOde 8.3.2 player and installed. Changing the settings in bluealsa.service on this new sender to start bluealsa with various codecs available and then connecting to the receiver I can see the results in the codec negotiated. Nice.

2. using an iPhone SE I can connect to the receiver with the AAC codec.

3. using my Google Pixel 6a, I confidently expected to connect to the receiver with the SBC codec. Surprise, the connection was with the aptX-HD codec. I didn't know until this moment that recent Pixel phones support an HD Audio mode using this codec! Sweet.

Well done, @jenzd !

Regards,
Kent

[jenzd]

Hi Kent,

Thanks for your testing efforts. This coincides with the results I got with my Sony Xperia XZ1 Compact. After adding the codec support, it automatically connects and streams to Moode via aptX-HD. By selectively deactivating the available codecs I could moreover test that streaming successfully works with aptX and AAC as well. (The order by which the Sony automatically selects its codec apparently is aptX-HD > aptX > AAC > SBC.)

By the way, an alternative command to see the codec which is in use (with better readable output) is:

Code:

bluealsa-cli --verbose list-pcms

Cheers
Jens

[TheOldPresbyope]

Oh my, yes.

My last test case using my Pixel 6a as source

Code:

pi@moode:~ $ bluealsa-cli --verbose list-pcms
/org/bluealsa/hci0/dev_0C_C4_13_D6_3A_36/a2dpsnk/source
Device: /org/bluez/hci0/dev_0C_C4_13_D6_3A_36
Sequence: 9
Transport: A2DP-sink
Mode: source
Format: S24_LE
Channels: 2
Sampling: 48000 Hz
Available codecs: SBC AAC aptX aptX-HD
Selected codec: aptX-HD
Delay: 15.0 ms
SoftVolume: Y
Volume: L: 127 R: 127
Muted: L: N R: N

Regards,
Kent