Beiträge von marcoboy

Eigentlich denke ich schon das das NT eine PFC hat.. ich kann mich nur nicht überwinden das Teil in die Werkstatt zu tragen.. So lange das Teil nicht qualmt ist mir das egal...

Also alles über 1A ist völlig abnormal und bei solch einer kleinen Stufe erst recht. Selbst wenn man das DSP Board hinzu rechnet.

Ist der Leerlaufstrom mit oder ohne Last ??? Mit Last würde sich sofort den Lautsprecher abklemmen. So HF auf deine Lautsprecher sind nie gut. Dann hat der Filter ein Problem und du einen Mittelwellensender. Vom EMV war die Stufe ja sowie so schon krass und ein Fall für die Bundesnetzagentur.

Damit war gemeint das man an die Messpunkte bei vielen Geräten schlecht heran kam. Nicht das die Bauteile nicht verfügbar wären.

Es gibt noch einen Indikator -> der Netzstrom dem die Stufe ohne Signal auf nehmen sollte. Das steht meist immer im Datenblatt. Daran lässt sich auch das hoch laufen des Ruhestromes beobachten. Wenn beim Einschalten 500mA auftreten und nach 10min 3A ist was faul....

Meist kommt man an die Bauteile auch nicht mehr heran. Deswegen gibt es hierzu oft keine Angaben wo und was zu messen ist. Du kannst den Strom in der Regel nicht so hoch drehen das etwas kaputt gehen könnte. Wenn kein defekt vor liegt... Heißt.. er läuft weg, lässt sich kaum oder gar nicht verstellen...

Kurz: eigentlich bedarf es da keine großen Erklärungen .

Das Ist kein Wunderwerk 10Khz drauf mit Last und den Pegel so weit reduzieren bis man die Übernahmeverzerrungen sieht. So weit den Ruhestrom hoch drehen bis man keine mehr sieht. Noch mal warm werden lassen schauen -> fertig. Voraussetzung ist aber das kein defekt vor liegt....

Ich musste den Betrag etwas ändern, das Problem ist auf Milan zurückzuführen und das dies trotzdem nicht korrekt implementiert wurde.

Ich werde das Problem das sich Milan und 1722.1 Geräte nicht ohne Probleme verbinden kann lösen. Ich sende einfach das fehlende Kommando aus, so das ein IEEE1722.1 konformer Listener zufrieden ist.Wenn man hat den Ablauf verändert um schneller eine Verbindung aufzubauen. Die aber unsicher ist ob der Stream wirklich steht. Dazu erzeugt man dann Trafic polling, welche auch wieder gegen den Standard verstößt.

Das sich auf gleiche Formate einigt oder auch Vendor basierte Kommandos nutzt im Rahmen des Protokolls ist kein Problem. Wenn man aber einen Internationalen Standard verändert so das diese Inkompatible ist, stellt man sich selbst die Füße.

Es ist schlicht weg unmöglich Dante usw. über Wlan zu übertragen. Auch wenn nach oben hin alles gleich ausschaut... Der IP-Frame ist im WLAN nur eingebettet und die Standards unterscheiden doch erheblich. PTP ist aber mit Wifi6 nicht zu weit entfernt ;). Also grundsätzlich sucht man nach Lösungen heutigen Anforderungen gerecht zu werden.

Wenn ich die Ups Liste heraus gebe haben Sie mindestens 6 Monate Arbeit . Mit dem Hinweis auf die 1722.1-2021/D13 welche dieses Jahr als gültige Norm erscheint weitere 6 Monate.

Ehrlich gesagt habe ich schon gedachtet mir die 1500€ zu sparen und das Ding zurück zusenden. Ich kann nicht alles kaufen und andere Menschen ihre Arbeit machen. Bisher hat mir kein Hersteller sein Gerät auf den Tisch gestellt. Für einen Feuchten Händedruck wird mir das zu teuer...

Zumal das Problem mit der PHY so richtig ärgerlich ist. Die meisten Probleme sind vermutlich darauf zurück zuführen das man vieles Dinge nicht hinreichend testen konnte. Oder eben jemand hatte der das nur in Theorie abarbeiten konnte. HIVE z.Bsp zeigt ja die Connection auch an und ich ahne auch warum...

Das connection_count Feld machte im alten Standard schon ärger und führte zu unklaren Verbindungen im Controller. Der neue Standard gab es in dieser Hinsicht eine Nachbesserung, die auch mit alten Geräten funktioniert. So lange sie auch korrekt antworten ... Ihr seht auch noch das alte Formular, in den neuen sind IP Adressen mit drin. Ja IP Adressen ...

