Beiträge von marcoboy

Nunja es ist aber noch weit davon entfernt auf den Anwender losgelassen zu werden. Kompatibilität der Teilnehmer ist nicht garantiert. Der Standard lässt mit Absicht zufiel offen.

http://www.paul-pelletier.com/id30.html

Der Link funktioniert erstaunlicherweise noch....

Eben weil sie meinen zu wissen wie es geht und dann doch schneller fertig sind als gedacht.

Es kommt teilweise darauf an wie man fragt und wem man fragt. Vieles lässt sich auch im Netz finden, wenn man weiß wie und wo man suchen muss. Mit dem Plan ist es aber nicht getan, man muss die Funktionsweise der Baugruppen und Schaltungen schon verstehen. Schaltungsdienste gibt es auch noch heute und diese liefern Pläne in hochwertiger Qualität.

Manchmal liegt es auch einfach daran das man blöde Anfragen von "Leihen" vermeiden möchte. Denn diese führen fast immer zu einen ungewollten Serviceaufwand. Gerade wenn es wieder Puff macht :lol:

Ich Frag mich im Ernst wo hier die Sinnhaftigkeit ist und welchen Bezug es zu AES50 gibt ?

Das ganze zeigt nur wie Robust der Standard ist. Das gegen den DAU der es mit allen unmöglichen versucht zu betreiben und sich freut wenn trotzdem irgend etwas ankommt. Das zudem wenig aussagekräftig ist und nicht von einer gewissen Intelligenz zeugt wie Ethernet funktioniert.

Dann wäre auch bekannt das bei TCP Pakete erneut angefordert werden wenn diese durch falsche Prüfsummen etc. verworfen werden. Das setzt den FCS Zähler noch oben und an diesem kann man Übertragungsfehler erkennen. ethtool -S ethx kann man diesen unter Linux auslesen. Der Linux Kernel ist auch in der Lage Pakete zu generieren und richtig unter Last bricht das ganze zusammen.

Das schöne ist das solche Bastelsachen in der Praxis dann eine ganze Menge Stress verursachen. Mit etwas Glück stören sie dann auch noch andere Dinge erheblich.

AES50 ist aber nicht Ethernet und wie schon erwähnt geht das ganze damit sicher in die Hose.

Also über RG58 fällt ohne Treiber auf Coax aus. Selbst wenn muss man aufpassen das die Phasen vom Clock nicht verschoben werden.
Die XLRs sind ebenfalls Kritisch da hier der Wellenwiderstand nicht eingehalten werden kann. Es kommt an der Stelle zu Reflexionen und Verlusten. Die möglicherweise auch die Phase zum Clock verschieben.

Solche Experimente würde ich nicht anbieten.

wora „Es irrt der Mensch, solang er strebt.“ Johann Wolfgang von Goethe

Du gefragtes nach der Datenrate, diese lässt sich aber aus diesen Informationen nicht ableiten. Dazu brauchst du den Header des Telegramms.

Aus den Bit Zeiten, Header und Häufigkeit des Telegramms ergibt sich die Datenrate. z.Bsp Typ|Status|Samples|CRC .. Die Häufigkeit ist durch die Sampling Rate und die Anzahl der Samples pro Frame gegeben. Dazwischen werden vermutlich die Ethernet Pakete übertragen.

Zitat von "oton"

ich persönlich hätte dich lange entfernt.

Das weiß ich und deshalb ist die Anzahl der Beiträge extrem gesunken. Um eben dich nicht zu sehr zu belästigen. Es zwingt dich auch niemand diese Beiträge zu lesen oder gar zu kommentieren. In einigen Punkten gebe ich dir auch Recht und ich versuche diese zu berücksichtigen.

Du regst dich aber Teilweise noch über Sachen auf die längst Geschichte sind und von anderen Leuten in ähnlicher Form pausenlos ins Forum geblasen werden. Aus den Stimmungsvollen Threads habe ich mich lieber raus gehalten.

Für deinen Blutdruck ist es nicht förderlich pausenlos in meinen Threads nach Fehlern zu suchen. Überließ sie doch einfach ! So wie ich viele Sachen nicht mehr lese oder gar kommentiere. Das ganze nimmt dann seinen gewöhnlichen Lauf nach unten in die Vergangenheit. Das pausenlose kommentieren bringt keinen weiter, schon gar nicht dem eigentlichen Thema.

Mag sein wenn man gerade zu auf solche wartet um so zu kommentieren. Jedenfalls verstehe ich die Möglichkeiten der Technologien trotzdem, die korrekten "ich habe nichts zu verbergen" Fraktion versteht sie weniger. Das ist besorgniserregender als die "ethischen Grundsätze" .

