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

[KlingtnachStrom]

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


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

Das ist doch nur Theorie, der in der Praxis nur wenige Interfaces gerecht werden, siehe meinen bereits geposteten Link:

https://gearspace.com/board/music-c...erface-low-latency-performance-data-base.html

Und sehr davon abhängt wie gut jeweilige Asio Treiber programmiert sind. Nicht jeder Treiber packt 16,32 oder 64 Samples Buffersize und schon gar nicht mit gleicher Asioauslastung.

Da gibt es heute meiner Erfahrung nach immer noch deutliche Unterschiede, zumindest zwischen Rme (pci, pcie, usb), Marian (pcie), Focusrite (scarlett+clarett usb), motu 828es und eben Behringer umc2 mit asio4all

 

[adrachin]

siehe meinen bereits geposteten Link

Wie oft willst Du den irrelevanten, aus der Zeit gefallenen Post denn noch erwähnen? 2011. Da liegen Generationen von Hard- und Software dazwischen.

Hier ein aktueller Link auf DAW Benchmark. Da zum Download bereitgestellt, DAWbench 2021 Benchmark Suite. Da kann dann jeder mal selbst testen, wo sein Gesamtsystem so steht.

Das ist doch nur Theorie, der in der Praxis nur wenige Interfaces gerecht werden

Was @Be-3 beschrieben hat, ist korrekt. Simple Mathematik in Programmcode gegossen. Wenn das Gesamtsystem, aus welchen Gründen auch immer, es nicht schafft, den Puffer kontinuierlich zu füllen und zu leeren, dann gibt es eben Dropouts. Aus welchen Gründen das so ist, muss von Fall zu Fall untersucht werden. Mögliche Gründe gibt es viele. Das interface ist da nur eine der Variablen.

@Charvelniklas, ich würde mal Prozess Lasso ausprobieren. War bei mir immer installiert, als ich noch mit Win unterwegs war. Das kann Prozesse priorisieren. Funktioniert sehr gut. Vielleicht schafft es das ja, den Übeltäter in den Hintergrund zu verbannen.....

 

[wjl]

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.

Torsten hat's auf den Punkt gebracht.

Wo's haken könnte ist also einmal die Software bzw. die Art wie man die benutzt (zu viele Plugins auf einem Kanal), und zweitens die Realtime-Fähigkeiten der/des Kernels, dazu kann ich aber bei Windows nicht viel sagen, beschäftige mich seit -zig Jahren nicht mehr damit.

