search

bluez / bluez

Main BlueZ tree
https://bluez.github.io/bluez/
GNU General Public License v2.0
718 stars 269 forks source link

[Feature] Exposing LE parameter update via DBUS #731

Open Jah-On opened 7 months ago

Jah-On commented 7 months ago

Hello,

Currently, BlueZ does not offer a way to set the connection interval for an LE connection via userspace for initialization or during connection. While it is possible to set the default interval in main.conf, this would affect all LE connections and does not account for device variance. One such application of this feature is the ASHA protocol for hearing aids. I would like to know if this can be added and if I could help implement it in any way.

Thanks, John Schulz

Jah-On commented 7 months ago

I'm closing this issue as I have reached the conclusion that it would not be of much benefit. Even if my ASHA app worked and people used it... the user base would be so small that'd it'd be hard to justify the work. Instead, I plan on working bringing LE Audio support to KDE (once I get my hands on a pair of BLEA headphones) so that it recognizes LC3 and can switch between transports from the settings app. I also want to make an Auracast app to serve as a template for frameworks.

Thanks!

ford-prefect commented 5 months ago

I think there's value to keeping this open so BlueZ can support ASHA

Jah-On commented 4 months ago

Ok, I will reopen the issue. I sent a message to Google's Accessibility team proposing a revised version of ASHA. Here's what I said...

The current specification of the ASHA protocol uses the g722 codec which was created in the 1980s for phone systems. However, many users use ASHA streaming for more than phone calls and listening to podcasts. Consequently, the audio does not sound great when listening to music. Sure, not all users will be able to notice a difference but why let that be the reason to limit the sound quality for those who can tell a difference? I propose that Google introduces a revision to the ASHA protocol that uses the LC3 as the default or mandatory secondary codec. LC3 is a modern codec that performs better at lower bitrates for music when compared to most other codecs. Doing this change now will help ensure ASHA remains as a sustainable bridge to LE Audio and would reduce manufacturer complexity by reducing the number of codecs needed in firmware. \ Additionally, Google should require a default packet interval of 30ms instead of 20ms. Yes, this will introduce more latency when using the standard mode. However, this would allow ASHA to work on nearly all desktop platforms. Currently, Windows, MacOS, and BlueZ (Linux) do not provide a way to issue a HCI command for changing the connection interval. Encouraging these platforms to add the functionality would be harder than having the default ASHA interval follow the standard 30ms that each platform uses. Even with this default, the peripheral should still respond properly to an interval update command issue by the central on Android. \ Thank you for taking the time to read this message and I hope these suggestions are taken into consideration.

If Google refuses to release an update to the specification for the second part then BlueZ will need to expose the functionality for ASHA to work on Linux.

barolo commented 4 months ago

How complex is the implementation of this feature? There are quite a few folks desperate for this to be implemented.

Jah-On commented 4 months ago

Here's an idea... could we send the L2CAP packets via raw advertisement packets? This way should allow us to set the advertisement interval without interfering with other services. Am I missing something?

thewierdnut commented 3 months ago

If Google refuses to release an update to the specification for the second part then BlueZ will need to expose the functionality for ASHA to work on Linux.

I seriously doubt that google will ever update the ASHA protocol, given that new devices will be implementing the LE Audio standard instead. ASHA is effectively dead, except that it lives on in devices that typically cost more than my car, and can't be replaced on a rapid schedule. If we expect to support ASHA, then the central needs to be able to update the connection interval (and the phy, but thats a different topic).

yacinbm commented 2 months ago

@Jah-On How's your development going for this feature? I'd be very interested in contributing to a sample Auracast application using BlueZ. Doing this should hopefully lower the barrier of entry for the protocol, helping the standard gain some traction. Auracast seems to be very much in its infancy still, so it may be a good opportunity to cement BlueZ as a leader for the feature!

ford-prefect commented 2 months ago

At the moment, LE Audio features are implemented via BlueZ plugin and PipeWire: https://www.bluez.org/le-audio-support-in-pipewire/

LE parameter updates are available as internal API at the moment. Example: https://github.com/bluez/bluez/blob/be0b08770e9214592e89589b2dc069426c0d9b91/profiles/audio/asha.c#L159

Jah-On commented 2 months ago

@Jah-On How's your development going for this feature? I'd be very interested in contributing to a sample Auracast application using BlueZ. Doing this should hopefully lower the barrier of entry for the protocol, helping the standard gain some traction. Auracast seems to be very much in its infancy still, so it may be a good opportunity to cement BlueZ as a leader for the feature!

I'm not working on this feature since it goes against core spec and would be of little use as @ford-prefect pointed out. If you want to help implement AuraCast on Linux, contribute to BlueZ directly rather than doing it externally.