Auch wenn das gesprochene Wort vermutlich bis auf Stichwörter nicht ausgewertet wird erkennt man mit der Analyse der Stimme die Stimmung eines Menschen. Cortana hört alles mit, sämtliche Eingaben werden ausgewertet bis zum letzten Click.

Cortana merkt an der Stimme das du aufs Klo musst und wenn du den Deckel nicht leise runter machst auch das du fertig bist.

Kein Scherz das ist stand der Technologie und diese wird auch genutzt. Schon wenn du unbeliebte Werbeanrufe erhältst werden Daten aus "Big Data" zusammen geführt die Stimme analysiert und dem Call Agenten Produkte angezeigt die er bewerben soll. Ohne das du es mitbekommst wirst du manipuliert.

Es ist einfach erschreckend welche ethnischen Grundsätze mittlerweile dem Profit geopfert wurden.

Ihr habt noch gar nicht über die Hardware gesprochen. Für solche Sachen sind mittlerweile Digitale Kleinpulte sehr gut zu gebrauchen. Die machen den Mix etc. im Studio gleich mit. XR18 oder etwas ähnliches sind dazu hervorragend geeignet und sehr flexibel. Mit dem P16 lässt sich auch das Kopfhörerproblem lösen und jeder kann seinen Mix selbst einstellen.

Das mit dem MAC ist er Ansichtssache, man kommt auch ohne klar. Den Vorteil den Apple eben hat ist das sie die Hardware kennen für die sie ihre Sachen Programmieren. Nicht nur das Sie kennen auch ihre Anwender ganz genau, MS$ hat das mit WIN10 getoppt die wissen wann der Klodeckel nach unten klappt.

Das geht mit dem xmos Core auch, Problem hier dabei ist die Bandbreite. Diese sind relativ hoch und erfordern ein entsprechendes Netzwerk. Die dort gezeigte Anwendung erfordert einiges an Infrastruktur die einiges kostet.

edit:
Das Open AVB Projekt habe ich erst mal abgebrochen aus Zeitmangel.

Die Intel i210 Netzwerkkarte hat sich leider als sehr problematisch erwiesen. Es gibt Probleme mit dem Kernel Treiber, der pcie bridge und vermutlich auch mit einen Bug im Bios des Testsystems. Somit ist die Karte nicht benutzbar, jedenfalls nicht mit dem alten PC. Der Link bricht bei jeden Datenverkehr ab.

Positives gibt es von Marvell, der ExtraNet Zugang wurde mir gewährt :-D. Dadurch wird es leichter sein gewissen Dinge in der Switch in Angriff zu nehmen.

So unter Linux bin ich in der Lage die Endpoints per 1772.1 zu steuern.

Benutzt wird die oben erwähnte Library. Die Switch läuft jetzt eigentlich ganz gut, problematisch ist nur das dass freigeben der Reservierten Bandbreite offenbar beim Disconnect nicht immer gelingt. Meine Idee wäre diese ganze Controller Sache auf ein Device auszulagern und dieses per HTTP mit Ajax/ Javascript zu steuern. RPI fällt aus der hat gerade durch eine defekte SD Karte multiples Organversagen. Genau deswegen baue ich so etwas auch nicht in Museen etc, ein. Außerdem hängt das Ethernet am USB.

Vorteil wäre das man die Geschichte mit jeden Browser nutzen kann und damit auf fast allen was Javascript unterstützt. Da keine libcap benötigt wird somit auch sicher.

Ich habe mir mal eine PTP fähige Intel Karte besorgt, den Rechner für das testen muss ich aber noch bei Gelegenheit zusammen schrauben. Mal schauen ob wir dem linux PC einen Stream entlocken können.

Es gibt noch ein Schmankerl eine Audio Patchbay.

Anbei das was mit Dante nicht geht Der Stream wird zurück gesendet und per Lautsprecher abgegriffen.

Neuigkeiten, die Kontakte über den Teich wurden wiederbelebt heute morgen war der neuste Treiber der NIC-1 von Echo Digital Audio im Postfach.

64ch Channels In/Out verteilt auf 8 Listener/Talker a 8 Channels.

Das einzige was immer noch nicht funktioniert ist das der Treiber die Streams nach außen zur Verfügung stellt. Heißt mit dem AVB Device Enumeration, Discovery and Control ist der NIC-1 nicht steuerbar. Somit ist es nicht möglich zwei PCs zu koppeln.
Streams können nur vom der Streamware Software aus initiiert werden. Die Sache hat auf Anhieb funktioniert da ich die Switch mittlerweile mehr unter Kontrolle habe :wink:

Gut sind auch die Möglichkeiten des Loggings. Die Größe des Puffers lässt sich einstellen und Filtern.

Als Recording/Playback System mit 64 Kanälen wäre das System sofort einsetzbar.

So ich bin jetzt im Besitz der jeweiligen Standards und ca. 320€ ärmer.

