AVB Geräte [RME-Audio]

Auf dem Tisch steht das RME-AUDIO AVB-Tool ein AVB<-> MADI Wandler. Firmware: 1.4.0_v107

Wo soll man Anfangen??? Funktioniert es ? Ja und Nein...

Keine Ahnung wer RME beraten hat jedenfalls ist das Ergebnis war wenig überzeugend.

• kein Link bei 100Mbit/s Ports ??? Warum ??? Das Digiface AVB macht dies doch auch ??? UPDATE: Das Problem lässt sich wohl auf meine Marvell Switch im Testfeld eingrenzen. Was da genau nicht funktioniert muss ich mal schauen. Den Link handelt die PHY unter sich aus und warum das beim Digiface AVB funktioniert und beim AVB-Tool nicht ist mir schleierhaft. Meist sind dir Ursachen beim schlechten Design der Hardware zu suchen. Bei der Switch kann ich mir das sogar vorstellen. Womöglich das dieses Problem auch in der Praxis auftritt, im Zusammenhang mit anderen Geräten.
• ein völlig verstrubbeltes 1722.1 so das dessen beworbene volle 1722.1 Unterstützung zusammen klafft
• sehr lange Response beim 1722.1, wenn man sich wirklich 250ms zeit nimmt
  und es hunderte Deskriptoren abfragt dauert dies sehr lange bis das Gerät im Controller wirklich auftaucht. HIVE braucht 15 Sekunden und fragt nicht einmal alles ab. Jacks und verschachtelte Deskriptoren werden nicht gelesen. Ich brauche 5 Sekunden um alles zu lesen
• bei einem Gerät für 1500€ hat man sich beim Hohlstecker besonders viel
  Mühe gegeben. Marke 1€ -> fällt unweigerlich auseinander
• Das Webinterface ist wiederum nicht schlecht, das Gerät lässt sich schnell einstellen
• Mit dem Display gelingt es auch grundlegende Dinge zu konfigurieren, wenn man den dreh mal raus hat
• Das Gerät ist super als Kaffeetassen wärmer geeignet, man sollte es im Case nicht unbedingt zubauen.

Ich werde mich mal ans Werk machen und RME kontaktieren...

Grundproblem bei den Deskriptoren ist das die base nicht korrekt gesetzt wurde und der ControlType stimmt nicht. So weiß man nicht was man damit anfangen soll. Der Type ist für mich Vendor -> OUI 90-e0-f0 verstehe auch nicht warum sich RME nicht daran hält wenn man die 1722.1 Konformität bewirbt ? z.Bsp um die Phantomspeisung zu steuern wählt RME ein Selektor Value siehe 7.3.5.31 IEEE1722.1-2021/D13 sagt was anderes...

Kleine Entschuldigung kann es geben, es gibt keinen Controller außer meinen wo das auffällt ... ControlBlock fehlt auch und die Signale sind auch irgendwie krumm.

Anbei noch eine kleine Rechenaufgabe siehe Bild vom Control Deskriptor es zeigt die Temperatur in Kelvin Wert 34060 Multipler -2 = 100 = 340,60- 273,15k = 67,45°c -> wunderbar zum Kaffee wärmen ... Multipler muss ich auch anderes anzeigen so mal nebenbei bemerkt... Das kann kein Schwein erraten...

Update:

Die PHY scheint etwas problematisch zu sein. Ich hatte gestern noch 80m Klotz RC5 dran und Link Verluste. Ich weiß im Standard steht etwas mit 83m und der Aufbau ist bewusst grenzwertig. Da bin ich etwas enttäuscht, andere Geräte spielen auch mit 100m Kabel zwischen.

Der Hohlstecker ist er das geringere Problem, der lässt sich mit drehen auch verriegeln.

Hauptproblem ist die PHY die wenig Fehlertolerant ist. Wenn man 80m Kabel zwischen hat und dann am RJ45 vom RME Digiface AVB wackelt ist die Nummer gelaufen. Es reicht das Digiface über den Tisch zu schieben . Nein das Kabel und der Stecker sind ok. Das Problem besteht darin das sich die Werte durch das bewegen sich so verschlechtern das die PHY vom AVB-Tool den Link deaktiviert.

Mir sind keine Geräte, DANTE etc.. bekannt die so derart empfindlich sind... Das bei ein Stream a 8ch mit 48khz.

Ach du meine Güte . RME hat das Kommando GET_TX_CONNECTION völlig falsch implementiert.

Ich hatte ja schon mal erwähnt das ich die Daten prüfe "Bist du WIRKLICH verbunden!?" Nunja schon aber nicht 8 mal mit dem selben Listener. Der kann nur einen Stream Verarbeiten. Da RME das so richtig versemmelt hat denkt mein Code ups das geht so nicht, also Status -> unbekannt.

