Trotzdem ist die Atmosphäre durch Schweiß etc. sehr aggressiv. Wenn ein Mikrofon in solch einer Atmosphäre einmal ausgesetzt war kann man es wegschmeißen. Das sich der Prozess weiter vorsetzt.
Auch Dynamische Kapsel nehmen die Feuchtigkeit auf.... Schon mal ein altes SM58 aufgeschraubt, das zu sabbern sorgt dafür das es erst komisch klingt und dann das Membran zersetzt.
Mit viel experimentellen Geist, kann man einen Sauna Lautsprecher als Mikrofon benutzen.
Wenn es mal so wäre... Die meisten Art-Net Nodes sind nicht in der Lage 100Mbit/s oder gar 1000Mbit/s zu verarbeiten. Einige schaffen nicht mal 30fps am DMX Ausgang... Schaut man rein weiß man auch warum... Man kann eine Node für 99€ oder auch für 1000€ kaufen. Augenscheinlich machen beide das gleiche, denkt man...
Um 100Mbit/s zu verarbeiten braucht man schon mehr. Klar man kann daran Teilnehmen aber ist nie an der Lage alle Frames zu verarbeiten. Bei TCP/IP spielt das keine Rolle, da sich der Fluss selbst steuert.
Worauf ich hinaus wollte das selbst solch eine MA-Node im Art-Net noch einen guten Job macht..
MA-Net(2) bietet Echtzeit und Frame-Synchronität für bis zu 256 Universen + Rückmeldungen. Davon ist Art-Net weit entfernt... ACN naja ...
Das Problem ist eben das dass MA-NET etwas anderes funktioniert als Art-Net. Was die Nodes aller Generationen übrigens verstehen und somit eingebunden werden können.
Mit den Knackpunkt allerdings dann man Rechenkapazität dafür zur Verfügung stellen muss 
Bei MA nennt sich das PARAMETER...
In diesen Nodes passiert etwas mehr als in einer einfachen Artnet_node -> schraube das teil mal auf und schau rein 
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..
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...
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.
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 ...
Das würde gehen mit dem Schalter vorne stellt man dann die Disknummer ein Das Problem ist nur das du genau wissen muss welche Show auf welcher Disk ist. Oder es gibt eine "Disk auf dem das Verzeichnis liegt und dann jedes mal hintenherum fummeln 
Das mit dem FTP macht dir ein Arduino bzw. RPI ... FTP listet auch Verzeichnisse auf. Das Protokoll ist sehr einfach... Man könnte sogar mit dem Browser/Explorer Daten austauschen. Jeder Browser/Explorer beherrscht FTP ftp://adresse:port alternativ gibt es gute einfache Clients...
Hmm dann per FTP speichern, das dürfte auch die Micro können.
naja was heißt Highspeed ? Die Samlingrate ist für keinen Optokoppler oder Logik ein Problem. Es zeigt nur das in diesem Splittern die Logik und damit die Schaltflanken des Signals sauber sind. . Wenn dieser aber aktiv arbeitet, also das Signal auswertet und neu erzeugt wird dieser mit solch einen Signal nicht arbeiten ... Die besseren Splitter z.Bsp der Firma Soundlight arbeiten so... Oder welche mit RDM die müssen ja zwangsweise den DMX Frame lesen um zu wissen wann die Richtung umgeschaltet werden muss.
Mit dem Trafo klappt das schon, passive Splitter sind auf dem Markt verfügbar. Auch welche die das 75OHM<-> 110 OHM lösen. Im HF Bereich werden noch ganz andere Dinge passiv gelöst....
Also beim Zubehör für die Musiker sind diese noch so ziemlich gängig und wenn man dessen Verkablung sich anschaut muss man sich über Redundanz er weniger Gedanken machen. Es gibt deutlich mehr Bruchstellen als das Digitale Audiokabel, darauf wollte ich hinaus.
Ich kenne nur ein Fall wo kurz vor der VA das Multicorekabel durchgesägt wurde 
. Wenn man so dämliche Mitarbeiter hat kann man dagegen auch nichts machen 
....
Nutzt alles nichts wenn die Switch mit einem schnöden 1,50€ Netzteil versorgt wird. Ich kenne noch keine Switch die min. 10min weiter läuft und dann auch noch dies mittelt das in 10min der Ofen aus geht. Negative Erfahrungen mit Stecknetzteilen hat ja so ziemlich jeder doch liegen sie bei den gängigen Geräten immer bei.
Das mit dem USB verstehe ich nicht taucht der nicht auf ? backup -> lokal muss auch vom USB gehen jedenfalls mit der letzten Firmware... siehe Manual ...
Aufpassen mit dem Displays, du sprichst von USB also wird ein neues Board 500MHZ drin sein. Das läuft mit 3.3V die alten Display liefen mit 5V...
Ist das fiese "Plop" nun endlich weg ? Die Technischen Daten sind er bescheiden... Man beachte das knappe Delay per Channel.... Reicht zur System Korrektur zu mehr aber auch nicht nach 3,5m ist Schluss.
Meist funktioniert es aber Trotzdem, was darunter leidet ist lediglich die Bandbreite und Reichweite. Bei 5Ghz insbesondere die Reichweite...
Nö es wurde in 3 Jahren grundlegend entwickelt, sogar mit Fördergeldern. Außerdem arbeitet Dante im Layer3 (IP) -> AVB Layer 2 (MAC). Also was grundlegend anderes....
https://www.reichelt.de/SMARTSolutions…=3&GROUPID=8262
ist fast das gleiche wie beim Kabelinternet. Alle Teilnehmer teilen sich die Bandbreite. Download per Broadcast, upload per Zeitschlitze.
Bitte löse das nicht mit einen Powerline Adapter. Grundsätzlich wäre dies auch eine Lösung nur diese Dreckschleudern machen bei dir und anderen mächtig Ärger- Bei dir könnte es mit VDSL ärger geben.
Ja das stimmt, sehr schön ! Ich könnte das glatt kopieren für mein Projekt 
. Ne ich denk mir was ähnliches aus...
Nun ja weil ich denke das AVB recht alleine da steht. MIDI,AES50 zu Dante da hat man schon alle Möglichkeiten. Wozu AVB ? die Nachfrage dürfte recht gering sein. Zumal AVB und Dante auf den selben Netzwerk interessant sein dürfte.
Das mit dem Format ist ein Problem der Hersteller die nicht alle Formate unterstützen.
das der eine 8 Kanäle, der andere 16 und der dritte 32 Kanäle in einen AVB Stream gepackt hat, es gab zu viele Varianten beim clocking etc.
Das ist nicht wirklich ein Problem, da im Header immer das Format mitgegeben wird. Auch in den Descriptoren ist das Format ersichtlich und es ließe sich auch umstellen.
Auch die Control Funktionalitäten sind in der 1722.1 festgelegt, nur fast keiner hält sich an den Standard. AES67 usw. hat genau das gleiche Problem das man sich im Stream einig ist aber in der Steuerung der Gerät wohl er nicht.
Wenn man mir die Daten vom Expansionsport zukommen lässt, kann ich ja mal schauen. Die Frage ist eben ob sich das lohnt ? Ich denke er nicht...
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
