Latenzen... und mit welchem Interface kriege ich sie niedriger?

[KlingtnachStrom]

Bei welcher Buffersize?

 

[Charvelniklas]

Das wäre jetzt auch meine Frage.

Ein Helix LT hab ich übrigens, aber (First World Problems, ganz klar) ich will das nicht auspacken und aufbauen müssen, um E-Gitarre zu spielen, und will nicht davon abhängig sein, dass ich es gerade zuhause habe. Übrigens ist meine RTL ja nicht 5ms (das wäre selbstverständlich wirklich kein Thema =)), sondern mit RTL Utility gemessen bei 256 Samples @96kHz knapp unter 10 ms. Das ist kein schlechter Wert, aber sobald ich allein Helix Native in der Signalkette habe, ist die Latenz im eindeutig hörbaren Bereich. Ich könnte versuchen, mir einzureden, dass mich das nicht stört – tut es aber.

Das bedeutet: Es spart CPU-Power

Das ist zwar gut, bei mir aber absolut nicht das Problem. Wie gesagt, meine CPU sitzt mit baumelnden Beinen in der Gegend herum und pfeift fröhlich vor sich hin. Über 10% Gesamtauslastung komme ich nicht, und auch die einzelnen Kerne landen nie bei bei mehr als 80% (was seltene Spikes sind), soweit ich das sehen kann.

Also,Ich hab das Behringer Umc202HD und komme mit einem kleinen Lenovo Ryzen 3 ,dem Behringer Treiber (nicht Asio4all) und Reaper
auf eine Latenz von 10/8,3 ms bei 48Khz.
Völlig ohne Probleme.

Ich auch, aber kommst du darunter? Genau das ist bei mir nämlichl die Schwelle, über die ich nicht komme. Und benutzt du zufällig Helix Native? Wenn ja, würde mich interessieren, die 8,3ms realistisch sind oder ob dein Spielgefühl vermuten lässt, dass da irgendwo eine zusätzliche Latenz draufkommt.

 

[LtdBoomer]

Ich auch, aber kommst du darunter?

Nein,keine Chance.
Aber das liegt mit Sicherheit an meinem schlappen System.

Und benutzt du zufällig Helix Native?

Nein,leider nicht.

dass da irgendwo eine zusätzliche Latenz draufkommt.

Bin Ich nicht sicher.Ich benutze viele Softsynths.Da ist schnell Schicht im Schacht,wenn Ich nicht die Spuren einfriere.
Reaper ist da sehr milde,was Cpu-last angeht.

 

[Zelo01]

Ein Helix LT hab ich übrigens, aber (First World Problems, ganz klar) ich will das nicht auspacken und aufbauen müssen, um E-Gitarre zu spielen, und will nicht davon abhängig sein, dass ich es gerade zuhause habe.

aber sobald ich allein Helix Native in der Signalkette habe, ist die Latenz im eindeutig hörbaren Bereich. Ich könnte versuchen, mir einzureden, dass mich das nicht stört – tut es aber.

Also dann frage ich bei dir persönlich jetzt nochmal nach, was ich denn an deiner Frage falsch verstanen habe?

Im Titel steht: "Mit welchem Interface krieg ich die Latenz niedriger"

Die Antwort ist: Mit Helix LT.

Ich wusste nicht, dass du bereits eins hast. Dass du das nicht immer rumschleppen willst versteh ich. Aber anstatt sich jetzt ein anderes Audiointerface anschaffen, was das Latenzproblem mit dem Helix Nativ Plugin bestimmt nicht löst, könntest dir doch ein zweiten Helix anschaffen? Budget hast du nicht genannt, oder ich habs übersehen.

Dann müsste man auch nicht drei Seiten lang diskutieren, über ein Problem, was nicht lösbar ist mit dem Helix Native Plugin.

 

[KlingtnachStrom]

Das Helix ist sicher nicht die beste Lösung, wenn man die Latenz von Softwareinstrumenten runterbekommen möchte.