Was macht dieses Kommando ? Damit lassen sich die Verbindungen abfragen welche der Talker aufgebaut hat. Es könnten hunderte sein, die Daten werden ja durch die Switch kopiert. Der Talker speichert die Daten zu welchen Listener er verbunden ist und man kann sie mit dem Kommando GET_TX_CONNECTION aus dem Talker abfragen. So kann man prüfen ob der Listener wirklich verbunden ist. Denn dieser hat ja auch die Bandbreite reserviert... RME erlag den Tragschluss das dass Feld connection_count etwas mit der Anzahl der Streamports zu tun hätte. Nö es dient als Index und wenn der Talker keine Verbindungen hat liefert er NO_SUCH_CONNECTION zurück.

Zumal setzt RME das Flag FAST_CONNECT welches nie bei einer vom Controller ausgelösten Verbindung gesetzt werden kann. Dieses Flag ist auch schon raus aus aus dem neuen Standard. Es gibt Streambackup Parameter die das viel besser beschreiben.

Meine Ups Liste ist schon reichlich gefüllt... Solche Fehler sind auch praktisch denn man findet so seine eigenen

Update: Erst Lachen dann Fluchen . Weshalb ? Mir kam das komisch vor und deshalb habe ich einfach mal in die MILAN Beschreibung geschaut und Bingo . Das Kommando GET_TX_CONNECTION wird unter Milan nicht unterstützt und man hat sich noch was ganz tolles einfallen lassen. Noch ein Command weg optimiert. Aber das Gerät antwortet trotzdem nicht korrekt.

Man kann einen Milan Listener mit einem IEEE1722.1 konformen Talker verbinden, aber keinen IEEE1722.1 Listener mit einem Milan Talker. Wenn das IEEE1722.1 am Listener richtig implementiert wurde schickt der Talker seinen Stream los, aber niemand hört zu...

Beim Milan kommt das selbe heraus wenn sich 16 Ministerpräsidenten auf gemeinsame Corona Maßnahmen einigen.

Merke verändere nie und wirklich nie von einer International erkannten Gruppe die seit 1963 auf der Welt anerkannte Standards entworfen hat. Es kommt nur Käse bei heraus ! Der wird noch richtig Bitter und birgt erhebliche Konflikte mit der neuen IEEE1722.1.

Merke auch wenn man ein Produkt AVB-Tool nennt und es ist so etwas inkompatibles zum Internationalen anerkannten Standard drin. Dann muss man es auch so nenn -> Murks-Tool. Denn ich habe nichts gefunden wie man das AVB-Tool auf 1722.1 abstellt. Beim DIGIFACE AVB gibt es diese Möglichkeit.

Wenn ich die Ups Liste heraus gebe haben Sie mindestens 6 Monate Arbeit . Mit dem Hinweis auf die 1722.1-2021/D13 welche dieses Jahr als gültige Norm erscheint weitere 6 Monate.

Ehrlich gesagt habe ich schon gedachtet mir die 1500€ zu sparen und das Ding zurück zusenden. Ich kann nicht alles kaufen und andere Menschen ihre Arbeit machen. Bisher hat mir kein Hersteller sein Gerät auf den Tisch gestellt. Für einen Feuchten Händedruck wird mir das zu teuer...

Zumal das Problem mit der PHY so richtig ärgerlich ist. Die meisten Probleme sind vermutlich darauf zurück zuführen das man vieles Dinge nicht hinreichend testen konnte. Oder eben jemand hatte der das nur in Theorie abarbeiten konnte. HIVE z.Bsp zeigt ja die Connection auch an und ich ahne auch warum...

Das connection_count Feld machte im alten Standard schon ärger und führte zu unklaren Verbindungen im Controller. Der neue Standard gab es in dieser Hinsicht eine Nachbesserung, die auch mit alten Geräten funktioniert. So lange sie auch korrekt antworten ... Ihr seht auch noch das alte Formular, in den neuen sind IP Adressen mit drin. Ja IP Adressen ...

Ich musste den Betrag etwas ändern, das Problem ist auf Milan zurückzuführen und das dies trotzdem nicht korrekt implementiert wurde.

Ich werde das Problem das sich Milan und 1722.1 Geräte nicht ohne Probleme verbinden kann lösen. Ich sende einfach das fehlende Kommando aus, so das ein IEEE1722.1 konformer Listener zufrieden ist.Wenn man hat den Ablauf verändert um schneller eine Verbindung aufzubauen. Die aber unsicher ist ob der Stream wirklich steht. Dazu erzeugt man dann Trafic polling, welche auch wieder gegen den Standard verstößt.

Das sich auf gleiche Formate einigt oder auch Vendor basierte Kommandos nutzt im Rahmen des Protokolls ist kein Problem. Wenn man aber einen Internationalen Standard verändert so das diese Inkompatible ist, stellt man sich selbst die Füße.