Beiträge von marcoboy

Dumme Switches machen genau das -> sie geben die Mutlicast Trafic auf alle Ports aus. Genau das Problem tritt auf wenn man einen AVB Stream über eine Normale Switch schickt. Die MACs sind Multicast Adressen und die Switch macht genau das -> auf alle Ports Ausgeben..

Schnüffeln . Es gibt ein Problem wenn du einen Mulicast Steam in den Heimnetz anschauen willst. Dein Router hat dann ein Problem die MACs zu zuordnen. Nach außen sieht das Netzwerk die MAC vom Router.

Sie belauschen IGMP Trafic und erfahren wann ein Host einer Gruppe beitritt oder verlässt. So kann er sein MAC Table aktualisieren und weiß wo die Trafic hin muss. Was im schlimmsten Fall passiert ist das die Trafic an alle Ports ausgegeben wird...

Wenn du es nicht aktivierst passiert eben der Schlimmste Fall, es wird an alle Ports ausgegeben. Damit belastet du die Geräte unnötig mit Trafic. TCP/IP Stacks mit Mikrocontrollern lassen sich so leicht lahmlegen, da sie der Trafic nicht gewachsen sind.

Der sender weiß erst mal nicht wer seine Pakete empfängt, die Verteilung übernimmt die Switch. Die Clients teilen der Switch mit welche Pakete sie aus welcher Gruppe haben will. Bei der Version 1 kann sich dieser nicht ein mal abmelden -> Stecker ziehen ..

Wo war jetzt die Frage ? Angst das die Pakete ins Wlan geraten ?

Wenn die Konsole Standard USB Audio Core unterstützt funktioniert es. Auch Linux sollte kein Problem sein...

Mit dem Netzteil wird es schon etwas wenn er zwei davon benutzt... Nur ist das eben so das ab 24V der Preis selbst Open Frame sprunghaft ansteigt. Da macht es schon Sinn per Boost Konverter aus 12V oder 24V die Spannungen zu erzeugen. Das dumme daran ist aber auch das der Strom auf der Eingangseite entsprechend hoch ist.

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..

Das meiste basiert sowie so auf die Standardschaltung des Hersteller, auch das Layout lehnt sich daran an.

Es gibt nur zwei Möglichkeiten.

A: sich ein defektes Eisenschwein oder mit SNT zu besorgen.

B: z.Bsp 24V Input mit einen Boost Konverter zu erzeugen, die negative Spannung liefert dieser gleich mit.

Bei B muss man aber mit Rauschen und Störgeräuschen rechnen, da muss man dann tüfteln um diese zu minimieren.

Es nehme an das es nicht die Möglichkeit gab das Ersatzteillager von A&H zu übernehmen ?

Ich wäre vorsichtig mit irgend einem Schaltnetzteil und würde mir erstmal das Rauschen im Datenblatt anschauen. Dann stellt man fest das die meisten Netzteil für Audioelektronik er ungeeignet sind...

Die Übertragung erfolgte per RS232 im Terminal.. Man musste die irgend wie in den Download Modus bringen und die Datei übertragenen... So ganz genau weiß ich das aber auch nicht mehr...

edit : gesucht gefunden ...

http://www.ks-audio.de/index.php/de-d…d1-397?start=20

Er bezieht sich auf eine Mail vom Vertrieb in dem EOL Ware angeboten wurde...

Zitat von Flugwuppich

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 ..

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

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...

Warum ? Also ich hatte noch kein Gerät in der Hand welches den Standard erfüllte. Es sagt ja niemand das es nicht funktioniert. Laut Standard wäre es kein Problem Hersteller A mit B zu verbinden und es zu steuern. Nur halten sich die Hersteller mehr oder weniger nicht an den Standard. Das führt dann dazu das du zwei Controller Applikationen benötigst oder auch drei .... usw.

Außerhalb von AVB haben andere Protokolle auch kein Problem mit der Switch..

Es gibt ja nicht mal einen Controller der den Standard 100% unterstützt.. Aber daran arbeiten wir bereits . Ich würde mich auch um die Switch kümmern , nur habe ich nur ein Hirn und zwei Hände.

ja auch das Kommando write_descriptor funktioniert ... der base64 String "AA4AAQAAAAAAAAAAAAEAAAAAAAAADg=" ist ein descriptor

Die Response zeig ich aber nicht an, da das Kommando als nicht erfolgreich zurück kam. Laut Standard müsste es die aktuellen Daten zurück liefern -> da das aber kaum einer macht zeige ich sie lieber nicht an ..

So was neues Ich bin fast durch mit dem AECP Kommandos.. Ich habe alle

Security Kommandos umgesetzt ! Somit ist dies der ein zigste Controller der das überhaupt unterstützt. Die Tokens bzw. KEYs müssen als base64 übergeben werden -> https://de.wikipedia.org/wiki/Base64 ... Da die Daten wie schon erwähnt nicht in UTF8 oder reservierte Zeichen enthalten... Ich habe den Xmos Stack so erweitert das dieser mir mit gültigen Daten Antwortet .. Leider ist auch in Wireshark an der Stelle einiges durcheinander geraten ..

