AVB in der Theorie super aber die Praxis ist eher bescheiden

  • Der Xmos Stack ist angeblich zertifiziert. Ich kenne die Kriterien nicht, vermute aber das sich diese er auf den Stream bezieht bzw. grundlegende Eigenschaften.


    Verständlicherweise kann ich mir nicht jedes Gerät kaufen und untersuchen :/. Bin aber offen wenn mir jemand etwas zur Verfügung stellt. Mein Controller Projekt kann aber ein wertvolles Tool dafür werden :). Durch die Open API könnten sich Hersteller eigene Scripte zum testen ihrer Geräte basteln...

  • Ich muss hier einmal etwas Wasser in den Wein giessen: Kein Mensch vor Ort hat die Zeit und die Muße, sich mit derartiger Befehlszeilenlutscherei zu beschäftigen. Deswegen ist Dante im Audiobereich so erfolgreich. Das, was Du Marco hier machst. mag für einige wenige technisch-theoretisch Interessierte von Belang sein, Dein Engagement diesbezüglich auch in allen Ehren. Aber Live haben wir es doch immer mit der Situation zu tun, daß das Bild seit der Digitalisierung dessen dem Ton nacheilt und der Tonmann sich entscheiden darf, ob er das Delay auf die erste Reihe der den Akteur direkt sehenden Zuschauer einstellt oder den Ton auf den am weitest hinten hängenden Screen justiert, womit es in sehr großen Hallen ja wieder passen könnte. Die Videofraktion scheint nicht das geringste Interesse daran zu haben, Latenzen auch nur annähernd als mögliches Problem zu sehen. Steigende Prozessorleistungen werden seit Jahren ausschliesslich dafür genutzt, immer noch höher Auflösungen theoretisch an zu bieten: Entsprechenden Content dafür gibt es dann aber irgendwo zwischen nicht, garnicht und niemals nicht. Und da stellt sich dann irgendwann auch die Sinnfrage, wozu man gegebenenfalls die eigene Leitung auch noch mit einem breitbandigen Videosignal teilen soll, dessen Entwickler offensichtlich bestenfalls autoerotische Erfolge suchen.

  • Also ich finde die Arbeit von marcoboy klasse und notwendig, sodass irgendwer mal AVB nutzen kann ohne dass er Zeit oder den technischen Background hat. Plug and Play funktioniert nur, wenn jemand stellvertretend für Andere durch dieses dunkle und tiefe Tal gegangen ist. Bei Audinate saß bestimmt vor einigen Jahren jemand vor ähnlichen Herausforderungen und hatte vermutlich nicht das Glück seine Erfolge und Misserfolge in einem Forum zu teilen. marcoboy: Hochachtung vor deinem Durchhaltevermögen.

  • Ich muss hier einmal etwas Wasser in den Wein giessen: Kein Mensch vor Ort hat die Zeit und die Muße, sich mit derartiger Befehlszeilenlutscherei zu beschäftigen.

    Dann hast du das Prinzip einer RESTfull API nicht verstanden ;). Ist aber nicht schlimm, das UI -> User Interface ist damit offen. Jeder kann den Controller benutzen wenn seine Software in der Lage ist mit HTTP umzugehen. Du brauchst auch keine Software mehr installieren, ein Browser mit Javascript reicht aus. Hier kann man sogar mobile Geräte berücksichtigen usw..


    Durch die Open API können also auch Hersteller sich eigenen Anwendungen basteln oder den Controller in ihrer Software integrieren.. Schau dir das Beispiel mit Node RED an :), das könntest du mit anderen Konzepten nicht machen.


    Mir der "Befehlszeilenlutscherei" hast du nichts zu tun, das mit Javascript und erzeugt daraus HTML Code 8o..

    Oder der Controller läuft als Backend und oben drauf ein GUI... Oder die Geräte lassen sich per IOT steuern, z.bsp Alexa etc... Gemeinsamer Punkt ist die RESTfull API und die muss durchdacht sein. Die Struktur wird in soweit angepasst das der Client keine Kenntnis von dessen haben muss, er folgt einfach links -> HATEOAS



    2 Mal editiert, zuletzt von marcoboy ()

  • Ich wollte mich auch mal wieder melden :).. Funktionalitäten betreffend des AVBs kamen in dem Projekt kaum was hin zu. Unter der Haube wurde aber kräftig geschraubt..


    - Timer Thread der alle Aufgaben mit Verfallsdatum abarbeitet.

    - Konfigurationsfile für die Applikation

    - logging Funktionen, Ausgabe auf Konsole auf Wunsch in Farbe, File mit Rotation, oder ganz aus..

    - neues Thread Konzept -> schneller


    Die Abfrage über eine Datenbank kommt ! wird wohl MongoDB werden. Diese kann auch ausgelagert werden...


    Ich hätte unter Linux auch http://www.linux-praxis.de/lpic1/manpages/logrotate.html verwenden können. Dann hätte ich aber auch die Konfiguration anpassen müssen und es müsste dauerhaft das Verzeichnis überwachen. Da ich ja auf die Größe schaue müsste, in meinen Code zähle ich einfach die geschrieben bytes mit. Jaja ich weiß stimmt nicht ganz -> Blockgröße vom Filesystem.


    Kurzum die Funktionalitäten selbst umgesetzt ;) .. min 1MB kann man in der Konfiguration setzen..



  • Tadaa der controller kann ACMP -> Geräte verbinden... Allerdings muss ich jetzt mal schauen wie man diese Information dauerhaft so aufbereitet das sich daraus eine Matrix bilden lässt. Ich sprach ja von Datenbank..


    Jetzt bin ich aber doch auf dem Pfad, eine Oberfläche zu bauen... QT scheidet aufgrund der Lizenz aus.. Bleibt nur noch GTK(in C geschrieben).. per Option kann man dann die Oberfläche mit einbauen bzw. die REST API ausbauen ;) . Dem Core ist es Wurst, zum Glück habe ich das vorher schon gut getrennt.


    Bleibt nur noch das Datenhaltungs- Problem. Das gilt es Plattform übergreifend zu lösen...


    Auf dem Bild sieht man wie man per Post eine Ressource anlegt, normalerweise sollte dann ein Objekt zurückgeliefert werden wo der Client den Status abfragen kann -> wir erinnern uns Rest ist Statuslos. Genau da haben wir das nächste Problem das wir lösen müssen ..


    per Delete löscht man die Ressource wieder...

  • Ich hänge mal die Ausgabe der Konsole mit ran. Da kann man schön sehen wie das ganze abläuft.


    Das ganze läuft als Multicast ab, das bedeutet andere Controller können den Verbindungsaufbau mit verfolgen und dementsprechend ihre Daten aktualisieren.


    Der Controller sendet ein connect_rx an den Listener(Emfänger Lautsprecher z.Bsp) dieser sendet ein connect_tx an den talker (sender Mikrofon z.Bsp ) dieser erledigt alles was für den Stream nötig ist und sendet dann ein connect_tx_response an den Listener. Der darauf dann ein connect_rx_response an den Controller sendet.


    Im Hintergrund passiert noch deutlich mehr, Reservierung der Bandbreite, Bildung des Vlan und MAAP -> finden der MAC Adresse für den Stream.

  • :D ich würd das voll gern wertschätzen - die Arbeit die Du Dir damit machst ist echt klasse!!! Leider versteh ich zu wenig von dem Programmierzeux um hier irgendwie mitreden zu können. Ich bin trotzdem sehr gespannt auf das Endergebnis, auch wenn der klassische Endnutzer (wie ich :D ) damit wahrscheinlich eher weniger anfangen kann...

  • pfeiffe mit dem Ergebnis könne wir sehr wohl was anfangen... Marco baut einen Controller für uns, also sowas wie den Dante Controller nur eben für AVB,

    nah am Standard und möglichst Herstellerübergreifend


    er macht quasi das was die Hersteller nicht schaffen...


    wenn ich das richtig verstanden habe


    PS ich hab grad den ganze Thread in einem Rutsch gelesen, mir ist schwindlig... :)

  • Das Problem was sich mir in den Weg stellt sind A: ein Haufen Geräte die nicht das machen was sie sollten, auch Controller wenn ins Detail geht... B: sehr viele Baustellen, HTML,REST,Datenbank, HTTP usw...


    C: das eine Technologie wie HTTP nicht dazu gedacht ist.. Besonders blöd wird es bei der Notification.. Es wo sich der Controller im Gerät registriert und bei Änderungen Benachrichtigt wird. Per HTTP müsste man immer pollen -> also Abfragen, Abfragen.. es sei denn man verlässt die REST API und hält die Verbindung offen...


    HTTP und Javascript hat noch weitere Stolperfallen, die Implementierung ist Browser abhängig. Nicht immer passiert genau das was man eigentlich wollte. Die Baustelle UI per HTTP und Javascript ist riesig... und das Status Problem ist noch nicht gelöst...


    Deswegen jetzt der Gedanke das Projekt zu splitten...


    Den Controller als Dienst und als Brücke zum AVB Netzwerk. Optional speichern der Daten in einer Datenbank. Das UI könnte dann per TCP/IP und DB Treiber sich die Daten aus der Datenbank holen... genau so das fastCGI Modul -> HTTP Schnittstelle.


    Oder man macht es dem IPC Socket einen richtigen Socket... Null Problem und bindet dann das UI mit GTK oder QT gebaut an...


    Ich weiß es nicht ....;(.. Fakt ist eins das eine Software die sich auf MAC,PC Installieren lässt eine bessere Verbreitung findet .. und leider bekommt man gerade unter Win nur mit einen speziellen Treiber Zugriff auf das Layer2. Dieser ist der Gau was die Sicherheit eines System betrifft.


    Und es geht dann genau der reiz der offenen Schnittstelle verloren. Mit der Rest API kann man den Controller sogar per Arduino steuern... Hauptsache das Gerät kann HTTP... Wenn sich Hersteller Scripte bauen können sie ihre Geräte testen.. Alexa,MQTT etc.. geht alles...


    Man kann per Connect sogar wie vorgesehen die stream_vlan_id und flags setzten..

  • Noch ein Hinweis darauf das deine Arbeit sicher gut ist für unsere Zukunft, es gibt noch mehr neue Produkte mit AVB:


    https://adamsonsystems.com/en/…s-new-is-series-offerings


    Was das ganze wirklich pennend macht ist die Milan Geschichte, das sollte einiges verbessern, hilft aber eben bei den schon existierenden Produkten nur bedingt ;)

    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

  • Nunja aber Dante hat es nun auch geschafft Video zu übertragen.. Genau an dem Punkt klinken sich bekannte AVB Controller aus. Weder Sensor noch Video werden unterstützt... Mein Projekt kann das :D.. Allerdings habe ich noch kein Gerät in die Finder bekommen das dies tatsächlich könnte. Gut Sensor wird es im Auto mit AVB wohl oder über geben. Aber soweit ich weiß ist der CAN Bus wohl da noch führend..

  • Nunja aber Dante hat es nun auch geschafft Video zu übertragen.. Genau an dem Punkt klinken sich bekannte AVB Controller aus. Weder Sensor noch Video werden unterstützt... Mein Projekt kann das :D.. Allerdings habe ich noch kein Gerät in die Finder bekommen das dies tatsächlich könnte. Gut Sensor wird es im Auto mit AVB wohl oder über geben. Aber soweit ich weiß ist der CAN Bus wohl da noch führend..

    Gibt es eigentlich schon aus dem Bereich Veranstaltungstechnik Videohardware die über AVB die Videodaten versendet?

    Im Auto wird CAN seit einigen Jahren zwar beharrlich durch FlexRay (bis zu 10 MBit/s, deterministisch m. Zeitslots) und 2-Draht-Ethernet abgelöst, letzteres soll dann Video über AVB ermöglichen. Bislang ist mir nicht bekannt, dass dies irgendwo umgesetzt wurde. Für Videoübertragungen bspw. von der Rückfahrkamera kommen da anscheinend noch propriertäre Protokolle/Formate zum einsatz, teilweise analog (!) bei älteren Systemen.

  • Bislang ist mir nicht bekannt, dass dies irgendwo umgesetzt wurde. Für Videoübertragungen bspw. von der Rückfahrkamera kommen da anscheinend noch propriertäre Protokolle/Formate zum einsatz, teilweise analog (!) bei älteren Systemen.

    Die Kameraübertragung wird afaik immer analog ausgeführt, aus Latenzgründen.

    Was im KFZ Bereich seit einigen Jahren spezifiziert ist ist Milan, quasi die Weiterentwicklung von AVB mit Fokus auf den Automobilsektor. Von einem Automobilzulieferer weiß ich, dass er Produkte auf dessen Basis anbietet (Von Assistenzsystemen bis Entertainment). Mehr darf ich dazu aber nicht sagen.

  • So meine Herrn und Damen.. was bisher geschah..


    Den Code auf Speicherleeks untersucht und Problemstellen beseitigt.


    Dann kam ich auf die Idee, den Webserver in den Controller zu integrieren. Vorher lief das ja über einen externen Webserver mit CGI Modul. Die Kommunikation zwischen dem Modul und Controller funktionierte mit unix sockets.


    Es funktionierte gut, wäre aber nur auf Unix Systemen lauffähig gewesen und von externen Diensten abhängig.


    Kurzum der Entschluss mir eine HTTPD Bibliothek zu suchen und sie in das Projekt einzubinden. Ganz einfach diese Aussage... Es gingen zwei Wochen ins Land um überhaupt die Probleme zu lösen die sich plötzlich auftaten. Das fing schon mal damit an das die das Json in der Art nicht mehr erzeugen ließ.


    Die dann zum Einsatz gebrachte Json Bibliothek brauchte dann für eine Response 65MB speicher.. Ohje 8|.. Nein den Käse kann man nicht verwenden.


    Drei Toiletten Sitzungen + einen Wutausbruch in 3 weiteren Tagen braucht die Lösung des Problem.. Ohne den Code der die Dokumente erzeugt über den Haufen zu werfen.


    In weiteren 3 Tagen schlug ich mich damit herum zu eruieren warum sich die Bibliothek bei falschen GET Anfragen mit Body immer aufhing. Wie man das umgeht bekam ich dann auch heraus.

    Nun müssen die request auf den neuen Code portiert werden...

    Baustelle HTTPD bleibt, Zugriffskontrolle, File API, usw....


    An den eigentlichen Funktionalitäten ergab sich nichts:/.. Dafür startet man den Controller und er ist auf einen Port erreichbar..


    Zwischendurch flog der alte Dell auseinander, Mutti brachte ihr Breitbandinternet mit 1 Woche Totalausfall.


    Ihr merkt es ist einiges passiert...