Neues Studio für zuhause, suche Interface mit sehr geringer Latenz

[Sascha Franck]

also hat das Motu Interface doch nichts gebracht bezüglich Latenzen. Ich bin ein Hellseher

Äh?

 

[Entone]

Wir alle sind Hellseher. Nur manche sehen etwas heller als andere.

 

[Darth Fader]

Weil?

Kannst ja dann auch auf UAD umsteigen. Garantiert nahezu Null Latenz beim Mithören.... (;

Mein Slate Abo sich nicht verlängern lässt und mir das Zuviel Hick hack ist.

Und irgendwie gefällt mir das ganze Slate System nicht mehr. Hab mich so an die andere Kette im Studio gewöhnt dass das Slate total billig wirkt mit all seinen tollen Vorteilen

 

[muffy]

Mein Slate Abo sich nicht verlängern lässt

Wie das? Will er kein Geld mehr? ^^

 

[Navar]

Fragt sich was ist das bei S1? Bug oder feature..... ?

Es geht hier um zweierlei Dinge:
- Kleine Latenzen beim Einspielen.
- Umgang der DAW mit Latenzkompensation.

Letzteres ist bei S1 anscheinend nicht ganz sauber gelöst (vielleicht muss man ja auch nur irgendwas einstellen), so dass es zu einem Aufnahmeversatz kommt.

Das ist glaube ich "by design". Die Audiodaten werden am Ende des Input Channels geschrieben. Würde man hier die Latenz kompensieren, müsste man die entsprechenden Samples anschließend wegeschneiden oder den Schreibprozess asynchron machen bei Multitrack Aufnahmen. Reaper macht das im übrigen so, das kann man sehr gut sehen, wenn man eine entsprechend hohe Latenz bei den Input FX hat, dann sind die aufgenommenen Dateien unterschiedlich lang.
Problem dabei ist, das muss man leider wissen, weil S1 einem das nicht mitteilt und das ist schlecht gelöst. Selbst die Latenz Anzeige bleibt an dieser Stelle stumm. Plugins mit Latenz sollten bei S1 nicht in den Input Channel, normale EQs und Kompressoren ohne Lookahead Geschichten oder Dinge, die Plugin Latenz produzieren sind kein Problem, weil die Samples so geschrieben werden wie sie auch rein kommen.
Das hat allerdings gar nichts mit der Latenz Kompensation an sich zu tun, sondern mit dem Design, wie die Audio Daten geschrieben werden. Ich tippe dabei schwer auf eine Software Altlast, an die man sich bisher nicht ran getraut hat, weil man dann zum Beispiel bei Multitrack Aufnahmen und Takes das Ganze neu designen müsste und das zieht sehr viel nach sich.

 

[Darth Fader]

Wie das? Will er kein Geld mehr? ^^

Anscheinend

 

[Sascha Franck]

Die Audiodaten werden am Ende des Input Channels geschrieben.

Aber dann sind doch auch die Effekte in die Aufnahme mit einberechnet, oder?
So kenne ich das jedenfalls von Logic und Cubase - weshalb die (also die Input-Kanäle) bei beiden auch standardmäßig zumindest ein wenig versteckter sind, sodass man an sich immer nur das trockene Signal (und dann natürlich auch ohne Versatz, zumindest wenn der Treiber nicht scheiße ist...) aufnimmt. Wenn man bei S1 standardmäßig gemonitorte Effekte ins aufgenommene File einberechnet bekommen sollte, wäre das eigentlich 'ne ziemliche Sechs, weshalb ich das auch nicht glauben möchte.

 

[Navar]

Wenn man bei S1 standardmäßig gemonitorte Effekte ins aufgenommene File einberechnet bekommen sollte, wäre das eigentlich 'ne ziemliche Sechs, weshalb ich das auch nicht glauben möchte.

Nee, das ist auch nicht so, es gibt nur einen Insert Punkt den man benutzen kann, bevor der Audiostream auf die Platte geschrieben wird. (Und das wurde da gemacht) Andere DAWs können auch das kompensieren, ob das bei allen der Fall ist weiß ich nicht.
Die normalen Inserts in den Kanälen liegen dahinter und dann ist das geschriebene Signal Dry und kann Wet abgehört werden.

 

[Sascha Franck]

Nee, das ist auch nicht so, es gibt nur einen Insert Punkt den man benutzen kann, bevor der Audiostream auf die Platte geschrieben wird. Die normalen Inserts in den Kanälen liegen dahinter und dann ist das geschriebene Signal Dry und kann Wet abgehört werden.

Das kenne ich eben auch aus anderen Hosts genau so. Dann sind die Files aber auch weder versetzt noch unterschiedlich lang - da ja einfach nur der Input ganz schnöde aufgenommen wird.

Manchmal sind Treiber aber mies, dann kann man einen Aufnahmeversatz haben. Ist auch das Allererste, was man testen sollte - und leider immer noch gar nicht so selten anzutreffen, besonders bei so Sachen wie Dreingabe-Interfaces, die man im ein oder anderen Effektgerät (ganz speziell bei Amp-Modelern) finden mag.

Und manchmal sind Hosts auch einfach kaputt. So bekommt es etwa Logic nach all diesen Jahren (bzw. Jahrzehnten) immer noch nicht hin, eine Aufnahme korrekt zu platzieren, sobald latenzverursachende Plugins auf dem Master sind. WTF?!? Umso schlimmer, als es sofort klappt, wenn man ganz schnöde einen Bus vor den Master schaltet und dann alle Tracks da rein routet. Auf dem Bus kann man dann latente Plugins reinkloppen, wie man lustig ist, die Aufnahmen sind trotzdem timingseitig akkurat. Vollkommen beknackt, dass die das nicht mal geregelt bekommen. Muss man halt wissen, dann geht alles.

 

[Darth Fader]

Also ich hatte jetzt keinen Versatz, selbst wenn ich mit Plugins (natürlich welche ohne Latenz) aufgenommen habe. Alles in Butter. Das MOTU läuft ja auch, aber ich hab es mir dann doch alles einfacher vorgestellt, dabei wollte ich mir nur ein zweites Setup für zuhause machen, jetzt gefallen mir so ein paar Punkte einfach nicht mit denen ich halt nicht gerechnet hab

 

[Navar]

Also ich hatte jetzt keinen Versatz, selbst wenn ich mit Plugins (natürlich welche ohne Latenz) aufgenommen habe.

Bei Plugins ohne Latenz darf das auch nie passieren. 0 Latenz bei Plugins heißt letztlich, dass sie keinen Bearbeitungspuffer brauchen.
Datenblock rein - rechnen - Datenblock raus.
Rechenzeit spielt dabei ja keine Rolle, die muss "nur" ausreichen, um zwischen den Pufferblöcken vom Treiber, die notwendigen Operationen abzuarbeiten. Sonst gibt es Dropouts, weil der Audiostream nicht mehr flüssig läuft.

 

[Jabir]

Wenn man bedenkt, dass sich RME in punkto Latenz mit 32 Samples Puffergröße seit jetzt schon Jahrzehnten beharrlich mindestens in den Top 3 hält, wird an sich auch klar, dass es ab einer bestimmten Puffergröße sowieso eher an der sauberen Programmierung liegt. Und wenn es dann ein Interface schafft, bei 16 Samples Puffergröße sauber zu laufen, dann sind idR die internen Verarbeitungspuffer (auf die man idR keinen, selten ein wenig Zugriff hat) höher angesetzt, sodass man unterm Strich nichts gewinnt. Wie der Vergleich SSL 12 vs. Motu ja auch zeigt.

Also du meinst, man kann daraus nicht schließen, dass das SSL grundsätzlich weniger CPU benötigt?

Ich frage mich schon länger, ob unterschiedliche Interfaces mehr oder weniger CPU benötigen, oder ob dies mehr oder weniger ausgeglichen ist. Wenn es z.B. mit einem RME oder Motu bei gleicher Sample Rate und Buffer Size erst später zu Knacksern und Aussetzern kommt, wäre das für mich ein Kaufargument.

 

[adrachin]

Das ist doch alles reine Theorie. Ob nun eine oder 2ms hin oder her, ob 16 oder 32 Samples Puffer, das ist nur in bestimmten Situationen überhaupt möglich. Zumindest wenn man ein Projekt aufmacht, das man auch als Projekt bezeichnen kann. Ich hatte schon mehrfach verschiedene Tests mit verschiedenen Interfaces auf verschiedenen Computern durchgeführt. Auch mit einiger Zeit Abstand. Die tun sich nicht viel wenn es um die Frage geht, wieviel Last können die verarbeiten bei welcher Buffer Size.

Die Variable mit dem grössten Einfluss ist der Rechner und die DAW. OS spielt auch eine Rolle bei der DAW Variablen. Je nach dem, was das "Home" OS der Programmierer ist wurde das dann mal für das eine OS besser umgesetzt dann auch wieder umgekehrt.

Abgesehen davon hat sich auf dem Interface Markt unterdessen durch den Price Drop der Komponenten erhebliches getan. Ein Behringer Interface früher war für die Tonne. Die Heutigen sind zwar immer noch vom Preis her unten angesiedelt, von der Performance aber keineswegs. Genauso wie bei den reinen Messwerten.

Das Feld ist sozusagen eng zusammengerückt und unterdessen ist zum Sieger aller Klassen nicht wie früher, analog zum Schifahren, noch Sekunden Abstand sondern nur noch hundertstel Sekunden sozusagen.

Da kann man sich aus einer grossen Auswahl bedienen und findet bestimmt was, das den Anforderungen entspricht.

So rum gesehen geht es in der Diskussion hier eigentlich nicht um echte Probleme. Die wurden schon gelöst vor langer Zeit. Zumindest wenn es um ms Latenz und sowas geht.

 

[rocking.xmas.man]

Ok, slate ist passé - also modeling mic von antelope mit einem Interface von denen? Oder uad mit sphere? Oder einfach richtig mit pro Tools Carbon und ohne den ganzen low buffer Hickhack?

 

[adrachin]

Ok, slate ist passé - also modeling mic von antelope mit einem Interface von denen?

Hatte ich mal. Qualität gut. Bedienung nicht wirklich. Dem würde ich UAD jederzeit vorziehen.

 

[Darth Fader]

Ok, slate ist passé - also modeling mic von antelope mit einem Interface von denen? Oder uad mit sphere? Oder einfach richtig mit pro Tools Carbon und ohne den ganzen low buffer Hickhack?

Ne ich schau mich nach einem vernünftigen mic um.

 

[Sascha Franck]

Also du meinst, man kann daraus nicht schließen, dass das SSL grundsätzlich weniger CPU benötigt?

Nein.

Wenn es z.B. mit einem RME oder Motu bei gleicher Sample Rate und Buffer Size erst später zu Knacksern und Aussetzern kommt, wäre das für mich ein Kaufargument.

Das ist definitiv der Fall. Für mehr Informationen bietet sich der Megathread auf Gearspace an.

 

[Kwaku]

Ob nun eine oder 2ms hin oder her, ob 16 oder 32 Samples Puffer, das ist nur in bestimmten Situationen überhaupt möglich. Zumindest wenn man ein Projekt aufmacht, das man auch als Projekt bezeichnen kann

Möglich ist es wenn man das Instrumental Projekt als Audio rendert und danach alle Effekte und Instrumente abschaltet. Oder man nimmt in einem komplett neuen Projekt auf.
Also wenn jemandem kurze Latenzen sehr wichtig sind

 

[Glutamatjunkie]

Weil?

das beste ist an dem ganzen Thread

 

[Glutamatjunkie]

Ne ich schau mich nach einem vernünftigen mic um.

Du bist ja verrückt!
Wie wär's mit SM7B?