Latenzwerte zwischen Apollo & RME

hier noch ein interessantes Video zu dem Thema:

4 Insertslotz voll mit Plugins erzeugen innerhalb der Console 4-6 ms Latenz. Der Test hat zwar jetzt nichts direktes mit meiner problematischen Gesamtlatenz innerhalb der DAW bei Software Instrumenten zu tun aber für so manchen Latenz Apollo Nerd vielleicht ganz sehenwert


Er hat Cubase gesagt und benutzt!
 
Und keine Sorge nach deiner Schuhgröße werde ich nicht fragen
Das könnte ich dir aber schneller beantworten ;-)

Nein, ich habe einfach das oben verlinkte RTL - Tool verwendet, Ausgang 1( Moni links) auf Eingang 1 verbunden und getestet.
Da wird sonst nix geroutet.
Rechner-Konfig:

Anhang anzeigen 62605

noch mal zum Test. Also du hast physikalisch das kabel von Ausgang links auf Eingang 1 gesteckt? Und dann einfach das RTL Tool starten oder wie?

Auf der Seite ist zwar eine englische Anleitung mit dabei aber ich nix verstehen
 
RTL Tool starten oder wie?
Du musst noch Ein/Ausgang konfigurieren, sowie die Soundkarte auswählen. Links auf den Button "Measure RTL" drücken und Ergebnis ansehen.

joo das hab ich alles gemacht, kriege aber irgendwie den Ausgang nicht auf den Eingang geroutet. Physikalisch ist das Verbunden. Nur was muss ich in der Apollo Console einstellen? Da kommt beim Eingang nichts an..
 
Ich habe das mal getestet, ne, verifiziert ;-) In Cubase werden, so weit man bei tausendstel und zehner Rundung von exakt sprechen kann, "exakt und identisch" angezeigt. Aber ehrlich ... ist mir Latte.

Das kann auch gut sein. Aber wie bereits erwähnt, das variiert von Hersteller zu Hersteller sehr stark. Sauber programmierter Treiber = normalerweise korrekte Berichterstattung im Host. Schludrig programmierter Treiber = Fake News.
 
Nur was muss ich in der Apollo Console einstellen?
Du musst natürlich auf Line stellen und auch etwas Inputgain geben.

hab ich ja so gemacht. Also ich bin mit Klinke aus Ausgang Links raus und mit nem XLR rein in den Eingang1. und hab dann den Input Gain voll aufgerissen sowie den Output Gain auf 0dB gestellt. Sowohl über Line als auch Mic kommt kein Signal am Eingang an.
Beim Testton seh ich lediglich den Ausschlag am Monitor Out aber nicht an Eingang1
 
Ich habe das mal getestet, ne, verifiziert ;-) In Cubase werden, so weit man bei tausendstel und zehner Rundung von exakt sprechen kann, "exakt und identisch" angezeigt. Aber ehrlich ... ist mir Latte.

Das kann auch gut sein. Aber wie bereits erwähnt, das variiert von Hersteller zu Hersteller sehr stark. Sauber programmierter Treiber = normalerweise korrekte Berichterstattung im Host. Schludrig programmierter Treiber = Fake News.

Das merkwürdige ist aber nur, warum haben andere Apollo-User dieses Problem nicht? Da scheint ja etwas nicht ganz normal zu sein. Wenn die UA Treiber unsauber programmiert wären, dann dürfte ich ja nicht der einzige sein der bei 128 Buffersize eine ziemlich hohe Gesamtlatenz von 31ms angezeigt bekommt oder?

Kassette schrub ja das bei ihm mit 7,9ms bei 128 Samples bei seinem Apollo alles im grünen Bereich ist.
 
Aber das ist doch eigentlich klar , sobald du den Eingang der Apollo nimmst musst doch alles erst mal durch den DSP und dann über thunderbolt nach Cubase.
Die UAD hat doch immer Latenz bei den Plugins in der Console zwar weniger als wenn sie nativ in Cubase laufen aber es gibt eine kleine Latenz.

Da musst du bestimmt auch darauf achten wie viele Plugins du hintereinander in der Konsole hast da werden sich die Pluginlatenzen auch addieren.
Du hast nur den Vorteil das innerhalb der Console mit einer höheren Abtastrate gerechnet wird und die Plugins dadurch schneller sind als nativ in Cubase die UAD Plugins.

Zeigt die Console die Latenzen eigentlich irgendwo an?
Bei Cubase kann man sich im Kanalzug anzeigen lassen wie die derzeitige Pluginlatenz aussieht.

User Kassette hatte bestimmt nicht so viele UAD Plugins in Reihe in der Console geladen wie du schätze ich mal...
 
