TODO list of missing kernel/bluez features that we need

[thewierdnut]

These all either need fixed or worked around in order to have a complete ASHA solution. Most of these probably need issues posted against the upstream bluez project.

• [ ] Ability to read or control the l2cap credits. The stereo pair of streams need to be kept reasonably close in depth (android keeps them within 4 credits). If one side lags behind, it is better to preemptively drop packets from both streams rather than keep feeding one side. Symptoms of falling out of sync include mis-matched stereo, audio cutting out as the devices switch off and try to re-sync, shifting of audio back and forth from the left to the right, and devices completely disconnecting.
• [ ] Better passive LE advertisement support. ASHA devices typically advertise their services on startup, and then advertise presence the entire time they are turned on. If you create an ASHA service profile, bluez will put the device on the kernel's auto-connect list, and will never remove it, even if you remove the profile. This causes ASHA devices to constantly reconnect on every advertisement, even if the user explicitly disconnects them. This makes it difficult for a user to switch their hearing devices to other audio sources, like phones or TVs. The userspace asha plugin needs the ability to know why a bluetooth device was disconnected, and to know the signal strength of advertisements in order to intelligently reconnect. This may also require some UI adjustments.
• [ ] Ability to directly override negotiated connection parameters. If a device sends a connection parameter request, the kernel will echo it back unmodified, and will completely ignore any connection parameters configured by the user in /etc/bluetooth/main.conf. Unfortunately some devices will negotiate unusable parameters, because they have only been tested against android, which will override the parameter request that gets sent back to the device. See https://github.com/thewierdnut/asha_pipewire_sink/issues/20
• [ ] Ability to explicitly set the ce_length connection parameter. The kernel currently always sets this to zero, but there are some devices that need this to be set to a reasonable value in order to function. Android always sets it to 16. See https://github.com/thewierdnut/asha_pipewire_sink/issues/10#issuecomment-2183236678
• [ ] Ability to explicitly set the PHY. Not a hard requirement, but some devices seem to prefer 1M PHY, and others prefer 2M PHY. 1M will result in longer range and a more stable connection for devices that use a long enough ce length, but 2M will work better in a noisy environment and is better on battery life.

[thewierdnut]

Note that most of these issues are due to the slightly twisted way in which ASHA uses the bluetooth protocol, and also because hearing devices are typically only tested against the android implementation, which leaves them with bugs and quirks.