Die Erkenntnis ist gereift das man ohne diese Paper im Nebel herum stochert und ziemlich Sinnlos Zeit damit verbringt herum zu raten was falsch oder richtig ist.

Ich bereue das ich mich nochmals mit Thema befasst habe. Die Switch ist immer noch eine kleine Katastrophe, so wirklich funktioniert sie nicht. Zu mindestens nicht auf Anhieb. Mit etwas eingriffen kam Bewegung in die Sache. Wenn man die Flusskontrolle einschaltet kommt ein Segmentfault. Böse Böse wenn der Kernel so etwas abfangen muss wenn man ungesichert auf Speicherbereiche zugreift die ungültig sind. Das gute ist das der Kernel in dem Moment die Hosen runter lässt und das Register offenbart wo es das Problem gab :lol:

Das Webinterface ist zwar extrem gering bietet aber die Möglichkeit des Firmware update, was in der Vorversion ist etwas heikel ab lief. Ob es funktioniert keine Ahnung Alles was AVB Betrifft ist direkt in den Kernel eingebaut worden, keine Module. So das es recht schwierig ist hier irrend welche Ursachen zu suchen. Ob es eine Möglichkeit gibt den entsprechen Code gesprächiger zu machen keine Ahnung. Dokumentation gibt es zu dieser Switch aufgrund des Lizenzmodels nicht. Auf all diese Dinge klebt ein großes Pflaster.

Ich weiß nicht vor was Marvell mehr Angst hat? Das es einer klaut oder zum laufen bringt.

Der Hono AVB Controller funktionierte so halbwegs. So sieht das aus wenn was zu sehen ist Ich habe mal ein Multicast Stream geöffnet. Ob aus dem DSPforYou Board was raus kommt weiß ich nicht da ich mir den Aufwand sparen wollte einen DA Wandler ran zu fummeln.

Das Problematische all dieser Controller ist ihr Prinzip. Sie schnüffeln die Daten Roh ab und werten sie dementsprechend aus. Die Lib WinPcap ist aus sicherheitstechnischer Sicht der reine Horror. Da jedes Paket ausgewertet werden muss verbraucht dies auch ordentlich CPU Zeit.

Ich hätte so eine Idee wie man das besser macht und vor allen sicherer;)

edit:

etwas weiter, mit der Faust in die Tür klopfen und man kommt vorwärts.

Den externen AVDECC Controller braucht man nicht unbedingt es ist ein Client oben auf der Switch. Mit etwas JavaScript bzw. AJAX lässt sich solch ein Controller auch auf der Switch realisieren. Das geht aber am einfachsten wenn man selbst CGI Programme schreiben kann die diese Register auslesen. So muss man sich mit dem gegebenen zufrieden geben und die Ausgabe von der Konsole umleiten.

Register kann ich auch auslesen aber ich brauch das Vectortable und was der Inhalt bedeutet. Genau hier liegt das Problem..... Ich warte ja noch auf einen Whistleblower der mir einen Umschlag in den Briefkasten steckt :roll:

wieder edit was bisher geht:

Switch:
gpios schalten im Sys Filesystem
i2c
i2s in Arbeit ... aber irrend etwas ist mit dem Kernelmodul nicht ok. .. dauert
PTP konfigurieren und 8KHZ Referenz an die PIO zuschalten

Wenn wir weiter machen kommt Post vom Anwalt :shock:

was ich nicht habe ist die toolchain Das könnte man aber hinbiegen in dem ich meine eigene baue und exakt die gleichen gcc, shared libs. Ohne bleibt einen nur die bash oder pyton :roll:

Was sagte die Hausfrau ! "Keine warmen Dinge in den Kühlschrank stellen ! " Die Gefahr das Wasser Kondensiert und sich Eis bildet wäre äußerst unangenehm für den Verstärker. Zumal fraglich ist ob der Kompressor es überhaupt schafft die Wärme abzuführen.

Nebst das diese für Kurzzeitbetrieb gebaut sind, also abschalten wenn diese zu heiß werden.

garnichts.. oder hast du von C programmieren Ahnung ? Vor allen mit Xmos MCU und dessen Eigenarten ? Die Firmware die da wahrscheinlich drauf ist könnte sehr alt sein. Die Switch ist closed dank Marvell und basiert auf den selben Standard Design wie Motu. Wenn du die aktuelle Firmware da drauf spielen willst musst du die Hardware Konfiguration im Projekt anpassen. Das AVB Projekt von Xmos ist für dessen Demoboards gebaut.

Vorsicht mit der Switch ! Die Chinesen wahren so schlau die 5V Versorgung direkt auf wichtige Bauteile zu führen. Bei den ganzen Stecknetzteil durch einander waren da bei mir schon mal 12V drauf -> total schaden .