Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bluetooth: CAP: Add support for handling ASE errors #79014

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Thalley
Copy link
Collaborator

@Thalley Thalley commented Sep 25, 2024

If we get an error/rejection from the CAP acceptor when
performing the Unicast Audio Start or Stop procedure then
we need to abort the procedure and let the application determine
what the next step is.

fixes #78264

The unicast_stop function is changed to primarily do a
BAP disable instead of a release, with optional
support for releasing the streams once they have been disabled.

This also adds unittests for the procedure which also
allow us to remove the invalid param testing from the BSIM tests.

Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Modify the BAP unicast client callback structure to be a
linked list. The purpose of this is to have multiple listeners
of the unicast client changes and notifications.
This is needed for the CAP initiatior.

Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
@Thalley Thalley force-pushed the cap_initiator_ase_error branch 6 times, most recently from c4a63a8 to 27ee8cb Compare September 26, 2024 11:40
@Thalley Thalley force-pushed the cap_initiator_ase_error branch 3 times, most recently from c9095db to fc21c88 Compare September 27, 2024 11:56
When the CIS for a BAP stream is not connected, we cannot truly
be in the disabling state (the only state the stop operation
can be performed by the unicast client).

The reason for this is that if the CIS is disconnected, then
the ASCS server shall transition to the QoS Configured state
regardless of whether it has received a receiver stop ready
command from the unicast client.

Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
If we get an error/rejection from the CAP acceptor when
performing the Unicast Audio Start or Stop procedure then
we need to abort the procedure and let the application determine
what the next step is.

This change triggered a corner case when connecting to multiple
CAP acceptors as the CAP initiatior that was fixed as part
of this.

Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

LE Audio: CAP Initiator: handle errors from ASCS
1 participant