LE Audio: Add ISO test parameters to the BAP API

[Thalley]

Add support for setting advanced ISO parameters in the BAP API.

Fixes #50950

[MariuszSkamra]

Is the "advanced" term used somewhere in the spec? I'd prefer to stick to the Core defined naming.
I see the parameters that are about to be passed to the HCI_LE_Set_CIG_Parameters_Test are named as "advanced" in this PR. This introduces confusion, as this command should be used for test purposing only to let the controller to choose the parameters.

As per Core 5.3, Vol 4, Part E :
"The HCI_LE_Set_CIG_Parameters_Test command should only be used for
testing purposes."

My feeling is that this shall not be part of public API

[Thalley]

@MariuszSkamra Those are fair points. There has been a user request for using the test commands for more fine-grained control of the ISO channels (some of the fields for the test commands shoul arguably have been part of the "regular" commands in the first place).

The "advanced" term is thus not used in the core spec, as these does use the test commands, but adding "test" fields in a public API for non-test purposes also felt incorrect. The "advanced" term was first used and introduced by #53945 in the ISO API

[MariuszSkamra]

The "advanced" term is thus not used in the core spec, as these does use the test commands, but adding "test" fields in a public API for non-test purposes also felt incorrect.

Yes, because this command is test command. What's the difference in naming it advanced as it's still test command that should not be used except for testing?

[Thalley]

What's the difference in naming it advanced as it's still test command that should not be used except for testing?

It is specifically because we (or rather the user that requested this) do want to use it for other things than testing. The test commands provides additional control of how the ISO channels are configured, which is useful for some advanced use cases where the application want the ISO channels to behave in a specific and deterministic way. Leaving many of these values up to the controller, does not provide the flexibility that some applications require.

While the core spec does state that these command should not be used for other things than testing, it is still allowed.

[carlescufi]

@MariuszSkamra please review

[Thalley]

As discussed, I will provide some alternative naming schemes for this feature

[Thalley]

Other naming options instead of "CONFIG_BT_ISO_ADVANCED"

CONFIG_BT_ISO_TEST
CONFIG_BT_ISO_TEST_PARAMS
CONFIG_BT_ISO_HOST_SCHED_PARAMS
CONFIG_BT_ISO_EXTENDED

@MariuszSkamra et.al. please provide your thoughts on the above

Another alternative is to create a new set of parameter structs and functions for the ISO API to use the ISO test commands, and then change the guard used for the LE Audio API to be something like CONFIG_BT_BAP_XXXX

[fredrikdanebjer]

@MariuszSkamra et.al. please provide your thoughts on the above

My five cents on this is that I agree with Mariusz. Since this clearly is referenced as 'test' in the spec, I think that is what we should continue to use here. If a user requested this, is it far-fetched to assume that the same user is well traversed enough in the spec to know about the test HCI_LE_Set_CIG_Parameters_Test ?

I would vote for either CONFIG_BT_ISO_TEST or CONFIG_BT_ISO_TEST_PARAMS, preferably the latter :)

[MariuszSkamra]

CONFIG_BT_ISO_TEST_PARAMS would suit here IMO

[Thalley]

Will update to use CONFIG_BT_ISO_TEST_PARAMS

[Thalley]

@MariuszSkamra @fredrikdanebjer added a commit to update the naming of the Kconfig option before adding the support for it in the BAP API

[Thalley]

@fredrikdanebjer Please re-approve if you can :)