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.

Ein PTP fähiger Adapter bringt noch kein AVB. Der Apple Core stellt 64 Kanäle zur Verfügung, die bisherigen Adapter für 30€ sind hierzu ausreichend.

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.

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.

So es gibt was zu sehen . Wieder mussten erst mal grundlegende Dinge programmiert werden damit es überhaupt weiter geht.

Die Abfrage der Descriptoren über die REST Schnittstelle funktioniert.. Ich habe es mal übertrieben und 9000 Elemente erzeugt. Daraus ergab sich auch gleich das nächste Problem. Die Browser können mit großen Json nicht umgehen. Das parsen dauert zu lange und der Speicherverbrauch ist extrem hoch auf dem Client. So das Firefox abschmiert . Ab 30000 Elementen wird kriminell da geht nichts mehr.

Aus dem Problem ist dann der Gedanke entstanden Seriell zu parsen. Also immer Stückchen weise und auch die DOM Elemente zu erzeugen. Das kommt dem Umstand zu gute da man ja sonst so lange warten müsste bis das Json komplett geladen wurde. Bei 10MB über das Neuland ist der Anwender vorher gestorben bis er was sieht.

So große Datenmengen entstehen nur bei Start, AVB hat einfach zu viele Informationen und die müssen irgendwie zum Client.

Das Problem Messages System wird damit auch erschlagen. Ich mache einfach ein Json auf was nie endet. Ich sende immer wieder Objekte, die TCP Verbindung bleibt offen. Um die Clients zu zuordnen muss ich mir noch etwas mit Tokens ausdenken.

Merke ! lasse nie einen AVB Stream über eine normale Switch laufen. Die MACs vom MAAP also für den Stream sind Broadcast Adressen. Die Switch macht daraus bitteren ernst. Musik tot -> Alexa "ich kann dich im Moment nicht verstehen" , WLAN zu 5sec Ping.... Böse Gesichter auf allen Seiten

Trommelwirbel ......

ein paar Meilensteine sind gelöst....

- log System -> inkl. Loglevel, Argumentations- Liste usw...

- Notifications System -> Benachrichtigung über Ereignisse -> Gerät kommt/geht, was Empfangen,Timeout etc. -> alle externen Kommandos arbeiten damit. Threads oder auch wartende Anfragen werden darüber benachrichtigt.
- einheitliche json Antwort bei Kommandos -> Gerät und Controller.

- Inflight System inkl. Retry beim ausbleiben einer Antwort. Das Problem mit dem Retry Schleife habe ich gelöst, andere nicht die schraubten das Timeout auf 750ms.

Auf den Bild sieht man wie Anfragen an das Gerät geschickt werden und die Antwort zum Browser als Json zurückgegeben wird. Der Controller Blockiert dabei nicht -> durch notification kommt die Antwort zurück oder ein Fehler ...

So der Mechanismus "IN_PROGRESS" funktioniert nun auch. Der Status sollte nicht auf das Json zurück wirken. Das Gerät erbittet sich damit mehr Zeit. Alle 120ms muss es den Status erneut zurück liefern, sonst ist das Paket als ungültig zu betrachten.

Das passiert wenn man ein entity langfristig per "acquire" für einen Controller sperrt. Genau genommen dessen Descriptor... Um keinen deadlock zu fabrizieren sendet das Entity an den Controller der es gesperrt hat "CONTROLLER_AVAILABLE" wird diese beantworte wird der zugriff verweigert. Antwortet der Controller nicht wird er gewährt. Zwischenzeitlich muss der anfragende Controller bei Laune gehalten werden alle 120ms -> "IN_PROGRESS". Das ist natürlich kaum sinnvoll es einen Client zurückzugeben. Andersherum muss natürlich mein Controller auf die "CONTROLLER_AVAILABLE" reagieren sonst ist die Wurst weg von der Stulle.

kommen wir zum Thema bescheiden zurück. Im Standard steht das wenn man einen Parameter setzt und dies scheitert der alte aktive Wert zurückgegeben werden soll.

Was macht das faule Obst ? Liefert den Mist wieder zurück dem man ihm schickt. Das dumme dabei ist es wäre so einfach gewesen old<->new Parameter im HTML Feld später auseinander zu halten..... Das darf ich jetzt umschiffen...

Mal was neues nicht nur von mir...

RME ist auf den Zug AVB aufgesprungen http://www.rme-audio.de/products/digiface_avb.php noch nicht lieferbar...

Ich wäre für einen Test ja empfänglich inkl. auslese was nicht funktioniert...

Was meinen Controller angeht sind fast alle AECP Commands im Controller implementiert. Was fehlt ist nur die Umsetzung im fastCGI Modul.... 74 Funktionen warten auf mich..