Zuletzt bearbeitet:
Aber das ist doch eigentlich klar , sobald du den Eingang der Apollo nimmst musst doch alles erst mal durch den DSP und dann über thunderbolt nach Cubase.
Die UAD hat doch immer Latenz bei den Plugins in der Console zwar weniger als wenn sie nativ in Cubase laufen aber es gibt eine kleine Latenz.

Für einen Latenztest per RTL Utility sollte man die erstmal deaktivieren, denke ich. Erst dann kann man die tatsächliche Systemlatenz ermitteln. Danach kann man die ja Stück für Stück aktivieren und den Test erneut durchführen, so weiß man dann auch gleich, wieviel Latenz jedes Plugin so mit sich bringt (falls UAD nicht irgendwo ohnehin eine Anzeige a la Cubase und Logic hat).
 
Welch eine Überraschung, wo es doch bei allen Audio-Interfaces mit Kombi-Eingängen genauso ist. :LOL:
 
Aber das ist doch eigentlich klar , sobald du den Eingang der Apollo nimmst musst doch alles erst mal durch den DSP und dann über thunderbolt nach Cubase.
Die UAD hat doch immer Latenz bei den Plugins in der Console zwar weniger als wenn sie nativ in Cubase laufen aber es gibt eine kleine Latenz.

Für einen Latenztest per RTL Utility sollte man die erstmal deaktivieren, denke ich. Erst dann kann man die tatsächliche Systemlatenz ermitteln. Danach kann man die ja Stück für Stück aktivieren und den Test erneut durchführen, so weiß man dann auch gleich, wieviel Latenz jedes Plugin so mit sich bringt (falls UAD nicht irgendwo ohnehin eine Anzeige a la Cubase und Logic hat).

Also hab's jetzt mal hingekriegt mit dem RTL Tool meine Latte tenzen zu lassen :eek: ähhh ich meine meine Latenz messen zu lassen und bekomme folgende Meldung in englisch angezeigt

Bildschirmfoto 2019-01-04 um 21.22.45.png

Soweit ich das mit meinen gebrochenen Englsichkenntnissen verstehe, sieht es woh ganz danach aus, dass die Vermutung von Sascha Franck richtig war und der Treiber Report ca. 50% abweicht von der tatsächlich gemessenen Latenz!

Diese ist bei 128 Samples und 44,1Khz wie zu erwarten deutlich kürzer und liegt bei mir bei 8.3 ms!

Bildschirmfoto 2019-01-04 um 21.23.39.png

eine zweite Messung habe ich noch bei 256 Samples gemacht und hier komme ich auf 14.1 ms

Bildschirmfoto 2019-01-04 um 21.26.16.png

gemessen habe ich bis jetzt komplett ohne UAD Plugins oder Unison Preamps.
Um die Latenzen der UAD Plugins geht es mir erstmal gar nicht so sehr, sondern um die Gesamtlatenz des reinen Audiointerfaces. Schließlich muss ich ja auch beurteilen, ob sich das Interface auch bestens eignet, um mit virtuellen Instrumenten VSTi's über Midi in der DAW einzuspielen und Beats einzukloppen.

Und mit diesen Werten sollte man denk ich problemlos arbeiten können! Zumal die Latenz ja sogar ein kleinen ticken kürzer ist als mein olles RME Babyface mit 8.96 ms bei 128 Samples. Somit ist das Apollo auf Augenhöhe was schon mal gut ist!

Weniger gut ist allerdings, dass mein Treiber völlig abweicht von den tatsächlichen Werten. Mein Device restarten und try again kann ich so oft ich will, bringt nur keine Änderung. Habt ihr Ideen woran das liegen könnte?
Es stört ja zum Glück nicht im Betrieb und ist eigentlich nur ne Fake Meldung aber merkwürdig ist das trotzdem..
 
Ich blick' grad nicht mehr durch (und bin zu faul, alles zu lesen), aber brauchst du noch irgendwo Hilfe?
Habe natürlich komplett ohne Plugins gemessen.
Aber das...
Schließlich muss ich ja auch beurteilen, ob sich das Interface auch bestens eignet, um mit virtuellen Instrumenten VSTi's über Midi in der DAW einzuspielen und Beats einzukloppen.
gibt keinen Sinn. Die RT Messung gilt nur für die Audio-Performance des Interfaces. Das hat nur beschränkte bis gar keine
Aussage für Midi-Latenzen.
Weniger gut ist allerdings, dass mein Treiber völlig abweicht von den tatsächlichen Werten. Mein Device restarten und try again kann ich so oft ich will, bringt nur keine Änderung. Habt ihr Ideen woran das liegen könnte?
Es stört ja zum Glück nicht im Betrieb und ist eigentlich nur ne Fake Meldung aber merkwürdig ist das trotzdem..
Stört's dich beim Arbeiten? Das ist das einzige, was für mich wichtig ist. Was irgendwelche Software behauptet...mir wurscht.
Ansonsten, Treiber sind aktuell?
dachte wenn ich mit XLR reingehe könnte ich den Input trotzdem auf Line stellen
Welch eine Überraschung, wo es doch bei allen Audio-Interfaces mit Kombi-Eingängen genauso ist
Da is was dran :D
 
