Feature request: Blueman support for LDAC, aptX, aptxHD

[SaschaVasarrhelyi]

blueman: 2.2.4 BlueZ: Distribution: Ubuntu- Mate 22.04LTS Desktop environment:

Hi, is there a chance to see in the future an support, option to get LDAC, aptX and aptxHD to work on Ubuntu-Mate? For older Pulseaudio and BlueZ, blueman versions there was an PPA that, if you have install, enable LDAC, aptx and aptxHD to use with blueman and pulseaudio. Since the new Pulseaudio that PPA are unusable. So my question:" Is there a plan in the Future dev of Pulseaudio, BlueZ and blueman that we can hope of an inplementary of this Codecs and an option to use it?

Thanks in advanced for your answer Sascha

[infirit]

Blueman is just a frontend for the linux Bluetooth stack and pulseaudio. There are plugins for pulseaudio but I don't think Ubuntu installs them by default or at all due to licencing issues. Here is a thread that goes over how to install this.

https://askubuntu.com/questions/1071469/how-to-enable-aptx-for-bluetooth-devices

[cschramm]

To my understanding what you need to get aptX out of pulseaudio (there are alternatives like PipeWire) is pulseaudio 15 with built-in GStreamer support and GStreamer 1.20. If you want to switch codecs in a GUI, pavucontrol 5 has got you covered.

Ubuntu 22.04 should have everything of that and I would expect it to just work. I don't think you need any special modules or anything (except for the usual pulseaudio-module-bluetooth package to make Bluetooth audio work in general).

Regarding blueman, it could make sense that we add a pavucontrol-like possibility to switch codes just like we have for profiles. I'm not sure how important that is as from a quick test with my Android phone it seems like it defaults to the highest quality codec available so that you do not have to switch to aptX explicitly or similar.

[infirit]

Regarding blueman, it could make sense that we add a pavucontrol-like possibility to switch codes just like we have for profiles. I'm not sure how important that is as from a quick test with my Android phone it seems like it defaults to the highest quality codec available so that you do not have to switch to aptX explicitly or similar.

It's handled like this when using pipewire or the pulse modules. Do you want to change this?

[cschramm]

Interesting. PipeWire seems to go a different way there and add the codecs to the list of profiles. I guess it does not even have the messaging API that pulseaudio uses to control the codec. (I have to say the list seems rather inconsistent as you have a generic entry for each profile and one for every codec. What's to expect when using the generic one? :laughing:)

With pulseaudio I just get the standard A2DP and HSP / HFP choice in blueman's and pavucontrol's profile menus. pavucontrol has an additional dropdown with the codecs for the selected profile.

What do you mean with "the pulse modules"?

[infirit]

The modules I'm talking about are these [1]. These behaved similar to pipewire. Thinking about this, I'm not sure we can tell from pipewire's pulse layer it we are dealing with regular pulse or pipewire.

[1] https://github.com/EHfive/pulseaudio-modules-bt

[infirit]

Thinking about this, I'm not sure we can tell from pipewire's pulse layer it we are dealing with regular pulse or pipewire.

Actually, they want to be a drop in replacement so why should we need to check for that.

[cschramm]

Ah, alright, so PipeWire copied the pulseaudio-modules-bt workaround. That makes sense, given the timeline (PipeWire implemented codec support much earlier than pulseaudio, so there was nothing else it could have been compatible with). https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/412 mentions that it's a temporary solution "for easier testing, since not many UIs support the new pulseaudio codec system yet".

The actual pulseaudio way to handle codecs is its messaging API with list-codecs, get-codec and switch-codec messages. PipeWire does implement that as well (since 0.3.25). I tried to test it on Pop!_OS 22.04 which uses PipeWire by default but failed to get anything working (I see the device in pavucontrol's configuration tab with a single merged A2DP / HFP / HSP item but no codec selection and no source or sink anywhere. That was a rather weird experience... :sweat_smile:).

So... PipeWire seems to be compatible for controlling the codec but still provides the (profile, codec)-tuples as the profile list, resulting in a rather weird UX. https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/543 mentions removing those "codec profiles" in the future "once more mixer apps support the message protocol" and that is where it gets complicated / funny / frustrating: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1563 tracks the weird UX issue (in that case, in pavucontrol) and according to the comments PipeWire would drop the codec profiles once gnome-control-center has proper codec handling but "gnome-control center is happy with how PipeWire does it with the profiles and since the GNOME devs are mostly Fedora, which is PipeWire, there is not going to be a lot of effort". :unamused:

Just like for mixer applications I see the following options for us:

1. Add support for pulseaudio codec switching. This results in a weird UX with current PipeWire, just like in pavucontrol, but is hopefully fine with future PipeWire.
2. Do not add any explicit support. This results in no codec switching with pulseaudio and profile-based codec switching with current PipeWire, just like in gnome-control-center. As I already mentioned, it's questionable if having codec switching in blueman is of much value anyway.
3. Detect pulseaudio / PipeWire to decide whether to provide proper codec switching or not, assuming that PipeWire does provide the codec profiles.

I think I'd go with 2 for now, i.e. await how the situation evolves and maybe think about codec switching again once PipeWire dropped codec profiles.

[infirit]

Ugh, so they knew of the codec selection in pulse but went ahead and did their own thing anyway 😞 . Now we have to deal with the backlash. I'm fine with ignoring pipewure exists and focus on having pulse work properly.

[cschramm]

To be fair: They did not. PipeWire implemented codec support before pulseaudio did.

[infirit]

Ah, sorry. I got the timeline a bit confused.

[infirit]

I actually tried out the codec selection on pipewire and it does work for me. When I select the new codec it switches profile. So let's assume pipewire folks will figure out a solution to this. Will it look jank in pipewire, unfortunately yes unless we strip the codec part when we present the profiles.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.