The listener tries to reestablish the connection on its own. To do this, it saves the status. That can't have anything to do with the Clock-Master. In which mode do you operate the Digiface AVB? Remember that Milan sabotaged the connection setup. The devices AVB-Tool and 12Mic cannot switch the Digiface but they can. Operate all devices in Milan Mode.

Dear Marco,

thank you for joining the forum and commenting on the AVB implementation. Please keep these comments in a separate thread, because they are not directly related to the firmware update but to the entire AVB implementation. They deserve a concise title that describes the overall issue, so that other users facing the same issue can benefit from your feedback - which is exactly what this forum is for. It is not a forum to provide work for the RME developers.

Feel free to contact support directly if you come across a problem that is very specific to your usage, so that your findings/remarks get forwarded to a developer to take a look at. This way, ongoing development can benefit from your feedback.

Another forum to discuss details of an AVB implementation is the AVNU Alliance, where developers communicate in a friendly manner and agree on how the standards should be interpreted, used, or even changed (not "sabotaged") in order to allow for interoperability.

Best regards,
Max

This is now implemented and will be available in the next beta.

Because no suitabe standard control type exists.
12Mic and AVB Tool, for example, have standard control types for phantom power, gain and phase invert.
There is however no standard type for High-Z, XLR/TRS select, and Autoset-Gain, at least not that I'm aware of, so we are using a generic "ENABLE" here.
For Gain Group, we do use a vendor specific type, there's just no standard type available that fits the bill.

Right, that bit was missing. Will land in the next beta as well.

The standard clearly states:
"The memory_data TLV field is always length octets in length. For READ TLVs in an
ADDRESS_ACCESS_COMMAND, this field is zero (0) octet filled and ignored"

If the memory_data is left out, i.e. the tlv is too short with regards to the length field, then it is deemed invalid and discarded, hence no response is sent.
But I agree that during development of an ATDECC application or library, it's nice to get some feedback if you send invalid PDUs.
On the other hand you could have just captured the communication between Hive or the Apple AVDECC controller and 12Mic or AVB Tool.
Both controllers are able to show entity logos, so obviously all implementations do agree here.

see IEEE 1722.1 7.3.4.9:

• minimum is zero.