Besonders niedrig in der Latenz sind entweder PCIe Lösungen von RME und Marian oder aber USB/Thunderbolt
Lösungen von RME, Motu, bzw das Presonus Quantum für Thunderbolt.

Das sind so die niedrigsten von denen ich weiss.

Und da ist eben auch der große Vorteil, dass man eine höhere Buffersize nutzen kann und trotzdem eine
sehr niedrige Latenz hat und somit auch geringere CPU Auslast, was dann erst später zum Einfrieren von
VSTis zwingt.

Es ist meist auch so, dass Systeme mit guten ASIO Treibern sich auch höher auslasten lassen und erst viel später
anfangen zu cracklen o.ä.

 

[Zelo01]

– Spielen mit VST-Instrumenten und Helix Native

Uups, dass es hier auch um virtuelle Instrumente geht, hab ich in der Tat übersehen. Dabei kann Helix LT natürlich nicht helfen. Ich hatte mich nur auf Audioeffekte bezogen, sorry, mein Fehler

 

[Charvelniklas]

@Zelo01 Alles gut =)

Besonders niedrig in der Latenz sind entweder PCIe Lösungen von RME und Marian oder aber USB/Thunderbolt
Lösungen von RME, Motu, bzw das Presonus Quantum für Thunderbolt.

Du, KlingnachtStrom (sehr cooler Nickname übrigens ), nichts für ungut, aber das hilft mir bei meinem Thema alles eher wenig. Hast du die erste Seite aufmerksam genug gelesen? Da habe ich nämlich geschrieben, dass ich einen Windows-Laptop mit AMD-Prozessor habe, eine tive-taugliche, also transportable Lösung suche. Sprich: PCIe und Thunderbolt sind beides keine Optionen.

Und da ist eben auch der große Vorteil, dass man eine höhere Buffersize nutzen kann und trotzdem eine
sehr niedrige Latenz hat und somit auch geringere CPU Auslast, was dann erst später zum Einfrieren von
VSTis zwingt.

Auch hier wieder: ich hab doch schon geschrieben, wie niedrig meine CPU-Auslastung ist. Die ist noch lange nicht das Problem. Spuren bouncen musste ich mit diesem Computer noch nie, auch nicht bei Projekten mit über 100 Spuren und mehreren VSTi. Dass es diesen Vorteil gibt, liegt auf der Hand, aber... den Vorteil hab ich schon Latenz, die ich bei 128 Samples @48 kHz, oder meinetwegen auch 256 Samples habe, ist ja für die meisten Aufgaben völlig in Ordnung. Da sind meine Ungenauigkeiten beim Einspielen teilweise größer als das, was die Latenz ausmacht.

Es ist meist auch so, dass Systeme mit guten ASIO Treibern sich auch höher auslasten lassen und erst viel später
anfangen zu cracklen o.ä.

Das ist so eine allgemeine Aussage, die ich schon häufig gelesen habe, so wie eben auch, dass RME Marktführer sein soll, was niedrige Latenzen angeht. Bevor ich loslaufe und mir ein Interface kaufe (und ich glaube, für den Preis kann ich mir kein Babyface rechtfertigen, weil das einfach eins der hässlichsten Interfaces auf dem Markt ist ), wollte ich nach Möglichkeit halt gerne wissen,
1) wie viel niedriger die inhärente Latenz von einem anderen Interface sein kann. Da scheinen die Behringer UMC-Interfaces nämlich selbst hinter denen in der 500€-Klasse nicht hinterher zu hinken, und
2) ob man herausfinden kann, ob mir ein Interface mit besserem ASIO-Treiber erlauben würde, die Puffergröße herunterzustellen, weil meine CPU ja offensichtlich nicht der Flaschenhals ist (jedenfalls nicht was die reine Rechenleistung angeht, wenn dann eher durch die Echtzeit-Performance).