Ach du meine Güte . RME hat das Kommando GET_TX_CONNECTION völlig falsch implementiert.

Ich hatte ja schon mal erwähnt das ich die Daten prüfe "Bist du WIRKLICH verbunden!?" Nunja schon aber nicht 8 mal mit dem selben Listener. Der kann nur einen Stream Verarbeiten. Da RME das so richtig versemmelt hat denkt mein Code ups das geht so nicht, also Status -> unbekannt.

Was macht dieses Kommando ? Damit lassen sich die Verbindungen abfragen welche der Talker aufgebaut hat. Es könnten hunderte sein, die Daten werden ja durch die Switch kopiert. Der Talker speichert die Daten zu welchen Listener er verbunden ist und man kann sie mit dem Kommando GET_TX_CONNECTION aus dem Talker abfragen. So kann man prüfen ob der Listener wirklich verbunden ist. Denn dieser hat ja auch die Bandbreite reserviert... RME erlag den Tragschluss das dass Feld connection_count etwas mit der Anzahl der Streamports zu tun hätte. Nö es dient als Index und wenn der Talker keine Verbindungen hat liefert er NO_SUCH_CONNECTION zurück.

Zumal setzt RME das Flag FAST_CONNECT welches nie bei einer vom Controller ausgelösten Verbindung gesetzt werden kann. Dieses Flag ist auch schon raus aus aus dem neuen Standard. Es gibt Streambackup Parameter die das viel besser beschreiben.

Meine Ups Liste ist schon reichlich gefüllt... Solche Fehler sind auch praktisch denn man findet so seine eigenen

Update: Erst Lachen dann Fluchen . Weshalb ? Mir kam das komisch vor und deshalb habe ich einfach mal in die MILAN Beschreibung geschaut und Bingo . Das Kommando GET_TX_CONNECTION wird unter Milan nicht unterstützt und man hat sich noch was ganz tolles einfallen lassen. Noch ein Command weg optimiert. Aber das Gerät antwortet trotzdem nicht korrekt.

Man kann einen Milan Listener mit einem IEEE1722.1 konformen Talker verbinden, aber keinen IEEE1722.1 Listener mit einem Milan Talker. Wenn das IEEE1722.1 am Listener richtig implementiert wurde schickt der Talker seinen Stream los, aber niemand hört zu...

Beim Milan kommt das selbe heraus wenn sich 16 Ministerpräsidenten auf gemeinsame Corona Maßnahmen einigen.

Merke verändere nie und wirklich nie von einer International erkannten Gruppe die seit 1963 auf der Welt anerkannte Standards entworfen hat. Es kommt nur Käse bei heraus ! Der wird noch richtig Bitter und birgt erhebliche Konflikte mit der neuen IEEE1722.1.

Merke auch wenn man ein Produkt AVB-Tool nennt und es ist so etwas inkompatibles zum Internationalen anerkannten Standard drin. Dann muss man es auch so nenn -> Murks-Tool. Denn ich habe nichts gefunden wie man das AVB-Tool auf 1722.1 abstellt. Beim DIGIFACE AVB gibt es diese Möglichkeit.

Was auch noch kurios war das ein Lötkolben und so diverse Ersatzlautsprecher,Stecker zum Standard gehörten was man mit sich führte. Oft auch brauchte, teilweise war ja das Zeug selbst zusammen gebastelt und damit auch Fehleranfällig.

Der Hohlstecker ist er das geringere Problem, der lässt sich mit drehen auch verriegeln.

Hauptproblem ist die PHY die wenig Fehlertolerant ist. Wenn man 80m Kabel zwischen hat und dann am RJ45 vom RME Digiface AVB wackelt ist die Nummer gelaufen. Es reicht das Digiface über den Tisch zu schieben . Nein das Kabel und der Stecker sind ok. Das Problem besteht darin das sich die Werte durch das bewegen sich so verschlechtern das die PHY vom AVB-Tool den Link deaktiviert.

Mir sind keine Geräte, DANTE etc.. bekannt die so derart empfindlich sind... Das bei ein Stream a 8ch mit 48khz.