• maximum is the number of presets (it's 16, we have 16 presets)

• 0 as value for current is defined as: "no saved settings are currently active or that the recalled settings have since been modified"

...which is exactly how we implement it. It just doesn't make sense to try to load snapshot 0. So IMHO BAD_ARGUMENTS is perfectly fine here.

You mean name_index? From the standard: "Most descriptors only have one name field, and hence this will normally be zero (0)."
This control is no exception.

If you want to label snapshot though, you may want to re-read 7.4.17.1:
"A MEMORY_OBJECT descriptor of type SNAPSHOT_SETTINGS may have user settable names for each snapshot it contains. If this is the case, then when the name_index
field is zero (0), the name being addressed is the object_name of the descriptor, otherwise it is addressing the name of the index snapshot"
So you have to call SET_NAME on the MEMORY_OBJECT descriptor, not the control!

We do send OPERATION_STATUS on completion of all operations implemented:
- Recall preset
- Save preset
- Erase preset
Are you sure that your controller subscribes to unsolicited notifications in the first place?

May I ask what project you are working on? Some kind of system integration?
I'm happy to hear that someone uses the comprehensive ATDECC interface that we provide!
ATDECC is pretty unique among audio network standards, as it's the most obvious way to implement control in AVB/Milan-Networks.
There is no OSC, OCA, NMOS, AES70, ember+ to choose from, just ATDECC.
And with L-Acoustic's LA_avdecc there are now three open source implementations to choose from! Pretty cool.

I don't see a problem with this approach. Vendor control types that are using the vendor's OUI are well within the standard.
As I said, we discussed for every control if there is a suitable type in the standard, otherwise we assigned a vendor defined one.
If you find a standard control type more suitable, let us know and we will consider your suggestion.

No, there is nothing missing. The use of CONTROL_BLOCKS is entirely optional and for the manageable amount of controls, most of them already grouped by attaching them to external ports, we didn't see any advantage in them. Quite on the contrary, not using control blocks lowers complexity.
Once ATDECC controllers start plopping up where grouping controls using blocks yields a better user experience we might reconsider them.

Judging from the JSON object you've posted, it looks like you've misread/misinterpreted a field in the CONTROL descriptor's PDU.
The field right after "control_latency" is "control_domain", not "control_block".
Controls are assigned to a block using the base_control and number_of_controls fields on the CONTROL_BLOCK descriptor, not by setting the block index on the CONTROL itself.
We are using control domains to assign different access levels to the controls.

I get that it's weird that the controller is not automatically notified about operations he has triggered, but that's what the standard says.
And for maximum interoperability with other vendors, we follow either 1722.1 or the according Milan specifications respectively.

As you are probably aware, the IEEE 1722.1 working group is open to anybody, so it might be a good idea to join the mailing list and propose a behaviour that you think is more reasonable. It will then be discussed and considered for the next revision.

Cool stuff! Nice idea to use Node-RED, as it enables a huge existing ecosystem to use ATDECC interfaces. Quite some people, in this forum too, might be interested in your project!
Do you have plans to make it available to the public soon?

By the way, you are surely using Hive on Mac OS, where it indeed takes forever to enumerate larger AEMs. On Linux it only takes a few seconds as well.

I wanted to point out again that the problem with the wrong base value also affects other descriptors.

{
  "status": "SUCCESS",
  "authenticated": false,
  "locked": false,
  "aquired": false,
  "ownerId": "Unkown",
  "EXTERNAL_PORT_INPUT": {
    "clockDomainIndex": 0,
    "portFlags": "0x0000(None)",
    "signalSourceType": "0xffff(INVALID)",
    "signalSourceIndex": 0,
    "signalOutput": 0,
    "blockLatency": 0,
    "jackIndex": 3,
    "control": {
      "num": 7,
      "base": 0 <- fail 
    }
  },
  "_warnings": []
}

Therefore, as mentioned, it is very difficult at the moment to find the right descriptors that belong to the functional part. Please check all base values not only from the descriptor control

I can also send you a SQLite database of your descriptors. This makes it easier for you to search. I installed the support but don't use it because it's too slow when writing. For now, I'm working on a solution.

Not tested yet, primarily the time depends on the response of the device. The device has 250ms for an answer, with an active stream and traffic shaping this can sometimes take an unusually long time. the device may request even more time.

Their devices respond relatively slowly and they have a large number of descriptors. The Digiface AVB is conspicuously slow.  Christophe will not read all of them, only those that are really needed. Others are read on request. Also, not all descriptors are read under Hive. Jacks, Control in sub and extended descriptors are missing.

An Apple device is read with 9 configurations in less than 1s.

The problem with Hive was that the device was only displayed when it was completely read. It's just a matter of weighing up whether they show it with invalid data or not.

Of course, you can also query the descriptors in parallel. Then they have to hope for the reception buffer and Qos that the device also answers them. However, data bursts are not a good idea, because the 1722.1 traffic should be packed between the stream packets. That's why the payload of these packages is relatively small. So that they can be processed well by the Qos.

In addition, some devices have not implemented a Qos internally. They can disrupt the stream with 1722.1 traffic.

Yes, it's UTF-8, which not only is the standard encoding according to the JSON standard (see https://www.ietf.org/rfc/rfc4627.txt, section 3) but also readily available as type for values in ATDECC.

What you probably mean is that the JSON is escaped, which is indeed the case. This way, the values can be encapsulated as "raw" object data into other JSON objects, which comes in quite handy.

As for the UUIDs: Its native type is u64, which isn't available as type in standard JSON, so we had to choose between encoding as string (and manually parsing every time we need the raw value) or a encoding as array of bytes, which is part of the JSON spec and easily transmuted/casted into a u64 value. Downside is that human readibility isn't good, but that's not something we care about in this descriptor.

Talking about "this descriptor": As you noticed we encode stream states there. The information can be easily collected by reading and combining other ATDECC commands (e.g. GET_STREAM_INFO, GET_TX/RX_STATE, etc).
To optimize for internal usage, we have this descriptor which has this data readily available.
However, it shouldn't be seen as public API, but rather as internal state that is, by coincidence, publicy accessible.

So, to sum this up, I really don't see any reason to rant about our engineering decisions here.