Ich hab sogar schon überlegt, mir ein Dual-Boot-System mit Windows 10 und Linux einzurichten, weil ich die DPC-Latenz meines Systems im Verdacht habe. Ein paar Prozesse, teilweise von Windows selbst, schränken die Echtzeit-Performance anscheinend deutlich ein. Aber eigentlich hab ich kaum die Zeit, um mich da rein zu begeben, und ich wollte auch nach Möglichkeit solche Workflow-einschränkenden Lösungen vermeiden. Vielleicht läuft es am Ende darauf hinaus, mehrere Sachen auszuprobieren. Ich hatte nur gehofft, ein paar handfestere Infos bekommen zu können, damit ich dieses komplexe Thema ein bisschen besser verstehe

 

[KlingtnachStrom]

2) ob man herausfinden kann, ob mir ein Interface mit besserem ASIO-Treiber erlauben würde, die Puffergröße herunterzustellen, weil meine CPU ja offensichtlich nicht der Flaschenhals ist (jedenfalls nicht was die reine Rechenleistung angeht, wenn dann eher durch die Echtzeit-Performance).

Meine Aussagen bezogen sich zum Teil auch auf andere Teilnehmer und waren nicht nur an dich gerichtet.

Es muss kein Babyface sein. Wie gesagt. Motu hat sehr stark aufgeholt, was Treiber angeht und spielt in einer Liga wie RME und
bietet auch bei Kleinstlatenzen knacksfreie Ausnahme und Wiedergabe. Ich kann mein 828es bei 16 Samples Buffersize laufen lassen
und habe dabei 0,7ms Wiedergabelatenz und eine RTL von rund 1,7ms.

Diese Werte wirst du auch mit einem M4 stabil erreichen können, sofern dein System sauber konfiguriert ist und nichts
den USB Anschluss stört, wie bspw gleichzeitige Nutzung der PCIe Lanes oder irgendwelche Dienste die reingrätschen.

Das könntest du mit Tools wie DPC Latency Check oder LatencyMon prüfen.

Behringer UMC-Interfaces nämlich selbst hinter denen in der 500€-Klasse nicht hinterher zu hinken

Verstehe ich was falsch oder steht das im Widerspruch zum Eingangspost, in dem du beschrieben hast,
dass du nicht unter 13ms RTL kommst? Das sind Werte, die schon kräftig hinterherstinken und wäre
für mich absolut indiskutabel.

Btw. ich habe das kleine umc2 für unterwegs hier. Die Latenzen sind nicht so toll, aber wenn es nicht
um Echtzeitperformance geht, ist das ausreichend.

Beitrag automatisch zusammengefügt: 14.08.22

Ich hab sogar schon überlegt, mir ein Dual-Boot-System mit Windows 10 und Linux einzurichten, weil ich die DPC-Latenz meines Systems im Verdacht habe. Ein paar Prozesse, teilweise von Windows selbst, schränken die Echtzeit-Performance anscheinend deutlich ein.

Das halte ich für unnötig. Es geht nur darum zu sehen, ob da was querschlägt, aber es erhöht nicht grundsätzlich die Latenz.
Hast du eine Nvidia Karte? Da können einige Baureihen die DPC Latenz nach oben schieben.
Auch Netzwerkkarte, WLAN usw können die ASIO Performance beeinträchtigen, aber genausogut kann es auch
ausreichen einfach einen anderen USB Anschluss am Board (Kein Hub) zu nehmen.

Es wäre mal interessant bei welcher Buffersize du 13ms Latenz hast, das scheine ich überlesen zu haben

 

[Person]

Oder anders formuliert: es hat einen Grund, dass sich Anbieter auf das Konfigurieren von DAW Rechnern spezialisiert haben und sich das bezahlen lassen...

So ist das. Man kann aber auch selbst etwas nachdenken und die gängigen, noch heute gültigen "Formeln" beachten.

Wenn man Probleme mit der Performance hat, weil der Rechner nicht der Superbolide ist, muss man eben die einfachen Dinge erledigen.
Wenn man so ziemlich alles auf dem selben Rechner erledigt, wie das Musizieren, ist der erste Flaschenhals die Festplatte. Wenn man auch noch Spiele installiert hat, kein Wunder, wenn das System schwächelt. Vermutlich ist die Festplatte vollgeknallt mit einigen Programmen, das lahmt natürlich irgendwann.

 

