Issue Fixes for Bap Broadcast Samples and Enable LC3 Codec For iMXRT1062 MCU

[nirav-agrawal]

bluetooth: host: add kconfig for synchronous buffer count

a. adding kconfig for HCI synchronous cmds, or events responsible to manage host-controller credits to avoid discard complete event due to unavailability of synchronous buffer.
b. Issue was present while working with use cases like Broadcast-BAP where more than one stream (SDU per BIS) sent to controller over HCI, and controller sends NOCP events for both streams at the end of BIG sync anchor. The gap between two consecutive events in same BIG is within few micro-sec range causes HCI driver to drop successive event while processing current and if not freed.

samples: bluetooth: bap_broadcast: enable LIBLC3 for NXP iMXRT Family

Added i. MXRT1062 MCU to enable LC3 Codec as it supports FPU and used to evaluate BLE Audio applications using LC3 based payload.

[Thalley]

@nirav-agrawal I think I need some more information here :)

You are talking about synchronous evens and TX.

I assume that the problem you are referring to here is that we are sending data in the callback that is triggered by the num_complete_packets event (the sent) callback? If so, then that is not specific to ISO/Audio or BAP, but a general issue for any Bluetooth operation done in the callback (both for ISO and L2CAP), so it's weird that this only seems to be done for the BAP Broadcast Source.

It also seems to be an issue specific for the controller you are using, as it works fine on a handful of other controllers, so there's some generic issue here that is being overlooked I think.

Can you elaborate on how you found this issue, and why you'd need additional synchronous events?

[nirav-agrawal]

@nirav-agrawal I think I need some more information here :)

You are talking about synchronous evens and TX.

I assume that the problem you are referring to here is that we are sending data in the callback that is triggered by the num_complete_packets event (the sent) callback? If so, then that is not specific to ISO/Audio or BAP, but a general issue for any Bluetooth operation done in the callback (both for ISO and L2CAP), so it's weird that this only seems to be done for the BAP Broadcast Source.

It also seems to be an issue specific for the controller you are using, as it works fine on a handful of other controllers, so there's some generic issue here that is being overlooked I think.

Can you elaborate on how you found this issue, and why you'd need additional synchronous events?

Hi @Thalley, thank you for your comment.

The current issue I observed is with bap broadcast tests with multiple streams. In current Zephyr implementation, the synchronous buffer count is one, means there is no room for any synchronous events received back-to-back, from controller would drop the event due to processing current event. I am not sure if this issue would hit in other ACL connections or CIS connections.

In particular bap broadcast use case, there is no ACK from remote and local controller has to raise NOCP event at either end of BIS events or BIG events.

If controller sends NOCP at BIS end of events, there can be gap of BIS events while sending NOCP for each BISes to the host (delta of two NOCP events may be in milli-sec). since host driver/stack gets enough time processing of received event, almost no issues would be seen in this scenario.

if controller configured with some synchronisation mechanism and sends all BISes NOCP (In one subgroup) at the end of subgroup event, it causes issue in Zephyr stack due to more than one events have been received within very short span and events would get dropped and controller's credits will not be maintained correctly.

Spec does not mandate about sending nocp for bap broadcast use case (no real ack from receiver but solely dependent on its irc/pto/vendor-specific-synchronisation etc and other parameters where controller has to keep the PDU buffered).

I feel that the host stack should not have any such limitation to receive synchronous events where it has sent multiple SDUs (for bap broadcast) together but only keeping single instance to process such synchronous events. I am not sure if similar issue could be present in any other transmission apart from broadcast use cases.

Regards,
Nirav

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Thalley]

Thanks for the explanation @nirav-agrawal

I'm still not 100% sure I understand the issue fully, but it seems like the controller is sending multiple NOCP events when a BIG terminates (e.g. if there 4 SDUs sent to the controller, the host would get 4 NOCP events back "at the same time"), and that's seemingly causing issues for your controller?

I assume you are using a different controller than the Zephyr controller, as we don't see this issue with the Zephyr controller (or at least not that I am aware of).

The reason why I mention ACL/CIS is that at least CIS can also send multiple SDUs, and thus would also get multiple NOCP events at the time of a disconnect.

I'm not fully sure why the number of streams matter, as it should be the same amount of events whether you have 1 outstanding TX for 4 BIS, or 4 outstanding TX for a single BIS.

Will also just cc @cvinayak and @alwa-nordic here

[nirav-agrawal]

Thanks for the explanation @nirav-agrawal

I'm still not 100% sure I understand the issue fully, but it seems like the controller is sending multiple NOCP events when a BIG terminates (e.g. if there 4 SDUs sent to the controller, the host would get 4 NOCP events back "at the same time"), and that's seemingly causing issues for your controller?

I assume you are using a different controller than the Zephyr controller, as we don't see this issue with the Zephyr controller (or at least not that I am aware of).

The reason why I mention ACL/CIS is that at least CIS can also send multiple SDUs, and thus would also get multiple NOCP events at the time of a disconnect.

I'm not fully sure why the number of streams matter, as it should be the same amount of events whether you have 1 outstanding TX for 4 BIS, or 4 outstanding TX for a single BIS.

Will also just cc @cvinayak and @alwa-nordic here

Hi @Thalley,

The issue happens during iso-streaming (not BIT terminate). if there are multiple BIS streams in single subgroup sending SDUs, and controller sends NOCP for each BIS in the same subgroup at the end of subgroup event, it causes an issue as Zephyr host only able to process one buffer and would drop others if current buffer process is not complete yet.

This is not a controller issue, NOCP for broadcast SDUs can be sent within ISO interval after BIS subevent or at BIG event. There are some controllers which sent NOCP for broadcast SDU after BIS sub-event, but not all controllers may follow same rule.

In CIS case, remote sends ACK (as per central peripheral), and based on ACK or flush-timeout, local controller updates host for NOCP. So, for MultiStream in CIS case, it would have separate CIS events where remote will ack (or FT) so controller will send NOCP to host for each stream with some time gaps (based on CIS event).

Regards,
Nirav

[cvinayak]

Please send separate PRs for the sample and optimizations to Host subsystem.

[cvinayak]

/* Pool for RX HCI buffers that are always freed by `bt_recv`
 * before it returns.
 *
 * A singleton buffer shall be sufficient for correct operation.
 * The buffer count may be increased as an optimization to allow
 * the HCI transport to fill buffers in parallel with `bt_recv`
 * consuming them.
 */

Based on the comment in the implementation, and the fact that bt_recv control flow has implicit event flow control; I do not agree that this PR fixes any bug. Increasing the buffer count is an optimization at the cost of increased RAM usage, as each buffer can be over "quarter of a kilobyte" in size!

HCI Number of Completed Packets event "can" accumulate the counts for multiple handles and be generated at a frequency at the implementations discretion.