Naja das ging schon, man ist rüber mit Westgeld und kam mit dem Zeug zurück. Da gab es noch ganz andere Dinger, die Nachgebaut oder über die Grenze geschoben wurden. Bruce-Springsteen-Konzert am 19. Juli 1988 in Ost-Berlin wurde die Technik komplett von der DDR gestellt . Da gibt es ein Haufen Geschichten zu . Wie MA Dimmer, selbst gebaute Kannen und ein Lichtpult das im Westen gekauft wurde abenteuerlich über die Grenze geschafft wurde.

Auf dem Tisch steht das RME-AUDIO AVB-Tool ein AVB<-> MADI Wandler. Firmware: 1.4.0_v107

Wo soll man Anfangen??? Funktioniert es ? Ja und Nein...

Keine Ahnung wer RME beraten hat jedenfalls ist das Ergebnis war wenig überzeugend.

• kein Link bei 100Mbit/s Ports ??? Warum ??? Das Digiface AVB macht dies doch auch ??? UPDATE: Das Problem lässt sich wohl auf meine Marvell Switch im Testfeld eingrenzen. Was da genau nicht funktioniert muss ich mal schauen. Den Link handelt die PHY unter sich aus und warum das beim Digiface AVB funktioniert und beim AVB-Tool nicht ist mir schleierhaft. Meist sind dir Ursachen beim schlechten Design der Hardware zu suchen. Bei der Switch kann ich mir das sogar vorstellen. Womöglich das dieses Problem auch in der Praxis auftritt, im Zusammenhang mit anderen Geräten.
• ein völlig verstrubbeltes 1722.1 so das dessen beworbene volle 1722.1 Unterstützung zusammen klafft
• sehr lange Response beim 1722.1, wenn man sich wirklich 250ms zeit nimmt
  und es hunderte Deskriptoren abfragt dauert dies sehr lange bis das Gerät im Controller wirklich auftaucht. HIVE braucht 15 Sekunden und fragt nicht einmal alles ab. Jacks und verschachtelte Deskriptoren werden nicht gelesen. Ich brauche 5 Sekunden um alles zu lesen
• bei einem Gerät für 1500€ hat man sich beim Hohlstecker besonders viel
  Mühe gegeben. Marke 1€ -> fällt unweigerlich auseinander
• Das Webinterface ist wiederum nicht schlecht, das Gerät lässt sich schnell einstellen
• Mit dem Display gelingt es auch grundlegende Dinge zu konfigurieren, wenn man den dreh mal raus hat
• Das Gerät ist super als Kaffeetassen wärmer geeignet, man sollte es im Case nicht unbedingt zubauen.

Ich werde mich mal ans Werk machen und RME kontaktieren...

Grundproblem bei den Deskriptoren ist das die base nicht korrekt gesetzt wurde und der ControlType stimmt nicht. So weiß man nicht was man damit anfangen soll. Der Type ist für mich Vendor -> OUI 90-e0-f0 verstehe auch nicht warum sich RME nicht daran hält wenn man die 1722.1 Konformität bewirbt ? z.Bsp um die Phantomspeisung zu steuern wählt RME ein Selektor Value siehe 7.3.5.31 IEEE1722.1-2021/D13 sagt was anderes...

Kleine Entschuldigung kann es geben, es gibt keinen Controller außer meinen wo das auffällt ... ControlBlock fehlt auch und die Signale sind auch irgendwie krumm.

Anbei noch eine kleine Rechenaufgabe siehe Bild vom Control Deskriptor es zeigt die Temperatur in Kelvin Wert 34060 Multipler -2 = 100 = 340,60- 273,15k = 67,45°c -> wunderbar zum Kaffee wärmen ... Multipler muss ich auch anderes anzeigen so mal nebenbei bemerkt... Das kann kein Schwein erraten...

Update:

Die PHY scheint etwas problematisch zu sein. Ich hatte gestern noch 80m Klotz RC5 dran und Link Verluste. Ich weiß im Standard steht etwas mit 83m und der Aufbau ist bewusst grenzwertig. Da bin ich etwas enttäuscht, andere Geräte spielen auch mit 100m Kabel zwischen.

Wenn mal sucht findet man das hier, was die Sache eigentlich erklärt. Lag also nicht falsch...

https://service.shure.com/Service/s/arti…?language=en_US

das steht dann auch "High levels of network traffic or bandwidth utilization on all devices." Die Trafic addiert sich ja von Gerät zu Gerät...

Hängt vermutlich mit einen fehlerhaften IGMP Konfiguration zusammen. Die durch die Kette entsteht, in den Geräten ist ja auch nur eine Switch und diese Kette ist kein Setup welches man so betreiben sollte.