[Signalschwarz]

dass man eine höhere Buffersize nutzen kann und trotzdem eine
sehr niedrige Latenz hat

Und das funktioniert wie genau?

 

[Murenius]

Wenn man auch noch Spiele installiert hat, kein Wunder, wenn das System schwächelt. Vermutlich ist die Festplatte vollgeknallt mit einigen Programmen, das lahmt natürlich irgendwann.

Wie soll denn da der Wirkmechanismus sein? Entweder auf der Platte ist noch Platz, oder eben nicht. Da ist es aber egal, ob jemand Spiele oder eine Office-Suite installiert hat.

Ich würde versuchen, bei dem Thema etwas von Voodoo-Mumbo-Jumbo wegzukommen und eher versuchen, wissenschaftlich zu arbeiten. Z. B. als erstes vom System (idealerweise nach Reinstall) ein Image machen, damit man zu einem definierten Punkt zurückkann. Dann Stück für Stück ausprobieren, z. b. Hintergrundprozesse manuell auf ein Minimum deaktivieren. Evtl Interfaces von befreundeten Musikern ausprobieren. Und dann pro Datenpunkt schlicht messen, ob es was bringt oder nicht und ein neues Image machen, wenn es gut ist. Bei Herumprobieren läuft man Gefahr, dass sich Effekte überlagern.

 

[Person]

Ich würde versuchen, bei dem Thema etwas von Voodoo-Mumbo-Jumbo wegzukommen und eher versuchen, wissenschaftlich zu arbeiten.

Kann jeder machen, wie er/sie will.

Wenn auf der Festplatte nur Musiksoftware installiert ist, das werden wohl keine 15 Programme sein, man seine Festplatte regelmäßig aufräumt, defragmentiert, ist das weder Voodoo, noch Wissenschaft.
Hintergrundprozesse, außer den Systemeigenen, sollte nichts laufen.
Mein Voodoo besteht genau darin, dass ich das gemacht habe. Ich habe mir von einem Fachmann einen Rechner zusammen bauen lassen, mit der Anforderung Audio. Und eben die anderen Empfehlungen befolgt habe. Das war vor vielen Jahren, der Rechner lief wie eine Rakete, heute warscheinlich auch, wenn ich den aus dem Tiefschlaf holen sollte.

 

[Murenius]

Wenn man noch eine Festplatte hat ist ein Umstieg auf SSD gute Chancen eine deutliche Verbesserung zu bewirken (vor allem bei der Schreibgeschwindigkeit), wenn man schon eine SSD hat sollte man auf keinen Fall defragmentieren, das bringt nichts und kostet Lebenszeit der SSD. Win 10 und 11 schreiben auch bereits automatisch so, dass eine Defragmentierung kaum noch nötig ist. Damit in 2022 wohl doch eher Voodoo. Man muss seine Festplatte nicht "aufräumen", solange genug freier Platz drauf ist.

Ich bezog mich übrigens auf systemeigene Hintergrundprozesse, hier kann man bei einem PC nur als DAW einiges deaktivieren, wenn man es nicht braucht.

 

[Be-3]

Wenn ich mich zum Stein des Anstoßes durchklicke, komme zu der Aussage

Und da ist eben auch der große Vorteil, dass man eine höhere Buffersize nutzen kann und trotzdem eine
sehr niedrige Latenz hat

Ich habe zwar sicherlich deutlich weniger Recording-Erfahrung als Ihr beide, aber ein bisschen rechnen kann ich:

Eine Samplerate r bedeutet, dass ein Sample 1/r "dauert". Eine Buffer-Size b zieht somit zwangsläufig eine Latenz von b/r nach sich.
Das heißt also, dass bei gegebener Sample-Rate eine gewisse Buffer-Size immer die selbe (!) Latenz produziert - unabhängig von der Hardware und egal, ob USB, Firewire oder Rauchzeichen.
Die Latenz muss also bei gegebener Sample-Rate proportional zur Anzahl der Samples im Buffer sein. Punkt.
Als Zahlenbeispiel:
Eine Samplerate von 48 kHz bedeutet, dass ein Sample 1/48 ms dauert und somit 256 Samples im Buffer 256/48 ms = 5,3 ms Latenz entsprechen.

