Verminderung der Latenz mit Plugins -> welches Audio-Interface (ggfs. DI-Box)?

[flobudi]

Hallo Forum,

ich befasse mich mal wieder intensiver mit dem Thema Gitarre über Plugins.
Ich spiele nur über Standalone Plugins ala Neural DSP, Polychrome und Tonocracy. Das einzige, was mich wirklich stört, im Gegensatz zu der Verwendung eines Hardware Modelers, ist das indirekte Feeling und das immer wieder vorkommende Knacksen verbunden mit der leichten Latenz.
Mein Pc ist in Puncto Leistung völlig ausreichend und habe das Betriebssystem entsprechend angepasst.

Um Hardware seitige Latenz zu minimieren, habe ich als neues Interface das Volt 276 ins Auge gefasst. Ist das von den Wandlern und Eingängen passend oder macht es Sinn höher ins Regal zu greifen? Eventuell ein Interface mit einem besseren Treiber als ASIO?
Des weiteren habe ich von der Möglichkeit zur Verwendung einer DI Box gelesen. Z.b. die Walrus canvas. Dies soll zusätzliche Latenz verringern. Ist das richtig?

Würde letzteres bedeuten: Gitarre in die DI Box- Interface (Singal muss über Gain Vorverstärkung verstärkt werden?)- Plugin- Interface- Abhöre

Sorry für meine Unwissenheit und Danke für Eure Hilfe

 

[Moselaner]

Moien,
was hast Du denn bis jetzt für ein Interface eingesetzt ?

Die DI-Box brauchst Du m.E. nur, wenn Dein Audio-Interface keinen Instrumenteneingang mit hoher Impedanz hat oder Du das Signal weiter routen möchtest, z.B. auf einem Amp.

Nur mal so als Referenz, ich benutze ein Presonus Quantum ES-2, mein PC hat einen AMD 5700 als CPU und ich kann bei 44,1kHz Samplingrate auf 16 Buffer runter gehen, da macht es bei der Latenz mehr aus, ob Du direkt vor den Boxen oder 5m weg sitzt ;-)

 

[flobudi]

Ich hatte ein Presonus 24c und ein Volt1. Momentan nutze ich einen FM3 als Interface.
Ah ok das Quantum habe ich auch angeschaut. Da war ich mir nur nicht so sicher, mit dem automatischen Einpegeln.

 

[Telefunky]

Mein Pc ist in Puncto Leistung völlig ausreichend und habe das Betriebssystem entsprechend angepasst.

Leider ein Trugschluss. Die Rechenleistung hat mit der Latenz praktisch nichts zu tun.
Sie wird vom CPU Bus- und Speicher Daten Transfer bestimmt und setzt genaue Kenntnis über Architektur und Chipsatz voraus.
IdR kürzt man das ab, indem man zu einem System greift, das sich in der Praxis bei anderen bewährt hat.

 

[Moselaner]

@flobudi Off topic: das automatische Einpegeln muss man nicht nehmen, Du kannst über die Universal Control Software auch manuell einstellen und in sog. "Scenes" abspeichern. Bei mir hat jede Gitarre eine Szene, die für die entsprechende Gitarre eingepegelt ist.

 

[flobudi]

Du kannst über die Universal Control Software auch manuell einstellen

Ok. Das ist praktisch. Bisher habe ich immer den Input Gain in Null Stellung des Interface mit dem Input Gain des Plugins abgeglichen und dann die Differenz eingestellt.

 

[thorwin]

Um Hardware seitige Latenz zu minimieren, habe ich als neues Interface das Volt 276 ins Auge gefasst. Ist das von den Wandlern und Eingängen passend oder macht es Sinn höher ins Regal zu greifen?

Ich hab das ganz kleine Volt für mobiles Spielen mit Plugins und bin mit der Latenz super zufrieden, allerdings am MacBook.

Eventuell ein Interface mit einem besseren Treiber als ASIO?

ASIO ist kein spezieller Treiber, ASIO ist ein Standard nach dem Treiber entwickelt werden. In vielen Fällen (ich will ich sagen "immer", weil dann wieder eine kommt und ne Ausnahme auspackt...) sind Treiber, die speziell für das Interface entwickelt wurden, besser was Latenzen angeht als generische ASIO-Treiber wie ASIO4All, das müsste beim Volt zutreffen.

Alternativ könntest du noch in Richtung Audient schauen, die werden auch gerne mal gelobt:

Audient iD24​

​

 

[ChristophK.]

