1 (edited by skioutsoukis 2020-04-07 19:49:10)

Topic: RME Digiface AVB and BSS BLU 805 AVB compatibility


Hello all,

I just got on my hands the Digiface AVB, a very nice device indeed.

The thing is that I bought the device specifically for it to work with a BSS BLU 805 AVB processor and after 5 hours of trying all possible configurations the devices do not appear to get in touch.
I know that the BLU 805 is not 1722.1 capable and this is excactly why a needed the Digiface.
I thought that under the terms "IEEE 802.1 BA compliant AVB Stack" and "IEEE 1722 AVTP" I would be able to capture the BSS 805 stream I/O.
I attach a screenshot showing simultaneously the reported status in Hive, Riedel manager and the RME controller.
In this configuration the Digiface is aknowledged as being the Grandmaster clock, even by the BSS. However no sign of recognition on the RME Digiface occurs.

Am I missing something or doing something wrong here?
Pls advise.

Many thanks in advance

Re: RME Digiface AVB and BSS BLU 805 AVB compatibility

AVB without 1722.1 is not AVB, and not designed to be interoperable with other vendors. Since BSS "AVB" processors can most likely connect to other BSS products, that means that a proprietary variant of 1722.1 is in place to intentionally make it incompatible with other AVB products.
However, since the device is enumerating at least partially in 1722.1 controllers, the 1722.1 implementation of BSS could just be incomplete. Maybe their engineers can contact RME to find out a way to get it up and running, or at least explain to their customers why this road was chosen.
Best regards,

Re: RME Digiface AVB and BSS BLU 805 AVB compatibility

The screenshot you provided is interesting since it shows also alternative controllers (riedel +hive). In the rme controller there is some information missing, not shown, for example the "name", "clock mode", informations about the supported formats and the connections. That probably means that these informations could not be read from the descriptors of the BSS processor.
So first of all I would check if these missing informations show up in the alternative controllers. If this is the case it is likely that an update of the rme controller may fix your issue. It would also be interesting if you could provide a wireshark capture of the enumeration. You toggle the enumeration within the rme controller by selecting "reload" from the menu. The descriptors of all connected devices are read in that case.
You could also try the latest Version 0.9516 (see link)


4 (edited by skioutsoukis 2020-04-09 01:12:00)

Re: RME Digiface AVB and BSS BLU 805 AVB compatibility

Many thanks for your replies

After several hours of testing under different scenarios and configurations I came to the following conclusions:

The inabillity to establish communication is NOT RME's fault. The BSS BLU 805 enumerates but does not provide any descriptors for its streams to be normally identified in 1722.1 environment.
Taking this into account I fear that driver updates will not be able to solve the issue. You cannot force extraction of information which, basically, does not exist (pls look https://ibb.co/x5VNdXQ ).

I contacted BSS and the answer was "you cannot enable and use 1722.1 on the blu805 or blu325.  Implementing 1722.1 is not required for AVNU certification.  The decision was made to not implement 1722.1.  It has been several years, and so far, that decision has not changed.     As it sounds like you have figured out, you can manually assign the static streams but BSS hardware does not support AVDEC"
Well, this is really dissapointing, no doubt. I also expressed this dissapointment in my answer.

It is true that I managed to pass audio by manually "masking" the BSS Tx using stream ids from other 1722.1 enabled devices in the network but this is a ridiculous solution and furthermore not functional as at some point the streams get fuzzy, then you have to reset the devices etc. The BSS is destined to send/receive streams by manually adding the ids to Rx Tx.
The problem is that in an 1722.1 environment where all other devices are 1722.1 enabled, arbitrary modification of the stream ids  is not acceptable in most cases, unless the device's firmware supports this intervention from the controller. At least, my devices don't accept it to be implemented. I will have to modify their firmware (god knows how) thus degrade them to a non-1722.1 status.

Anyway, it was my fault that I believed that somehow the Digiface would be able to capture and manage the BSS streams in terms of the previous 1722 AVTP protocol. Obviously, I was mistaken.

PS: In case you spot at the left upper corner the second "1722.1" right under the "non-1722.1" option of the device, I have to tell you that in fact you CANNOT select it. Even if you try you get rubish messages.