Also erst mal ignorieren....

Jahresabschluss:

Wie weit ist er denn !?

kurz davor den stand auf IEEE1722.1-2021/D13 zu heben. Meine Nase hängt mal wieder weit vorne. Was war passiert? Ich kam auf die Idee meinen alten Mac auf macOS Monterey zu heben. Erstaunlich das dies mit einem Gerät von Mitte 2015 noch funktionierte. Jedenfalls hat sich am AVB-Stack von Apple erheblich etwas bewegt. Dieser unterstützt jetzt auch AAF und CRF Streams. Ohha... Da tauchten plötzlich neue Descriptoren auf, TIMING,PTP_INSTANCE und PTP_PORT. Es ging nicht anderes als mich auch von den Grundlagen auf den neusten Stand zu bringen. Denn Mitte 2022 wird es eine neue IEEE1722.1 geben die erheblich mehr Kommandos am Thema PTP mit bringt. Auch der IEEE1722-2016 wurde erheblich erweitert. Später sicherlich mehr..

Die IEEE1722.1-2021/D13 ist in den Descriptoren umgesetzt und weil ich schon mal dabei war habe ich den letzten Gurkencode von 2018 gleich mit umgedreht. Sowie den nächsten Schritt vorbereitet..

Schreiben kann man diese auch und zwar per JSON, man schickt das Dokument auf einfach zurück. Der einzige Controller der WRITE_DESCRIPTOR überhaupt unterstützt, das vollständig.

Die IEEE1722.1-2021/D13 hat auch endlich ein Kommando wo man mehre Kommandos zusammenfasst in einer Anfrage. Da bin ich jetzt dran, Kommandos die auf Parameter beruhen JSON basierend auszulösen. Keine Webformulare mehr, wer was ändern will manipuliert das JSON und schickt es zurück. Was man ändern kann -> siehe API.

Neue Hardware ist auch eingetroffen -> RME digiface AVB. Auch hier in einem extra Thread ein paar Worte..

So Guten Rutsch...

https://meyersound.com/documents/

ganz unten ->Discontinued

Zitat von =RS=

Ja und? In den mir dazu bekannten Fällen, bei denen eine Zulassung einer Kernel Erweiterung notwendig ist, steht das aber auch immer groß und breit in den readmes drin.

Ist halt nicht alles "hausfrauentauglich" in dem Bereich. Muss es aber auch nicht, meiner Meinung nach.

Nun ja ich glaube du solltest dich mal mit Apple beschäftigen..

https://support.apple.com/en-lk/guide/ma…1/12.0/mac/12.0

Ähm das kann nicht die Lösung sein um ein Audiointerface anzuschließen...

Zitat von Walgesang

Vorsicht:

marcoboy beschreibt Probleme mit einem Digiface AVB.

pfeiffe und Wora hingegen reden über das Digiface Dante.

Das Digiface Dante hab ich bisher an diversen Windowsrechnern gehabt, komplett unauffällig. Allerdings nur Playback oder Converter Madi <-> Dante.

Ich sehe nicht, warum das nicht funktionieren sollte, das Digiface ist für den Rechner ja nur ein beliebiges USB Audio Interface.

Nö das Problem ist das gleiche, es werden Kernel Module notwendig die in den Kernel geladen werden müssen. Da war die erste Bauchlandung, da Apple sehr restriktiv geworden ist mit solchen Dingen. Zum Rechner hin sind die Interfaces relativ ähnlich...

Was viele nicht bedenken Treiber und auch die Plug-Ins sind optimiert für Intel Prozessoren und diese setzt Apple nicht mehr ein. Wer sich einen Apple zulegt sollte dies unbedingt bedenken oder versuchen einen alten mit Intel Prozessor zu bekommen. Apple mit M1 fällt aktuell leider unten durch, liegt aber nicht an Apple. Hersteller müssen ihr Zeug eben portieren....

Das kommt darauf an ob dein Mac eine M1 CPU -> ARM hat. Dann Bitte kurz in den Hintern beißen.

Ich weiß jetzt gar nicht ob es mit der DVS mit Dante irgend wie läuft. RME hat zwar recht früh Treiber angekündigt scheitert aber offenbar an den Sicherheitsanforderungen.

Das besagte RME Interface läuft hier am Mac nicht. Da sich nötige Zusatzsoftware aufhängt....