"Mächtigere" Hardware hilft also dabei, die Buffer-Size möglichst klein zu halten - aber bei gegebener Samplerate und Buffersize kann niemals die Latenz kleiner werden. Wie denn auch?

Der Einwand von @Signalschwarz ist zwar wie üblich wieder recht orakelhaft (Denkanstoß statt Silbertablett), aber auf jeden Fall gerechtfertigt.

Viele Grüße
Torsten

 

[Person]

Win 10 und 11 schreiben auch bereits automatisch so, dass eine Defragmentierung kaum noch nötig ist. Damit in 2022 wohl doch eher Voodoo. Man muss seine Festplatte nicht "aufräumen", solange genug freier Platz drauf ist.

Nun ja, es ist mir nicht bekannt, ob SSD oder HDD, wurde nicht gesagt.
Bei HDD schreibt Win10 auch so wie sonst, muss man hin und wieder defragmentieren.
Naja, weil du schreibst, man soll wissenschaftlich bleiben. Es ist keine große Wissenschaft, seinen Rechner fit zu halten. Wenn das für dich schon Voodoo ist, weiss ich auch nicht.

 

[Charvelniklas]

Diese Werte wirst du auch mit einem M4 stabil erreichen können, sofern dein System sauber konfiguriert ist und nichts
den USB Anschluss stört, wie bspw gleichzeitige Nutzung der PCIe Lanes oder irgendwelche Dienste die reingrätschen.

Hast du damit eigene Erfahrung oder ist das eine Vermutung? Das wäre für mich wirklich wichtig zu wissen, weil ich nicht auf gut Glück was bestellen möchte, nur um es dann doch zurück zu schicken und mir das nächst Teurere zu kaufen (und dann erst zu wissen, ob das überhaupt die Lösung ist...).

Das könntest du mit Tools wie DPC Latency Check oder LatencyMon prüfen.

Hab ich schon. Beide liefern verblüffenderweise sehr unterschiedliche Ergebnisse: Während DPC Latency Checker eine durchgängige DPC-Latenz von etwa 1ms misst, dabei aber nichts, was ich als Ausreißer interpretieren würde, misst LatencyMon die allermeiste Zeit über DPC-Latenzen im zweistelligen μs-Bereich, dafür aber problematische Ausreißer von bis zu über 2ms. Ich hab tatsächlich eine NVidia-Grafikkarte, die ich im Gerätemanager ausgeschaltet habe; im Bios hab ich darauf keinen Zugriff, scheint aber auf diese Art zu funktionieren, weil LatencyMon nichts mehr von NVidia erzählt. Wenn ich Grafikkarte, WLAN und nicht benötigte Anwendungen ausmache, bleibt immer noch ntoskrnl.exe übrig, die regelmäßig eine routine execution time von ca. 800μs hat., und noch schlimmer, wdf01000.sys mit über 1ms. Danke Microsoft...? Als ich eben mit Native Instruments Cloud Support gespielt hab, musste ich bei 48kHz tatsächlich auf 256 Samples rauf, weil ich sonst sporadische Aussetzer hatte. Das passt zu dem, was LatencyMon gemessen hat: die meiste Zeit ist alles gut, aber es gibt ein paar Hintergrundprozess-Übeltäter, die hin und wieder ausreißen. Weil das allerdings Windows-Prozesse sind, wüsste ich nicht, dass ich ohne OS-Wechsel was dagegen tun kann. :/ Ich hab Windows schon gesagt, dass es Hintergrundprozesse priorisieren soll.

Verstehe ich was falsch oder steht das im Widerspruch zum Eingangspost, in dem du beschrieben hast, dass du nicht unter 13ms RTL kommst?

