AVB in der Theorie super aber die Praxis ist eher bescheiden

  • Wie versprochen wollte ich euch nicht mit jeder Neuigkeit langweilen, also war hier erst mal eine weil pause.


    Der Code hat eine bessere Struktur bekommen und wurde so umgearbeitet das er auf verschiedenen Plattformen lauffähig wäre. Es gab starke Veränderungen Im Code , die ich jetzt nicht im einzelnen abspulen möchte. Jedenfalls ist er wieder ein Stück fixer geworden :) .


    An der API gab es Änderungen was die Json Antworten angeht, Values mit vielen Werten werden jetzt besser angezeigt, siehe unten. Das Betrifft auch die Control Values... Momentan arbeite ich am einheitlichen Errorhandler, hierzu muss man ab und zu den Code nochmal anfassen. Da ergeben sich dann meist auch Optimierungen. Unter Linux bin ich mit dem BpF vom Kernel jetzt grün und es gibt vermutlich April, Mai noch eine Überraschung.... So läuft das Projekt stabil..


  • Also ich möchte ein paar Dinge Posten. Der Controller kann wenn man es es aktiviert sich als eigenes Entity im AVB publizieren. Das ist schon seit einen Jahr vorhanden, aber nur mit dem Deskriptor "Entity" -> Konfiguration 0. Jetzt ist das Entity vervollständigt worden. In Vorbereitung für die versprochene Überraschung. Es wird so sein das man Deskriptoren in ein einem Konfigurationsfile beschreiben kann und das der Entity Core die Entsprechenden Funktionen bereitstellt -> ist aber noch Baustelle..


    Die Verfahrensweise der Control Values wurde überarbeitet. Die Values werden Count,Type,Range werden aus den Daten des Deskriptor geprüft. Man kann dem Entity keine falschen Values übergeben, oder unvollständige. Wie schon seit über 1 Jahren kann der Controller mit allen Typen umgehen. Die weise wie sie im Json dargestellt werden wurde verbessert. Lässt sich einfacher mit Javascript lesen.. Später kann man das Json Objekt einfach per POST senden und somit die Values setzen.

    Es funktioniert natürlich auch mit dem Deskriptoren Mixer,Matrix ! Siehe Bild, da sieht man schon das besser Json Format. Mixer muss man erst mal verstehen :| . Es beschreibt eine Möglichkeit Control values in einer Quelle zu Mischen. Deswegen werden nur Linear Values unterstützt. Das Thema Sources ist ziemlich wirr und ich werde das noch besser da stellen müssen. Sources lassen sich ja schon per HAL verfolgen.


  • Mal was anderes außerhalb dem Controller Thema..


    Mir wurde im Dezember ein Raspberry Pi CM4 https://www.raspberrypi.org/pr…nt=raspberry-pi-cm4001000 mit dem IO Board https://www.raspberrypi.org/pr…ompute-module-4-io-board/ auf den Tisch gelegt.


    Nebst der unsauberen Verarbeitung wird das Board als "Onboard Gigabit Ethernet PHY supporting IEEE1588" beworben.


    Ich habe mir das auch schon denken können und mich schon kurz im Dezember mit beschäftigt. Das geladene Standard Modul für die Broadcom PHY keine Hardware Timestamps, das haben jetzt auch andere mitbekommen und kotzen bei GIT darüber aus https://github.com/raspberrypi/linux/issues/4151 . Das Problem alles bei Broadcom steht unter NDA selbst die Datenblätter. Ein super Grundlage um Treiber zu entwickeln und ich glaube ich nicht das dies die Raspberry Pi Foundation machen wird. Obwohl das eine wichtige Voraussetzung wäre um wie beworben das Modul in der Industrie zu verwenden. Macht keiner Bastelkram bleibt Bastelkram..


    Aber das IO Board hat auch einen PCIe Slot, also hat der Marco eine Intel i210 aufgesteckt einen PTP fähigen Kernel gebaut und mit dem linux PTP Projekt versuche gemacht.


    Um festzustellen das zwar die PHY synchronisiert und es auch gelingt diese Uhr mit dem System zu synchronisieren. Naja fast, denn der Clock vom dem Board ist derart miserabel das dieser stark weg läuft und es mit der Regelschleife im Userspace dann nicht mehr gelingt das die PLL einrastet.


    So ein paar Stunden läuft es dann ist auf einmal Feierabend, warum auch immer. Schaut man sich die Linux AVB Projekte so an ist nichts dabei was wirklich verwendbar ist. SRP,QOS werden von der Konsole aus gesteuert und einen einen IEEE1722.1 Controller gibt es erst recht nicht. Man startet Talker und Listener auch per Hand und hofft das was ankommt. Fazit von 2013 bis heute ist man nicht sehr weit gekommen...

  • 1. Marco, du arbeitest doch auch seit 2014 an deinem Controller. Wo ist der denn? Da brauchts du dich über die Linux Community nicht beschweren. Mal davon ab, dass jemand aus der Community, ohne selbst ein verkaufbares Produkt herstellen zu wollen, die 500$ für die IEEE Spezifikationen hinlegen wird.

    2. Laut den Kommentaren auf der Raspberry Github Seite ist doch mittlerweile ein Hardware PTP Treiber in Arbeit oder sogar schon im Test.

    3. Wenn man Wine installiert kann man auch unter Linux (X85) jeden Windows AVB Controller verwenden. Und ein Controller braucht auch weder PTP noch Trafficshaping.

    4. Üblicherweise benutzt man heute ein AVB Audiointerface mit USB für die Verbindung zum Rechner (Motu AVB Serie, Presonus, RME Digiface AVB). Die Haben alle eine Mischpultfunktion und Controller (zumindest zum Connekten) integriert und sind die ideale Bridge zwischen Comptuter und AVB Netzwerk.

    5. Von Neutrik gibt es ein Modul (Neutrik MINEA) mit dessen Hilfe OEMs eigene AVB Geräte bauen können sollen. Vielleicht gibt das ja einen neuen Schub für AVB.

    Ich, der AVB nur hobbymäßig einsetzt (Motu 16A an Linux Rechner mit i210 https://github.com/Drumfix/avb4linux)) , bekomme natürlich leider keine Doku dazu von Neutrik.


    Gruss

  • Hallo,


    1. Ich beschäftige mich seit 2014 mit TSN und mit dem Controller wurde ernsthaft vor 2 1/2 Jahren begonnen.
    2. PTP ist nicht alles was man für ein TSN fähiges Gerät benötigt. Du beklagst den nicht kostenfreien IEEE Standard. Alles bei Broadcom steht unter NDA nicht einmal ein Datenblatt bekommt man. Extrem schlechte Voraussetzungen für die Entwicklung eines Treibers. Mit der i210 musst du dich ja auskennen, das kann der Treiber von der Broadcom PHY nicht einmal ansatzweise.

    3. Man braucht kein Wine ,Win10 hat ein Linux Subsystem. Außerdem ist das Projekt vom Ansatz her auch auf anderen OS lauffähig. Deswegen ja auch der wechsel zu cmake Im Übrigen Hive lässt sich auch für Linux übersetzen. Wenn du einen Controller mit Benutzeroberfläche suchst.

    4. Der RME Controller ist lustig, weißt du wie dieser funktioniert ? Ohne PC gar nicht, denn dieser läuft auf dem Rechner wo der Treiber läuft.

    5. Kenne ich aber bisher noch keine Hardware gesehen, auch keine Entwicklungsumgebung.


    Nunja es ist eben alles nicht so einfach und ich mit der Meinung das dass Projekt noch nicht so weit ist um es zu veröffentlichen.

    Momentan arbeite ich an einer neuen Flow API. Das Projekt hat auch ein völlig anderen Ansatz und des wird auch so bleiben. Wenn sich keiner findet und mit HTML5 eine Oberfläche baut.

  • Ich will das Produkt https://www.neutrik.com/de/pro…audio/milan-oem-solutions nochmal auseinander nehmen.


    Es kann nur 100MBit/s links -> veraltet und es basiert auf einen Marvell ARM Switch Baustein. Der ARM der da oben ist für die Peripherie . Von Marvell bin ich geheilt und in der Praxis die Kunden sicherlich auch.


    Die Idee war ewt. einen RPI CM4 hierzu zu ertüchtigen. Wenn man die Software schon mal entwickelt hat, diese auf andere Industrie fähige Hardware zu portieren. Soweit die Idee, die Praxis ist dank NDA sehr weit entfernt. Nun bin ich am prüfen ob NXP die bessere Wahl wäre... Der günstige Preis eines RPI CM4 erschien mir als nicht so sehr Risikoreich.

  • Huhu...


    Es gibt mal wieder was neues ;). Die Flow API ist fertig, ich kann jetzt viel besser Flows verwalten. Also alles was um das verbinden von Geräten benötigt wird. Irgendwann mehr dazu...


    Ich bin jetzt dabei mit nochmal Gedanken zu machen die API zu beschreiben. Mich mit RAML und OpenAPI beschäftigt. Nunja mich für openAPI entschieden. Nur leider rendert auch die aktuelle Version nicht so die links wie HATEOAS (Hypermedia as the Engine of Application State) -> HAL. Deswegen muss das auch erst mal drin bleiben.


    Unheimlich Mühselig, aber hier die ersten Ergebnisse. Funktioniert so... Die API wird in einem json oder yaml beschrieben. Durch den Client gelesen und der rendert dann das UI -> rechts auf dem Bild. Das was zu sehen ist wird aus der Beschreibung erzeugt, es ist nicht die Antwort vom Controller ;) .

  • Hmm auch mal wieder Rückschläge. Die Tools hierzu funktionieren nur halb, man kann damit eine simple API sicherlich fix beschreiben. In meinen Fall wird das ganze so derart komplex das keine Sau mehr durchsieht. Wichtige Dinge die es vereinfachen würden funktionieren schon seit Jahren nicht. Ich habe mir die mühe gemacht die Json per yaml zu beschreiben das war auch nicht ganz nutzlos. Ich habe ganz einfach ehrlich gesagt keine nerven herzu mich in dort so tief einzuarbeiten das da was brauchbares heraus kommt. Problematische fragen gibt es einen Haufen und auch keinen der mir sagt ob das überhaupt Sinn macht. Ohne externe Hilfe geht es hier nicht sinnvoll weiter. Aus externen Quellen wird man auch nicht schlau. Im openAPI Projekt sind unglaubliche 450 Issues ! Da Entwickler merken das Dinge fehlen oder nicht funktionieren um ihr Projekt zu beschreiben. Vor dieser Mauer stehe ich auch...

  • So ein Stück Schokolade als Energie Reserve und muss ich da durch. Ich muss die API irgend wie umschreiben. Also weiter mit der openAPI. Ich bin jetzt dazu übergegangen das ganze in kleine Teile zu zerlegen. Was nicht funktioniert im Editor, aber irgend wie doch. Das komplexe ist ich muss jeden Endpoint beschreiben und das sind unheimlich viele. Die Deskriptoren habe ich schon alle beschrieben :) . Hierbei habe ich auch gleich bemerkt was einfach gedacht aber aus Sicht der API schlecht gelöst wurde.


    Warum der Aufwand? Aus dieser Beschreibung kann man mit einem Generator eine Client/Server Bibliothek für fast 30 Sprachen generieren. https://openapi-generator.tech/docs/generators


    Das macht es einfach die API einzubinden.


    Die Erfahrung war nicht umsonst, sie hat auch gezeigt was von der anderen Seite verbessert werden kann. Anbei nur mal ein kleiner Einblick wie umfangreich das ganze wird, es zeigt einen kleinen Teil der Endpoints. Erstmal nur die Methode GET, andere kommen noch.


    Im Grunde und das ist auch das Ziel, diese Beschreibung einzulesen und im Controller mit Variablen zu verknüpfen.

  • Ich hatte einen guten Freund, er war ein zufriedener junger Mann, Lehramtsstudium, nette Freundin ... begeisterter Hobbyangler. Bei Ihm auf dem Klo gab es immer ganz wunderbare Lektüre, den Blinker, den deutschen Karpfenfreund, ein paar Bände Jamiri und Robert Crumb.


    Dann hatte er eine Sinnkrise, die nette Freundin verlassen, ein Informatikstudium durchgezogen und ist heute ein Top-Notch Java Programmierer .... auf seinem Klo liegen nur noch C++ Inside, Linux Weekly & Co. .... sein Leben ist einsam, niemand besucht ihn mehr .... schmeiß dich nicht weg, und mach was Anständiges aus deinem Leben ... sonst führst du irgendwann virtuelle Selbstgespräche in einem Veranstaltungstechnikforum ...

  • Manchmal ist es ok wenn nur ein Sender mehrere Empfänger hat 🤘


    Trotzdem ist der Text von Oton lustig :P

    Privater Account mit meiner persönlichen Meinung.

    Sollte es ein Problem mit meiner Neutralität zu einem Thema geben mache ich das im Beitrag kenntlich. :thumbup:

    http://www.noon.ruhr


    Application Support Engineer - HK Audio

  • Das hier kaum Antworten kommen ist auch dem geschuldet das wir hier in einem Veranstaltungstechnikforum sind :) . Die wenigsten können bei diesem Thema verständlicherweise etwas beitragen. Auch einer deiner Forderungen, wenn man keine Ahnung hat F... halten.


    Ich habe den Thread nun damals hier begonnen und bei 66k Zugriffe kann dies nicht ganz uninteressant sein. Der Austausch findet schon statt aber eben auf anderen Foren und das er zu speziellen fragen.


    Die API zu beschreiben erfolgt auch viel zu spät, denn nur so kann ein außenstehender erkennen welche Fähigkeiten das Projekt besitzt. Der Otto Normalverbraucher kann mit dem Projekt erst mal wenig anfangen. Aber andere könnten mit der Hilfe der API Beschreibung etwas leicht bedienbares bauen.


    Andere Controller Projekte greifen das Thema REST API ebenfalls auf. Das Angebot steht immer, wer es ausprobieren will kann sich gerne melden.