Summary
For CAP 1.0.1 we have
Section 7.3.2.2:
If a Commander is notified about a change in volume exposed by VCS on one of the Acceptors in the Coordinated Set, then the Commander shall change the volume to the same value on other Acceptors in the Coordinated Sets.
Section 7.3.2.4:
If the Commander is notified about a change in (Volume) mute state exposed by VCS on one of the Acceptors in the Coordinated Set, then the Commander shall change the (Volume) mute state to the same value on other Acceptors in the Coordinated Sets.
Section 7.3.2.5
If the Commander is notified about a change in a (Microphone) mute state on one of the Acceptors, then it shall change the other participating (Microphone) mute states to the same value.
and
A Commander should synchronize the local microphone mute state of a higher-layer application and (Microphone) mute state exposed by the Acceptors.
It is unclear whether these requirements affect ad-hoc sets as well. See https://bluetooth.atlassian.net/browse/ES-29577
Describe the solution you'd like
There are 2 routes to go:
- The CAP Commander itself will automatically apply the same volume and mute values when it gets a notification (thus implementing the shall parts). This adds complexity to the implementation and will require the implementation to keep track of coordinated sets.
- The CAP Commander applications (samples, shell, tests) will do this themselves. This makes the actual implementation simpler, and defers this complexity to the application layer.
https://bluetooth.atlassian.net/browse/ES-29577 may affect how it will work; if ad-hoc sets needs to be handled in the same way as coordinated sets, then 2) is the only option as we cannot keep track of ad-hoc sets in the stack.
Alternatives
No response
Additional Context
No response
Summary
For CAP 1.0.1 we have
Section 7.3.2.2:
Section 7.3.2.4:
Section 7.3.2.5
It is unclear whether these requirements affect ad-hoc sets as well. See https://bluetooth.atlassian.net/browse/ES-29577
Describe the solution you'd like
There are 2 routes to go:
https://bluetooth.atlassian.net/browse/ES-29577 may affect how it will work; if ad-hoc sets needs to be handled in the same way as coordinated sets, then 2) is the only option as we cannot keep track of ad-hoc sets in the stack.
Alternatives
No response
Additional Context
No response