https://www.base64decode.org/ -> eG1vcyBmcmlzdCBrZWluZW4gYmFzZTY0IEd1cmtlbnNhbGF0 zum decodieren...

Die Controller Values nehme ich auch als base64 entgegen und gebe sie so zurück. Wenn man 400 Werte mit value=10&value=1.... füllen muss wird das dann doch doof.

Anbei habe ich mal einen Rasbpery Pi und Node Red probiert etwas zusammen zu basteln.. Um einfach mal zu schauen wie gut oder auch schlecht sich das Json verarbeiten lässt... Der Flow fragt ein Value ab und steuert abhängig des wertes eine LED ...

Das hat in der IEEE1722.1 auch seinen Grund. Denn das Format ist bei dem CMD Control GET/SET wird nicht als Parameter übergeben. Um das Format heraus zu bekommen muss man in den Control Descriptor schauen.

Damit ist auch klar das es eigentlich keine andere Möglichkeit gäbe die Daten beim Empfang ohne Kenntnis des Descriptors zu entschlüsseln. Also kommt das als byte Array zurück..

Was für ein Gerät auch nicht schlimm wäre, denn wenn man was setzen will kennt man auch das Format ...

Ich habe jetzt zwei Möglichkeiten, entweder es den Anwender es zu überlassen die Daten so zu arrangieren und diese mir byte weise zu übergeben. Doch Vorsicht ! Ich bekommt die als String UTF8 Kodiert, reservierte Zeichen müssen entwertet werden. Json ähnlich.. Oder den Type auf Binär setzen...

So ich habe das schon so einfach gemacht das man anhand des Formates die Values anhängt und somit das schieben entfällt.

Man stelle sich einen Fader vor und der Client müsse die Daten so aufarbeiten.. Keine wirklich Lösung...

So da bin ich fertig *lol* sämtliche Formate lassen sich jetzt dezimal eingeben ! Allerdings bei der Antwort muss ich noch was umstricken so das man Parameter mit übergeben kann. Der Count der Formate wird auch geprüft

Das mit dem Parametern kann man auch in der REST Auflösen --/{entity_id}/{command}/{desc_type}/{desc_index}/{format}?value=1.999&value=-10.2

Ja im Grunde geb ich dir recht.. Das spielt keine Rolle da das CGI Modul und der Controller auf der selben Maschine laufen. Alles was auf das Netz geht ist klar definiert nach IEEE sonst würdest du den String auch nicht lesen können

In C ist das Wurst und das umformen kann Problem mit Unions machen -> 32bit rein float raus

Wenn du mir das float oder double übergibst muss ich das prüfen denn du kannst mir ja so etwas 1.1999929999299999999299999922229299929 übergeben .. geht noch weiter .... bis die zahl in China wieder raus kommt...

Ich denk darüber nach... was ich vermeiden will das es zu einer unklaren Durchmischung kommt, gerade was die Parameter betrifft. value=hex&value=dezimal

Ja soll offen sein unter welcher Lizenz ist noch unklar...

Noch ein Beispiel mit welchen Problem man zu tun hat...

Die Control values haben ein Format welches im entsprechenden Descriptor beschrieben ist. Dort sind Unterschiedliche Typen (8,16,32,64,float,double..) beschrieben... Beim setzen spielt das Format keine Rolle und taucht auch nicht im Command auf. Das führt dazu das man das Value nicht mehr anzeigen kann, auch nicht schreiben.. Ich muss ja wissen wie es sich byte weise zusammensetzt. Das steht im Descriptor und dann muss man sich die zahl HEX 0x5566 -> value[0]=0x55,value[1]=0x66 zusammen schieben.

So wer jetzt noch mitkommt probiere das jetzt mit float oder double -> bitte.... kleiner Tip https://de.wikipedia.org/wiki/Gleitkommazahl

So ein Käse unzumutbar...

Ich stehe jetzt zwischen Baum und Borke.. Alle meine Values zeige ich HEX an, warum ? Bei einer Typen sicheren Programmiersprache wie Java weniger ein Problem, aber unter C will man schon wissen welcher Wert einen erwartet. 0x00 Bit 0x0000 16 Bit -> nächstes Problem MAC Adressen 0x11777277773 ist was völlig anderes als 11:77:72...

Würde ich jetzt den Control Wert Dezimal entgegen nehmen würde ich das Prinzip verlassen .. Macht es aber einfacher für den Anwender, oder man muss im Client den HEX wert umformen. Irgend wie trotzdem doof... Nunja selbst EQ werte lassen sich setzen ...

Hier mal ein String .... Anhand des Formates wird das dann korrekt an den Controller übergeben..

Ist das nicht genau das was auch als Seminar hier angeboten wird ? Die Frage ist eben was man von solch einen Tag erwartet ? Geht man von unterschiedlichen Wissen der Teilnehmer aus wird es schwierig die Erwartungen zu erfüllen.

Sich ein paar blinkende Ports anzuschauen ist nicht sehr Informativ ..