Pro Tools erkennt I/O-Latenz von RME-Wandler nicht. Was tun?

[Nachtschicht]

muss er ja auch nicht, wenn die daw mittel und wege hat, es selber rauszufinden.

job des treibers wäre es aber zumindest, die latenz der adat-schnittstelle innerhalb des interface der daw korrekt mitzuteilen (was hier scheinbar nicht der fall ist)

 

[wolfgang_5dot1]

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 und ADAT uebermittelt keine Device Infos.
Es ist also sehr muesig darueber zu reden.

 

[Nachtschicht]

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

längst klar. der TE schreibt aber:

"Dazu habe ich einfach einen Hardware-Ausgang mit dem entsprechenden Eingang direkt verbunden und dieses I/O-Paar als Insert-Effekt benutzt. (...)
Die Signale, die ich durch den Adat-Wandler geschlauft habe, waren um 75 Samples verzögert."

heisst, offenbar erzeugt schon die reine adat i/o strecke 75 samples latenz, die der daw nicht korrekt mitgeteilt werden. zumindest das wäre ja nett

 

[Muenze]

Aber doch nicht das, was an dem Adat Ein/Ausgang dran haengt.
Das kann kein Treiber wissen.

Da hängt aber nichts dran. Nur ein Glasfaserkabel von ADAT Out zu ADAT In.

 

[Muenze]

Nachtschicht war schneller

 

[Nachtschicht]

is mehr meine uhrzeit

 

[wolfgang_5dot1]

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.

 

[Muenze]

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.

 

[katerkarlo]

So, jetzt bin ich wieder mal dran mit einer Bemerkung

Mal was Grundlegendes: Ich bin der Meinung, es gibt zwei Varianten, wie das mit der Hardware-Latenz funktionieren könnte / sollte:

1) Die DAW berücksichtigt die gesamte Software-Latenz inkl. Audio-Buffer, aber keine Hardware-Latenz. Die H/W-Latenz ist konstant für eine bestimmte Samplingfrequenz und muss vom User manuell eingegeben bzw. durch Ping ermittelt werden. Genau so funktioniert es z.B. in Cubase. Dort habe ich für den ADI-8 eine konstante Latenz von 75 Samples bzw. 1.7 ms und für das Fireface ungefähr 0.7 ms.

2) Die DAW berücksichtigt die Software-Latenz UND die H/W-Latenz. Dazu teilt die Hardware der DAW ihre Latenz mit. Oder die H/W-Latenz für einen bestimmten Wandler ist in der Software gespeichert. So funktioniert es so weit ich weiss bei Pro Tools mit Avid-Wandlern. Die Latenz der Avid-Wandler ist in PT fest einprogrammiert. Für den User bedeutet das, dass er manuell gar keine H/W-Latenz mehr eingeben muss (ausser man verwendet digitale Effektgeräte mit Latenz, aber das ist eine andere Geschichte).

Das Merkwürdige ist nun, dass meine Messergebnisse mit keiner dieser beiden Varianten übereinstimmen. Die gemessene Latenz ist bei mir abhängig vom Audio-Buffer, und das sollte nicht der Fall sein. Meinem Fireface ist es ja egal, ob ich in PT einen Buffer von 64 oder 512 eingestellt habe. Der Wandler wandelt immer gleich schnell (gemessen in Samples).

 

[Nachtschicht]

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.

nach der logik könnte jede daw einfach jegliche form von wandler-latenz ignorieren. weil, kommt ja sowieso noch was dazu wahrscheinlich, nichwahr? weiss man ja nie!

halte ich für nen irrweg. its a bug, not a feature.
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

 

[wolfgang_5dot1]

nach der logik könnte jede daw einfach jegliche form von wandler-latenz ignorieren.

Es geht nicht um die DAW sondern um den Treiber.
Analoge Ein/Ausgaenge werden kompensiert, digitale nicht oder eben selten denn da haengt immer noch was dran was zusaetzliche Latenzen erzeugt.

 

[Nachtschicht]

digitale nicht oder eben selten denn da haengt immer noch was dran was zusaetzliche Latenzen erzeugt.