Hallo Forum,

Das einzige, was mich wirklich stört, im Gegensatz zu der Verwendung eines Hardware Modelers, ist das indirekte Feeling und das immer wieder vorkommende Knacksen verbunden mit der leichten Latenz.

Hallo flobudi,

hast du ggf. die Möglichkeit im Menü deines gewählten Modelers die Buffergröße einzustellen? Das Knacksen gepaart mit der leichten Latenz klingt für mich danach, dass hier ggf. ein falscher Wert hinterlegt ist. (Oder meinst du das mit Betriebssystem entsprechend angepasst?) Würde das vielleicht checken bevor ich mich komplett neu ausrüste.

Grüße

 

[flobudi]

ast du ggf. die Möglichkeit im Menü deines gewählten Modelers die Buffergröße einzustellen

Das Knacken kommt immer, sobald ich mit einem Plugin arbeite. Da spielt es keine Rolle welches interface ich verwende.
Die Buffergröße habe ich im Plugin eingestellt.

 

[Moselaner]

Beitrag automatisch zusammengefügt: 16.08.24

Das Knacken kommt immer, sobald ich mit einem Plugin arbeite. Da spielt es keine Rolle welches interface ich verwende.
Die Buffergröße habe ich im Plugin eingestellt.

Werlche Buffergrösse hast Du denn eingestellt ? Bei mir sieht das so aus, und da knackst nix ....

 

[Thilo278]

Ich tippe eher auf irgendetwas softwareseitiges, was das Knacken verursacht. Ich habe bei mir in einem PC einen i7-12700K drin und kann ohne weiteres auf die niedrigste Buffer Size runter. Das von dir beschriebene Knacken kenne ich trotzdem. Auch mit wesentlich höheren Buffer Sizes. Mit einem 10 Jahre alten PC und einem alten Interface hatte ich das nicht. Was es bei mir genau verursacht, weiß ich auch noch nicht, ich hatte aber Software von HP vorinstalliert (OMEN Gaming Hub), welche den PC für Gaming optimieren soll. Nachdem ich das deinstalliert hatte, waren die Störgeräusche schon wesentlich besser. Da hilft wohl nur ausprobieren, was es bei dir verursacht. Solltest du Windows verwenden, kannst du z.B. den Winaero Tweaker mal verwenden, um bestimmte Services etc. zu deaktivieren und zu schauen, ob bzw. wann es besser wird.
In ein anderes Interface zu investieren, geschweige denn in eine DI-Box (die wird gar nichts bringen), halte ich für nicht zielführend.

 

[engineer]

Verwendung einer DI Box gelesen.

Das schon mal nicht. Ich kenne DAS Teil nicht, aber eine "DI" ist was Analoges.

kann bei 44,1kHz Samplingrate auf 16 Buffer

Was heißt 16 Buffer? 16 Samples?

Um es konkret zu machen, arbeitet so ein ASIO-Treiber mit bis zu 512 samples (bei hohen Raten von 192k) was maximal 3ms sind und damit 1 Meter Schallabstand entspricht. Wenn man das halbwegs sinnvoll einstellt und das OS nichts Seltsames tut, dann kann man auch mit 256 samples arbeiten, bei 48kHz allemal. Das sind damit 2 Meter Schall-Equivalent. Kompensieren kann man da ein wenig mit Kopfhörern.

Der eigentliche Bremser ist aber der PC selber: Selbst wenn der nur mit Samples arbeiten soll und nichts berechnen muss (was ich zum Live-Einspielen empfehle!) dann kommen da immer noch OS-spezifische Dinge wie USB-Chip-Zugriff, Zeitscheiben von Windows und leider auch die Programmierfähigkeiten des Entwicklers im Bezug auf low-Level Zugriffe im OS hinzu. Windows ist da leider je nach Programmiersprache eine Super-Bremse. Es gibt USB-Zugriffe mit gemessenen 100ms Verzögerung und die auch noch inkonstant, also jitternd. Auch USB-Chips paketieren und brauchen je nach Nutzung im ärgsten Fall 10ms bis es durch den Treiber hindurch ist.

Heißt : Mit einem schnelleren Treiber geht es grundsätzlich nur, wenn der Hersteller da einen schlechten programmiert hat und du den durch Systemtausch ersetzt, sodaß der nicht mehr bremst. Ein gutes Audio-IF, das nicht allzuviele Kanäle hat und daher auf Bandbreite optmiert ist, sondern auf schnellen Zugriff, kann das faktisch mit gemessenen 5-8ms. In dem Bereich bewegt man sich eben.

