search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.16k stars 6.22k forks source link

Bluetooth: Audio: return volume in vol_set callback #71614

Open koffes opened 3 months ago

koffes commented 3 months ago

In the struct bt_vcp_vol_ctlr_cb the vol_set callback https://github.com/zephyrproject-rtos/zephyr/blob/b62180261421cb1b62c8954bdeb3148fdfaca541/include/zephyr/bluetooth/audio/vcp.h#L349`

should include the volume. This is available in 'vol_ctlr->cp_val.volume'.

This change will make it a lot easier to cope with absolute volume adjustments.

Thalley commented 3 months ago

@koffes in the future please use the Enhancement template when creating enhancements :)

Thalley commented 3 months ago

We can add the volume in the bt_cap_commander_cb.volume_changed callback as well.

Where it gets tricky, is that this will make the set volume and the set volume offset inconsistent. We can add the offset in the VCP API as well, but for the CAP Commander API returning the volume offset is going to be tricky, as that is a value per device, and thus the callback would have a list of {conn, value}. Ideally the CAP API would be consistent in the behavior and values in the calls and callbacks.

It would not be too hard to do if we added a requirement that the parameters shall be valid for the duration of the procedure (as we do for the GATT API), but I'd like to avoid that (although that would save some stack memory).

Thalley commented 3 months ago

The above may be a non-issue as bt_vcp_vol_ctlr_cb can be registered by the application to get the callbacks directly without passing through the CAP callbacks, so the application may get all the information without relying on the CAP callbacks