L-Acoustics / avdecc

A set of open source libraries for controlling AVB entities using the AVDECC (IEEE 1722.1) protocol compliant to Avnu Milan Specifications
GNU Lesser General Public License v3.0
89 stars 22 forks source link

CONTROL_SELECTOR_* controls are not implemented #128

Closed Florob closed 1 year ago

Florob commented 1 year ago

Title pretty much covers it. CONTROL_SELECTOR_* controls are not implemented yet:

ReadDescriptorResponse deserialize warning: Unsupported ControlValueType for READ_CONTROL_DESCRIPTOR RESPONSE: 11
[0x480bb2fffed00013] Failed to process READ_DESCRIPTOR AEM response: Unsupported value
[0x480bb2fffed00013] onControlDescriptorResult (ConfigurationIndex=0 ControlIndex=5): The library does not fully implement this command, please report this.

Aside: It is unfortunate that this leads to Hive claiming the device is not IEEE 1722.1 compliant, since this leaves a whole in the descriptor IDs, when in reality it is a shortcoming of the library.

christophe-calmejane commented 1 year ago

I've been working on this for the past few months but it's taking a long time to correctly handle all non-top level descriptors. I've an almost ready version to test if you really need, it will be soon pushed in the beta update channel. Along with supporting SELECTOR it will try to ignore incorrect sequencing if it's something it doesn't understand.

Florob commented 1 year ago

I've been working on this for the past few months but it's taking a long time to correctly handle all non-top level descriptors.

This is slightly orthogonal. While I would be very happy if non-top level (CONTROL) descriptors were supported, this only shows up because CONTROLs on CONFIGURATION are handled. So the issue really is about control_value_types.

I've an almost ready version to test if you really need, it will be soon pushed in the beta update channel. Along with supporting SELECTOR it will try to ignore incorrect sequencing if it's something it doesn't understand.

That sounds promising. I'm not in any particular hurry. However, the log message explicitly told me to file an issue, so here we are.

christophe-calmejane commented 1 year ago

Well, everything is kind of actually linked all together. I first got the non-IEEE device issue when I started handling controls at all levels (the only device I have with controls at multiple levels, also uses a SELECTOR). And that's at this point I discovered the library would incorrectly flag a device as non-IEEE altough it's not the device's fault.