Leider ein Trugschluss. Die Rechenleistung hat mit der Latenz praktisch nichts zu tun.

Wenn er eine Amp-Simulation oder was anderes rechenzeitintensives nutzt, dann sehr wohl. Das Problem sind nämlich die Speicherzugriffe, Refreshes und vorgehaltene Daten im PC in Caches. Je mehr da sonst noch rennt (und bei Windows rennt sehr viel) kann das ein Problem werden und sogar die Aussetzer erzeugen.

Zu der Knackserei:

Ich tippe eher auf irgendetwas softwareseitiges, was das Knacken verursacht.

Wenn der Buffer im Asio-Treiber groß genug ist, bleibt nur das Dazwischenfunken anderer Hardware - z.B. ein USB Host oder auch eine Grafikkarte.
Ich würde solche Sachen in Echtzeit immer mit Hardware einspielen und bei SW generell komplizierte Berechnungen mal ausschalten um es zu testen.

Was man testen kann: ist das Knacksen lautstärkeabhängig, ist es meistens ein Kabelproblem oder ein Synch-Problem, d.h. manche Datenbits werden nicht richtig erfasst. Hat man aber praktisch nur bei z.B. S/PDIF. Über USB werden meistens Sicherungsschichten implementiert.

 

[Telefunky]

Wenn er eine Amp-Simulation oder was anderes rechenzeitintensives nutzt, dann sehr wohl. Das Problem sind nämlich die Speicherzugriffe, Refreshes und vorgehaltene Daten im PC in Caches.

nun ja
... Sie (die Latenz) wird vom CPU Bus- und Speicher Daten Transfer bestimmt...
ist da nichts wirklich anderes

 

[smello]

Das Knacken kommt immer, sobald ich mit einem Plugin arbeite. Da spielt es keine Rolle welches interface ich verwende.
Die Buffergröße habe ich im Plugin eingestell

Ist da auch sicher ASIO ausgewählt? Anders geht es unter Windows nicht. Und wenn es mit dem jetzigen Interface und Asio Probleme gibt ist die Wahrscheinlichkeit durchaus gegeben, dass es mit einem anderen Interface nicht besser wird.

 

[engineer]

... Sie (die Latenz) wird vom CPU Bus- und Speicher Daten Transfer bestimmt...

"Er" der Benutzer, war gemeint, so er denn in der Tat komplizierte Rechnungen benutzt.

ist da nichts wirklich anderes

Ja,ja nur war deine Aussage ja, dass die "Latenz mit der Rechenleistung nichts zu tun" habe und das ist so nicht richtig: Man kann natürlich unterstellen, dass die Rechenleistung insgesamt ja offenbar reicht, um jedes benötigte Sample auszurechnen. Allerdings arbeiten Audioprogramme nicht synchron, sondern die Prozesse werden durch das OS verteilt und dabei hat der Programmierer der Audio-APP nur sehr beschränkte Möglichkeiten, auf das Echtzeitverhalten Einfluss zu nehmen. Wenn da ungünstige Szenarien entstehen, weil gerade zu einem Zeitpunkt mehre Prozesse Rechenzeit haben wollen (und das ist bei Windows durchaus der Fall, weil insgesamt sehr "dumm" programmiert) dann gibt es da ziemlichen Versatz in den Berechnungen und der Datenpuffer, den das Programm vorhalten muss, läuft leer. Dabei spielt dann in der Tat die Rechengeschwindigkeit eine Rolle, ob das gerade passiert, oder nicht.

Windows ist halt nicht das Richtige für real time, da auf Multitasking programmiert, so wie Server laufen, um die gesamte Leistung zu optimieren. Das widerspricht klassischen Echtzeitanforderungen. Bei MCUs ist das durch eine geschickte Interruptsteuerung oftmals besser handhabbar. Das musste vor vielen Jahren schon die Firma WERSI lernen, die unbedingt Windows CE in ihr Produkt gestopft hat.