Zuletzt bearbeitet:
Jaa, nee, mit den genannten Latenzwerten lassen sich definitiv keine professionelle Produktionen erstellen. Schade.
 
Jaa, nee, mit den genannten Latenzwerten lassen sich definitiv keine professionelle Produktionen erstellen. Schade.

Viel wichtiger ist, dass man immer wieder misst und misst. Am besten mit 10 verschiedenen Tools und mindestens einmal die Woche.

Nur so kann man den Produktionsflow am Laufen halten.

Man könnte ja auch einfach mal was einspielen und schau obs klappt. Ganz unabhängig davon ob die DAW in irgendeinem Menü 3,78ms oder 27,33ms anzeigt.

Aber was weiss ich schon.
 
Soweit ich das mit meinen gebrochenen Englsichkenntnissen verstehe, sieht es woh ganz danach aus, dass die Vermutung von Sascha Franck richtig war und der Treiber Report ca. 50% abweicht von der tatsächlich gemessenen Latenz!

Tja, wie gesagt, das passiert häufig.
Kann aber auch, wie das RTL Utility ebenfalls sagt, in der Tat manchmal mit dem direkt davor erfolgten Wechsel der Samplerate oder Puffergröße zu tun haben. Mein Zoom mag das auch nicht so richtig und meldet dann ab und an mal was verkehrt.

Weniger gut ist allerdings, dass mein Treiber völlig abweicht von den tatsächlichen Werten. Mein Device restarten und try again kann ich so oft ich will, bringt nur keine Änderung. Habt ihr Ideen woran das liegen könnte?
Es stört ja zum Glück nicht im Betrieb und ist eigentlich nur ne Fake Meldung aber merkwürdig ist das trotzdem..

Wie du sagst: Stört ja nicht im Betrieb. Also abhaken. Oder vielleicht mal den UA Typen eine Notiz zukommen lassen.

Ich kenne mich mit UA Kram nicht aus, aber hier ist eine grobe Mutmaßung: Um zu garantieren, dass im Sequenzer timingmäßig korrekt aufgenommen werden kann, muss die Karte bzw. deren Treiber dem Sequenzer mitteilen, wieviel Latenz erzeugt wird, bevor das Signal tatsächlich aufgenommen wird. Das können dann ja, je nach Staffelung der Plugins auf der Karte, vielleicht auch mal die reporteten 31ms sein. Und dann läuft vielleicht was schief, was die Skalierung innerhalb des Reports angeht. Kannst du denn ganz sicher davon ausgehen, dass du niemals, ob mit oder ohne UA-Karten-Plugins, einen Aufhahmeversatz hast? Das wäre so ziemlich das Schlimmste, was aus dieser fehlerhaften Kommunikation womöglich resultieren könnte, im weniger schlimmen Fall stimmt alles und es sieht einfach nur im Treiber doof aus.
 
ticken kürzer ist als mein olles RME Babyface mit 8.96 ms bei 128 Samples
Hmmm ... hast Du das denn nachgemessen?
Vielleicht weichen die Angaben da ja auch stark ab.
Wäre mir bei RME nicht so sicher.
Und wer kann schon garantieren, dass dieses RTL Tool korrekt misst?
Das wäre mir alles zu unklar und wenig belastbar.
Da bleibe ich doch lieber beim Gefühl - das ist wenigstens subjektiv objektiv verifizierbar :)
 
Zuletzt bearbeitet:
Vielleicht weichen die Angaben da ja auch stark ab.
Wäre mir bei RME nicht so sicher.

Bei allen mir bekannten Beispielen waren die vom RME-Treiber übermittelten Werte mit den gemessenen identisch.
Und wieso wärst du dir gerade bei RME nicht sicher? Das sind doch wirklich *die* Treibernerds schlechthin.

Und wer kann schon garantieren, dass dieses RTL Tool korrekt misst?
Das wäre mir alles zu unklar und wenig belastbar.

Zig Vergleiche zwischen händischen Messungen und RTL Utility Resultaten haben ergeben, dass das sehr akkurat ist. Im Prinzip macht es genau dasselbe, was man händisch machen würde, nur eben auf bedeutend einfachere Art und Weise.
Und letztendlich wurde das Tool ja ausschließlich zu diesem einen Zweck entwickelt.
 

Zurück
Oben