Um ehrlich zu sein, bin ich mir selbst nicht mehr ganz sicher, unter welchen Bedingungen ich das gemessen habe. Ich hab nicht von Anfang an alles dokumentiert. -.-

"Mächtigere" Hardware hilft also dabei, die Buffer-Size möglichst klein zu halten - aber bei gegebener Samplerate und Buffersize kann niemals die Latenz kleiner werden. Wie denn auch?

Mit dem Teil hast du so weit natürlich Recht, aber jedes Interface selbst hat nochmal eine inhärente Latenz. Die ist nicht groß (angeblich, vermutlich, vielleicht, ... um die 2ms). Im Vergleich zur Puffergröße ist das also ein kleiner Faktor, aber der einzige, den der Hersteller wirklich in der Hand hat.

Nun ja, es ist mir nicht bekannt, ob SSD oder HDD, wurde nicht gesagt.

Tatsache, das hatte ich ja wirklich noch nicht geschrieben. Ich dachte, das hätte ich inzwischen. Also, ich hab 2 M.2-SSDs, die beide auch nicht "vollgeknallt" sind. Von daher: sicher nicht der Flaschenhals.

 

[Person]

Tatsache, das hatte ich ja wirklich noch nicht geschrieben. Ich dachte, das hätte ich inzwischen. Also, ich hab 2 M.2-SSDs, die beide auch nicht "vollgeknallt" sind. Von daher: sicher nicht der Flaschenhals.

ok, dann doch Voodoo

 

[Signalschwarz]

@Be-3 So sehe ich das auch. Da mag dann herstellerabhängig nochmal ein bisschen was zusätzlich obendrauf kommen. Aber wenn die Differenz von beim Top-Hersteller mit superduper Hardware-Software-Kombi zum Durchschnittshersteller, wo vielleicht softwareseitig bisschen was aus der Retorte kommt und die Hardware nicht immer state of the art ist, dann bspw. mal angenommen 4,8 ms zu 5,6 ms beträgt, dann sind das ja keine sehr großen Unterschiede. Klar, die sind da, messbar und nicht zu leugnen. Aber wie praxisrelevant?

Und ich hatte ja die fragliche Stelle zitiert. Von daher eigentlich eindeutig, was meine Aufmerksamkeit auf sich zog. Und sicherlich hatte ich einen Meinung dazu, aber ich habe nicht sowas wie "Quatsch" oder "Blödsinn" dazu geschrieben, sondern einfach nach einer Erklärung gefragt, denn ich gehe ja nicht davon aus, dass ich alles ganz genau weiß.

 

[Be-3]

Die ist nicht groß (angeblich, vermutlich, vielleicht, ... um die 2ms). Im Vergleich zur Puffergröße ist das also ein kleiner Faktor, aber der einzige, den der Hersteller wirklich in der Hand hat.

Ja, OK, verstanden, also das, was auch @Signalschwarz schreibt.
Sicherlich kommt zusätzlich zur "Puffer-Latenz" noch ein wenig durch die Hardware hinzu, aber in Anbetracht dieser hauptsächlich problematischen "Puffer-Latenz" frage ich mich dennoch, wie man trotzdem eine "sehr niedrige" (Zitat @KlingtnachStrom) Latenz erreichen will, ist mir ein wenig schleierhaft. Da wären doch andere Stellschrauben sicher effektiver (also irgendwie den Puffer kleiner zu bekommen)...

Viele Grüße
Torsten

 

[Signalschwarz]

@Be-3 Du hast natürlich Recht damit, und das belegt ja auch deine Beispielrechnung, dass eine gewisse "Muss"-Latenz pro Puffergröße nicht unterschritten werden kann.

Ich habe die (von mir zitierte) Aussage von KlingtnachStrom so verstanden, dass dies aber möglich sei, wenn die Hardware (allgemein und audio-spezifisch) nur entsprechend potent (und hochwertig) ist. Aber das wäre schwarze Magie und damit ist's Essig nachdem der eine Ring in den Feuern des Schicksalsberges vernichtet wurde.