- Registriert
- 20.08.11
- Beiträge
- 8.310
- Reaktionen
- 4.793
- Punkte
- 22.831
Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: Diese Funktion ist in einigen Browsern möglicherweise nicht verfügbar.
Was es vielleicht sogar macht aber die zusaetzliche Latenz des Geraetes welches an diesem ADAT Anschluss dran haengt kann es nicht kompensieren, da ja nicht bekannt ist was fuer ein Device es ist und ADAT uebermittelt keine Device Infos.job des treibers wäre es aber zumindest, die latenz der adat-schnittstelle innerhalb des interface der daw korrekt mitzuteilen
Was es vielleicht sogar macht aber die zusaetzliche Latenz des Geraetes welches an diesem ADAT Anschluss dran haengt kann es nicht kompensieren, da ja nicht bekannt ist was fuer ein Device es ist
Aber doch nicht das, was an dem Adat Ein/Ausgang dran haengt.
Das kann kein Treiber wissen.
Und? Ist das der normale Arbeitsmodus wie die ADAT Ein und Ausgaenge benutzt werden?Da hängt aber nichts dran. Nur ein Glasfaserkabel von ADAT Out zu ADAT In.
Und? Ist das der normale Arbeitsmodus wie die ADAT Ein und Ausgaenge benutzt werden?
Wenn schon korrigiert werden muss ist es egal ob man ein bisschen Latenz ausgleicht oder ein bisschen mehr.
Ok, hab ein bisschen auf dem Draht gestanden.Jetzt versteh ich was du meinst.
Bei ADAT kommen ja in jedem Fall noch die Wandler des anderen Gerätes dazu. Deshalb währe es sinnlos die Latenzen des einen Gerätes automatisch zu kompensieren. Natürlich, du hast recht.


Es geht nicht um die DAW sondern um den Treiber.nach der logik könnte jede daw einfach jegliche form von wandler-latenz ignorieren.
digitale nicht oder eben selten denn da haengt immer noch was dran was zusaetzliche Latenzen erzeugt.
Wie du weisst hat alles was digital ist eine Latenz, so auch eine simple Matrix.schon bei der verwendung einer schlichten routingmatrix würde einen das in den arsch beissen.
eine korrekte implementation geht so: das interface berichtet an die daw die eigenen latenzwerte, wird also mit latenzausgleich samplegenau sauber im timing geprinted, egal ob der signalpfad jetzt über analog oder adat IO lief.
zusätzlich bietet die daw ein feature mit dem der signalweg durch alle weiteren geräte (derer manche vielleicht latenz haben, andere vielleicht halt auch nicht) "gepingt" werden kann. heisst: die interface-eigenen latenzen werden schon auf interface-ebene über korrekt berichtende treiber geregelt. weils das kann. den rest übernimmt bei bedarf die daw.
alles andere ist jetzt kein weltuntergang, aber zumindest bemerkenswert schlampig![]()
Wie du weisst hat alles was digital ist eine Latenz, so auch eine simple Matrix.
Wie ich schon sagte: muessig darueber zu reden was waere wenn...![]()
ich meine mich zu erinnern dass z.b. eine RME madi, wenn sie nur als matrix fungiert (also der signalfluss im totalmix geregelt wird) tatsächlich nichtmal ein sample latenz erzeugt sondern schlicht flexibel weiterleitet, aber selbst wenns statt keinem ein oder zwei samples wären: dann hättest du in szenario 1 ein signal mit einem versatz von einem sample, im anderen einen versatz von 76 samples. ich hätte gerne beides nicht, weil schon geringste fehler dieser sorte z.b. innerhalb einer multimikrofonierten quelle für unnötige phasenprobleme sorgen können, aber ich hätte auf jeden fall einen versatz von 76 samples noch weniger gerne als einen versatz von einem
wie gesagt, besonders wichtig isses alles nicht, und man kanns gerne schönreden. wenns schee macht![]()
Wenn man es richtig machen will mit PT, dann nimmt man PT HD und ein Digilink Interface, wie z.B. die hauseigenen, oder halt DAD. Die werden halt von Hause aus garantiert samplegenau eingebunden, so dass das mit den Latenzen einfach funktioniert. Klar, immer noch kostpielig aber funzt.
wie gesagt, in diesem konkreten fall geht es denke ich eher um RME als um PT, denn es scheint ja alle hosts zu betreffen.