Closed max24192 closed 1 year ago
Hi,
1722.1 do indeed impose inputs before outputs, which explains the AEM validation failure.
This is defined in IEEE1722.1-2013 §7.2 Descriptors, and was confirmed during a public 1722.1 call.
AEM uses an addressing hierarchy of 16-bit indexes, allowing a maximum of 65536 of each type of
descriptor. Indexes start numbering at zero (0) and increment through to the last of that type of descriptor
with no gaps in numbering. Descriptors are numbered per Configuration with the index resetting to zero (0)
with each Configuration.
For descriptors that can appear at multiple levels of the hierarchy, such as the CONTROL descriptors, the
numbering starts at zero (0) at the entity (CONFIGURATION) level and proceeds through the hierarchy as
it is encountered—that is, any Controls at the Unit level of the next Unit are numbered next, followed by
any Controls in the Stream Input and Output Ports, then the External Input and Output Ports, and then the
Internal Input and Output Ports. This is repeated for the next Unit. Units are traversed in increasing
descriptor index order with all of the AUDIO_UNITs first, followed by the VIDEO_UNITs and then the
SENSOR_UNITs.
This text was a little bit clarified in the latest rev of 1722.1 but might still cause confusion ;)
For clarification, this behavior is required because no index are stored in the official aemxml file format (nor in Hive's aem json format). This means that the file loader will create indexes as it reads them from the file, and they must be identical to the ones from the device when loaded from file.
I planned on checking validity when a device announces itself on the network (see https://github.com/L-Acoustics/avdecc/issues/80) but couldn't work on it yet.
The audio descriptor's numbering of the entity that causes this are numbered like this:
Creating a full network dump fails with the message:
Invalid Audio Descriptor Index: 16 but expected 0
I can't find anything in 1722.1 (7.2) that would require that the counting must commence with the inputs rather than the outputs. Is this a bug or did I miss something in the standard?