"nicht oder eben selten" sollte in der tat einfach nur "selten" heissen, denn selbstverständlich gibt es noch andere anwendungen für digitale signalpfade als das einschleifen von latenzbehafteten effektgeräten. schon bei der verwendung einer schlichten routingmatrix würde einen das in den arsch beissen.

und somit bleibts halt schlampiges design. das man selbstverständlich schönreden kann, wenn einem denn danach ist. ist ja nix perfekt auf der welt

 

[wolfgang_5dot1]

schon bei der verwendung einer schlichten routingmatrix würde einen das in den arsch beissen.

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

 

[katerkarlo]

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

Nachdem ich das jetzt auch mit Cubase getestet habe, glaube ich nicht, dass irgendeine DAW so funktioniert wie von dir beschrieben. Sondern eher so wie meine Variante 1. In Cubase habe ich folgendes gemessen: Wenn ich über die Wandler des Fireface raus- und wieder reingehe (direkte Verbindung mit Kabel), kriege ich ein Delay von 3 Samples, über alle Buffergrössen hinweg. Über das Adat-Interface kriege ich in jedem Fall ein Delay von 75 Samples.

Das sind die exakt gleichen Werte wie in Pro Tools, AUSSER bei Audiobuffern von 64 und 128 Samples. Dort macht Pro Tools etwas falsch. Es berücksichtigt nämlich die Buffergrösse nicht. Ist meiner Meinung nach ein grosser Bug von PT (oder vom FF-Treiber, was ich aber weniger glaube).

 

[Nachtschicht]

ich bin sowieso der ansicht, dass es sich hierbei wahrscheinlich um einen fehler im RME-treiber handelt, und insofern an jede daw dieser welt die 75 samples latenz nicht berichtet werden. sollte man als fireface-besitzer vielleicht einfach mal an RME melden, dann ist das wahrscheinlich zeitnah vom tisch

 

[Nachtschicht]

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

 

[katerkarlo]

Das ist kein Fehler im RME-Treiber. Ich glaube nicht, dass es irgendeinen Adat-Wandler gibt, der seine Latenz der DAW "mitteilt". Wie auch? Für das Fireface selber wäre das eher vorstellbar. Aber ich weiss nicht, ob das ASIO Treiberformat dafür vorgesehen ist.

Als ich diesen Thread gestartet habe, dachte ich auch, dass PT die Latenz des Wandlers irgendwie erkennen sollte (darum auch der Titel). Nachdem ich jetzt aber mit Cubase getestet habe, bin ich ziemlich sicher, dass es in PT genau gleich wie in Cubase funktionieren sollte.

Solange die Latenz konstant bleibt (wie in Cubase) ist sie überhaupt kein Problem. Genau dafür gibt es ja in Pro Tools eben die Möglichkeit, die Hardware-Latenz einzustellen. Ein Problem wird es aber, wenn sich die Latenz mit der Buffergrösse ändert. Weil dann müsste ich für jede Buffergrösse ein eigenes I/O-Setup erstellen.

 

[bafc24]

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.

 

[Nachtschicht]

wie gesagt, in diesem konkreten fall geht es denke ich eher um RME als um PT, denn es scheint ja alle hosts zu betreffen. ich hab selber kein fireface (bzw nur ein altes, das als standalone routingaufgaben erledigt, ohne am rechner zu hängen), aber wer eins hat sollte das vielleicht mal dem RME support mitteilen, dass da die adat-schnittstelle 1. ungewöhnlich hohe latenzen verursacht die 2. nicht an den host berichtet werden.

oder halt damit leben. bricht man sich auch kein bein aber mich würds nerven.

 

[katerkarlo]

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.

Genau zu diesem Schluss komme ich auch. Die Software ist anscheinend so programmiert, dass sie nur mit der hauseigenen Hardware richtig funktioniert. Shame on Avid.

wie gesagt, in diesem konkreten fall geht es denke ich eher um RME als um PT, denn es scheint ja alle hosts zu betreffen.

Nein, eben nicht! So wie es in Cubase läuft ist so, wie ich es erwarte. Und 75 Samples Roundtrip-Latenz ist glaube ich für einen 15-jährigen Adat-Wandler nichts Aussergewöhnliches.

Oder erkennt Pro Tools die Latenzen deines (Nicht-Avid-) Wandlers etwa automatisch? Ich glaube kaum.