AVB in der Theorie super aber die Praxis ist eher bescheiden

  • Was sind da so für Geräte im Einsatz ?


    Im Audio/Video Stream funktioniert das bestimmt. Wo es spannend wird ist beim Control Stream, also womit Meter Daten, Gain etc. übertragen werden. Da gibt zwei Möglichkeiten -> A: IEEE(Norm) B: Vendor


    B: macht Sinn wenn man nicht will das andere die Geräte mit einbinden und Funktionalitäten in diesen steuern. Zumal müsste das Gegenstück in der Lage sein diese zu verarbeiten.

  • Die Sache ist nicht eingeschlafen ;).. Ich komme mit dem Konzept voran, es hat etwas gedauert sich etwas auszudenken die descriptoren zu speichern. Die Bibliothek ist hier nicht zu gebrauchen. Alle Dinge die Daten erzeugen können sind schlicht weg nicht implementiert. So gesehen ist die Bibliothek relativ nutzlos, da weder Files gelesen noch erzeugt werden können. Es dauert eben sich Gedanken zu machen wie man solche Datenmengen effizient speichert und hinzu noch parallel aus den Geräten ließt.


    Die Web Anbindung wird wohl auf Angular basieren und mit einer lokalen Datenbank. arbeiten. Damit nicht jedes "click" event auf der Oberfläche Trafic erzeugt. Uneinig bin ich noch ob das mit REST API -> polling oder per MQTT funktioniert. Also per Websocket des Protokoll wechseln.

  • Wir haben in zwei Kirchen je ein AVB-Netzwerk auf Biamp-Tesira-Basis im Einsatz. Null Problemo. Spannend würde es, wenn ein Presonus-Mixer nun in das Netzwerk eingebunden werden könnte. In Ermangelung eines solchen kann ich das allerdings nicht austesten :(

    Wenn Du spezifizierst, welche Generation dich interessiert, könnte ich gf. aushelfen.

  • Ein fancy neuer Name und endlich mal Absprachen unter den Herstellern damit AVB Geräte auch miteinander reden können.

    Ich finde es in der heutigen schnelllebigen Zeit schon spannend wie langsam das voran geht, aber es gibt ja noch den Spruch „was lange währt...“


    Also milan ist quasi die Einigung auf gewisse Standards zur AVB Implementierung für Pro-AV Geräte.

    Bisher gab es da noch viele Inkompatibilitäten, z.b die Anzahl der Audio Kanäle pro Stream ist bei Jedem gerät anders, der clock ist manchmal fest einem Stream zugeordnet oder extra, all solche Dinge werden jetzt geregelt.


    http://avnu.org/Milan/


    bin mal gespannt ob audinate dann doch noch auf den AVB Zug aufspringt... zuerst wollten sie ja, dann wieder nicht...

  • Warum ? Genau die das meiste zeug verkaufen sind nicht dabei...


    Gerade mit dem 2/2 Interfaces bringen bringen sie genug Geräte auf den Markt. Da kann mal schauen wie sich das Lizenznehmer Konzept auszahlt. Erst verkauft man die 2/2er Entwicklungskits an dritte um zu schauen wie sich das verkauft ohne Risiko, um dann doch eigene Interfaces auf den Markt zu werfen.


  • Ich bin mit meinen Controller ein Stück weiter ... Das Konzept für die Rest API steht und funktioniert. Man sieht ein Json welches die IDs enthält. Soviel Geräte gibt es natürlich nicht ;) aufgrund des MAAP nur 256... Ich habe auch mal 50000 Results übergeben, dann bricht der Json Parser in Firefox zusammen :(. Der Stack hat das aber in 40ms drüben :) .


    - load Balance der CGI Module

    - IPC Kommunikation zwischen den fastCGI und dem Controller

    - Rest API -> gibt json zurück

    Dieses Json lässt sich dann in Javascript recht einfach verwenden und daraus kann HTML Code dynamisch erzeugt werden. Ob ich lokal eine Datenbank aufsetze ist nicht nichts so sicher. SQLite hat es nicht ins HTML5 geschafft und ist Lizenz rechtlich problematisch. Wie alle Datenbanken ... Auch das speichern von Daten im Hintergrund begeistert viele Browser nicht und die Menge ist recht begrenzt.

  • Marco vielleicht bin ich ja der Einzige der diese Posts hier im Faden von Dir teils nur sehr begrenzt versteht. Interessant find ichs aber glaub ich schon was Du da machst - könntest Du für die Programmierlaien unter uns mal in aller Kürze erklären was genau Du da grad bastelst und was das am Ende können wird? :P

  • Macht nichts, es ist ja auch ein Paforum :).

    Die Idee war folgende, einen AVB Controller zu programmieren der sich ausschließlich mit dem Webbrowser bedienen lässt.


    Der eigentlich Core läuft auf einer Switch oder anderen Device.


    Der Vorteil dessen ist es läuft mit jedem Browser und durch die Rest API können andere Programme anbieten die den Controller ebenfalls ansprechen. Oder auch IOT Gerät, Buttons, Alexa usw.


    Die Methode ist zumal Sicher und man kann die Geräte von außen Verwalten.


    Das ist das eigentlich Ziel :/. Die Aufgabe ist aber nicht so wirklich einfach...

  • Nö.. Die entwickeln ja Hardware und genau das in Hardware zu gießen wollte ich eben nicht.


    Dazu müssten sich die Firmen erst mal einigen werden und da sitzen welche bei die für einen Controller 700€ wollen. Andere funktionieren nur mit ihren eigenen Material, was äußerst förderlich ist wenn man y mit x verbinden möchte. Eine gemeinsame Open Source Projekt wäre denkbar. Über Plug-Ins könne man dann Hersteller spezifische Funktionen nachladen oder sie in eigenen Softwareapplikationen einbinden.


    Davon ist man aber extrem weit weg.. Auch vom IOT Thema usw. da der Standard ohne Rücksicht auf kleine Geräte gebaut wurde. Es wird ein Vermittler benötigt, der eben die AVB Funktionalitäten mit einer einfachen API zur Verfügung stellt.



     


  • Was ich noch dazu sagen wollte ist, wir sollten darüber reden wenn wirklich etwas benutzbares vorliegt ;). Das könnte noch 2-3 Monate dauern bevor noch ein paar Meilensteine gelöst wurden.


    Einer wäre das Status Messages System, hier geht es darum Aktionen abzuarbeiten die nicht synchron ablaufen können. Damit meine ich das man nicht immer sofort eine Antwort aus dem Netzwerk erhält. Bei einigen Mechanismen kann es bis zu 4500ms dauert, so lange kann ich eine Anfrage nicht warten lassen. Javascript läuft im Browser synchron, das heißt es gibt keine Threads der Browser blockiert so lange bis die Antwort vorhanden ist.