Und auch bei MCU-basierten Systemen wie ARM gibt es Probleme, wenn man mehrere verheiratet: Meinereiner hat vor Jahren hier detaillierte Untersuchungen angestellt und Modelle erarbeitet und dann FPGA-basierte Lösungen entwickelt, solche Prozesse zu monitoren und dem OS "Tipps zu geben", wie es die Zeiten zu verteilen hat, damit es die Aufgaben packt, weil sie eben heraus gestellt hat, dass klassische Multi-Core-Systeme in extremen Ausnahmefällen ein schlechteres Echtzeitverhalten aufweisen, als ein einzelner Single Core. Das klappt hervorragend, verhindert die problematischen Einbrüche und sorgt dafür, dass die maximalen Verzögerungen auf konkret 1/3 sinken. Das bedeutet in der Folge, dass das System mit einem Drittel der Rechenleistung = Frequenz der ARM-Prozessoren die gleichen Echtzeitreaktionen halten kann. Das ist aber aufwändig und erfordert ein spezielles OS, dass da mitspielt und das unterstützt. Der Nachteil ist dann dass man 20-30% Rechenzeit zur Verwaltung und Sicherstellung dieser Funktionaliät spendieren muss, also die Multitasking-Effizienz sinkt. Das System ist also diesbezüglich in etwa doppelt so gut und man hat die Sicherheit, dass es keinen Hänger gibt. Vorraussetzung und damit show stopper bei Audio:
Die Prozesse und die SW muss exakt bekannt sein und der Source-Code etwas aufgepeppt werden.

 

[Telefunky]

Da muss ich mich dann wohl doch komplett zitieren

Leider ein Trugschluss. Die Rechenleistung hat mit der Latenz praktisch nichts zu tun.
Sie wird vom CPU Bus- und Speicher Daten Transfer bestimmt und setzt genaue Kenntnis über Architektur und Chipsatz voraus.
IdR kürzt man das ab, indem man zu einem System greift, das sich in der Praxis bei anderen bewährt hat.

CPU Bus- und Speicher Datentransfer schliesst auch die diversen Cache Systeme mit ein.
Natürlich hat auch die Software Architektur einen Einfluss, aber ein durchschnittlicher Anwender ist bereits bei CPU und Chipsatz idR überfordert.
Deswegen der praxisbezogene letzte Satz und die grobe Vereinfachung
ps: das „Sie“ habe ich um „(die Latenz)“ erweitert, weil „Sie“ sowohl auf Rechenleistung wie auf Latenz bezogen interpretiert werden könnte. oops.

 

[engineer]

ps: das „Sie“ habe ich um „(die Latenz)“ erweitert, weil ...

aha, Synergieeffekte bei der Nutzung von Pronomen - sehr löblich! Spart Co2

 

[engineer]

Mal so in die Runde:
Hat mal jemand echte Latenzen und Jitter bei seinem Equipment richtig vermessen?
Also PC-Analog Ausgang und GeräteAusgang (also hier einen PC mit SW) gleichzeitig als Audio aufzeichnen und messen?

 

[flobudi]

Also ich habe jetzt aktuell ein Motu M2 hier und bin damit sehr zufrieden.

Allerdings habe ich nach wie vor immer wieder Aussetzer im Sound.
Mein Setup aktuell:
- HP Notebook i7 11th Generation
- 16GB Ram
- 512GB SSD

Spielen tue ich am Liebsten mit der Standalone Version von Tonocracy. 48000HZ. Die Buffergröße ist eigentlich egal. Es gibt bei 16 die selben Aussetzer wie mit 128.
Die Energiesparmodi habe ich im Betriebssystem ausgestellt und auch die CPU Max angepasst. Ebenso die USB Verwaltung.

Nun stellt sich die Frage, neuer PC? Ich mag die Tonocracy Software und spiele sie lieber als den FM3.

 

[Mr. Pickles]

i7 11th Generation

Ist es ein u11xxx oder ein H11xxx?

Intel fährt teils sehr niedrige Basistaktraten bei den u Serie notebook CPUs, so dass bei nuzung von Plugins permanent der boost läuft und dann kackts ab.

Ebenso ist die Kühlung wichtig. Wenn du ne Standard Consumer kiste hast ist Thermal throttling auch ein Thema.


Ich hab mir daher für mukke ein Gamingnotebook geholt mit Ryzen 5800H, basistakt 3,2Ghz glaub ich.

Bei den intel U-Serien gehts teils auf 1.1Ghz Basistakt runter.

Hatte selber immer auf Intel gesetzt, mit Nutzung von Neural DSP plugins gingen dann die gleichen Probleme los, biss ich das mit Basistakt irgendwo gelesen hatte war ich auch ratlos, hab jetzt ein XMG zockerteil, kann da bei nutzung von reaper ein komplettes live setup der Band inkl. Mischpult via DAW und 16in/18out ohne probleme bei 64 Samples/44.1kHz fahren