Versuch: ein Live-Image wie UbuntuStudio vom USB Stick starten (das hat einen "RT"-Kernel (wobei "realtime" natürlich immer relativ ist, nichts ist realtime) und dann nochmal probieren.

Ich nutze Debian und Arch mit einem Focusrite Interface, meinem Bruder hatte ich mal ein Behringer geschenkt, beide sind gut. Vielleicht nicht so toll wie das RME eines Freundes aus Paris (der auch Linux nutzt), aber für uns Hobbyisten mehr als gut genug.

Die Tochter nutzt übrigens Ubuntu auf einem Notebook und hat damit auch keine Probleme - aber die spielt ja auch "nur" Klavier. Und mit einer Buffersize von 256 sind wir bei den 5,3ms - alle.

LG,
Wolfgang

 

[Mfk0815]

wenn man schon eine SSD hat sollte man auf keinen Fall defragmentieren, das bringt nichts und kostet Lebenszeit der SSD.

Bei SSDs stimme ich dir voll und ganz zu. Fragmentierung von Dateisystemen haben keine Performance-Einbußen zur Folge wenn es kleine beweglichen Teile in dem Speichermedium gibt. Daher braucht es auch keine Defragmentierung einer SSD.
Allerdings gibt es kein mir bekanntes Dateisystem, das nicht zur Fragmentierung neigt, wenn man es lange benutzt. Das hat seine Gründe wie Dateien, speziell große Dateien abgelegt werden. Je länger man ein Dateisystem benutzt und je mehr Daten immer wieder neu geschrieben werden, desto stärker wird die Fragmentierung sein. Deshalb macht es durchaus Sinn, wenn man HDDs als Arbeitsplatte für die Daten benutzt, diese hin und wieder komplett wegzusichern (sichern ist ja ohnehin eine extrem gute Idee) und die Platte, das logische Laufwerk oder wie auch immer man es nenne will, komplett neu zu formatieren und die Daten wieder zurück zu kopieren. Das ist oft schneller und effektiver als irgendein noch so tolles Defragmentierungstool zu benutzen.

Win 10 und 11 schreiben auch bereits automatisch so, dass eine Defragmentierung kaum noch nötig ist.

Da sich seit einiger Zeit an den Dateisystemen nichts substantielles geändert hat (Windows 10/11 arbeitet nach wie vor mit NTFS und FAT(32)) gibt es keine Grund zu glauben dass neuere Betriebsysteme da irgend etwas wirklich besser machen. Das gilt übrigens auch für die anderen Betriebsysteme wie z.B auch alle Unix-artigen. Wer glaubt, dass es da keine Fragmentierung gibt ist auf dem Holzweg. Allerdings kann z.B MacOS schon länger quasi eine laufende Defragmentierung. Das heisst, dass es das im lafuenden Betrieb macht. Der Anwender kriegt das nicht mit, bzw. muss gar nicht bewusst aktiv werden, allerdings kostet das trotzdem etwas Zeit, weil es ja doch getan werden muss. Naja, ist halt so.

 

[adrachin]

Allerdings kann z.B MacOS schon länger quasi eine laufende Defragmentierung

Das muss nichts mehr defragmentiert werden, da die länger nur noch SSD als "Festplatte C", also OS Speichermedium verwenden. Und die muss, bzw, sollte auf keinen Fall defragmentiert werden. Siehe SSDs: Keine beweglichen Teile, keine Vorteile durch Defragmentierung.

 

[Mfk0815]

Das ist mir schon klar und hatte ich durch meine Zustimmung zur Aussage von @Murenius auch so halbwegs deutlich gemacht, aber hast du auch immer deine Audio-Daten auf einer SSD? Und das schon seit 20 Jahren? Das denk ich nicht, Tim äh Adrachin Und bei HDDs macht auch der Mac seine Defragmentierung: https://www.heise.de/tipps-tricks/F...en-und-warum-es-nicht-noetig-ist-4015120.html (letzter Abschnitt)

 

[adrachin]

Audio-Daten auf einer SSD? Und das schon seit 20 Jahren?

Seit ungefähr 10 Jahren.

Wie auch immer, ich wollte nur sicherstellen, dass niemand damit anfängt, seine SSD zu defragmentieren..... (;

 

[Mfk0815]

Alles gut, da sind wir d‘accord

 

[Charvelniklas]

So, ich hab mich nach einiger Überlegung für das Motu M4 entschieden. Das Ergebnis: Ich kann auf dem ansonsten unveränderten Setup VSTis bei einer Samplerate von 64 @48kHz spielen, ohne dass es Aussetzer gibt. Der Motu-Treiber meldet an Reaper eine Latenz von 4,8 ms.

Hier mal ein paar Messungen mit RTL Utility – und im Gegensatz zu den Messungen beim Behringer UMC404HD bekomme ich hier auch zuverlässig konsistente Messergebnisse:
Abtastrate Puffergröße RTL
48 kHz 64 6,396
48 kHz 128 10,417
48 kHz 256 15,729
96 kHz 64 4,073 (Warnung „Suspect result!“)
96 kHz 128 6,073 (Warnung „Suspect result!“)
96 kHz 256 10,062 (Warnung „Suspect result!“)

Höhere Puffergrößen habe ich nicht gemessen, weil die Latenz für mich dann ohnehin nicht mehr interessant ist.

Damit zeigt sich, dass das Interface sowohl auf die tatsächliche Latenz als auch, und das ist hier viel entscheidender, die realistisch nutzbare niedrigste Puffergröße hat. Abschließend möchte ich danke sagen an alle, die sich an der regen Diskussion beteiligt und mir weitergeholfen haben!