Read access to credits_outgoing for credit-based l2cap connections

[thewierdnut]

Is your feature request related to a problem? Please describe.

We are trying to implement a hearing-aid streaming device on a raspberry pico using google's ASHA standard.

This requires us to make two credit-based l2cap connections to two separate bluetooth peripherals, and then stream audio to them. The standard requires the devices to initially provide 8 credits, and then return a credit each time they receive an audio packet.

There are a couple of problems we are trying to solve:

1. Some devices will disconnect the moment they have a buffer underrun.
2. Some devices will disconnect if one device falls behind, and the audio gets out of sync.

The android implementation here, which we are using as a reference, uses the number of credits as a reference, mainly by comparing how many credits each device has available, and preemptively dropping audio frames if the audio devices go out of sync. Since this is the only implementation against which hearing aids are likely tested against, we need to duplicate this behavior if possible, but btstack does not provide access to the outgoing credits.

Describe the solution you'd like

A new api function, which returns credits_outgoing for a credit-based l2cap connection. We can use this as feedback to gauge how in-sync the hearing devices are, and inject or skip extra audio packets to maintain that synchronization.

Describe alternatives you've considered

Intentionally streaming silence until there are no credits available, and then using the availability of buffer space as an indicator of whether the hearing aids are in sync. This won't work for all devices though, because some hearing devices will make the full 64 credits available after the initial 8 credits are offered, which represents nearly 20 minutes of audio. This method will make the latency unacceptable.

[shermp]

Just for reference, I asked about this independently on the btstack-dev google group here.

[mringwal]

@shermp thanks for pointing this out. I'll add something in the next days (I'm deep in the HID Parser which needs some rework)

[shermp]

That's fine @mringwal

In the meantime, I'm investigating other options to improve stability in Pico-ASHA. I discovered that by keeping the WiFi/BT firmware on flash, I have just enough RAM to use the pico's copy_to_ram function, which at first glance seems to be helping a lot. It's not perfect yet though.

[shermp]

Thanks for adding support for this @mringwal

It's already given me plenty of insights. For example, it turns out Pico-ASHA is not always receiving new credits from the HA's in a timely manner. Knowing this allows me to add mitigations.

[mringwal]

Glad it helps. To be honest, I haven't used the (Enhanced)CoC modes for anything really. It's more overhead than just Without Response and Notifications, and not faster.