Latenzfragen bzgl. e-Drums-Echtzeitspiel mit VSTi

    Habe mal einen Latenztest an meinem e-Drumset gemacht:
    Den physikalischen Attack auf ein Gummipad und einen knackigen Rim-Klick eines latenzfreien VSTi´s (BFD2) als Audioausgabe mit gutem Micro aufgenommen. Das Rim-Klick-Sample habe ich selber gecheckt: es ist ein mono-WAV mit der Transiente wirklich maximal am Anfang.
    Natürlich alles ohne weitere FX, weder im Sequencer noch im VSTi.


    Soundkarte ist eine M-Audio-Delta192 mit 128 Samples ASIO-Puffer-Einstellung (also so ca knapp 3 Millisekunden Latenz) in einem audio-optimiertenWin XP SP2 Rechner. Soundkarten-Treiber sind für das Setup auf aktuellem Stand.
    Trigger-To-Midi-Interface ist ein Yamaha DTXpress-Modul. (Habe das auch mal mit einem Alesis Trigger I/O verglichen. Das Alesis ist bei gleichen PC-Hard- u Softwareeinstellungen. bis zu knapp 5 ms langsamer. Gehe (in Anbetracht des Messergebnisses) also davon aus, daß das Yamaha-Modul fast vollkommen latenzfrei ist und Alesis eben nicht ganz.)


    Jetzt ist mir Folgendes (also mit Yamaha-Modul) dabei aufgefallen, als ich den Versatz zwischen Gummipad-Attack-Transiente und Rim-Klick-Transiente gemessen habe:


    In Cubase mit M-Audio-ASIO-Treibern (VSTi in Cubase geladen - ansonsten keinerlei FX) gibt es einen Versatz von ca 10 Millisekunden in meinem Speaker-Setup, sowie dann laut Berechnung ca 7 ms über Kopfhörer.


    Meine Berechnung: Es gibt je einen ASIO-Puffer für den Eingang und den Ausgang. Ich muß also die Werte immer verdoppeln. Dann sind´s knapp 6, dann nochmal ca 3 ms Schallweg in meinem Speaker-Setup (ca 70 cm Speakerentfenrnung), bin ich bei 9. Das ist nicht mehr weit weg vom gemessenen Cubase-Ergebnis.


    Meine Frage:


    Hat jemand bessere Ergebnisse? Vielleicht hat jemand eine andere Soundkarte daraufhin getestet? Ja, warum gehen eigentlich 64 Samples ASIO-Puffer nicht mehr klar (es knackst und furzt)? Ist das nur bei mir so, bzw. hat es mit der Stärke des Rechners zu tun? (laut Taskmanager ist da CPU-mäßig eigentlich nichts überlastet...) Oder liegt´s an der Soundkarte? Gibt´s eine die bei 64 Samplen lockerbleibt? (Wie schlägt sich da z.B. das RME-Fireface?) Oder an der Kommunikation mit dem Sequencer?



    Desweiteren habe ich ASIO-Puffer mal auf 512 gesetzt und bekomme sehr seltsam schwankende Ergebnisse: von ca 20 - 30 ms geht´s da rauf und runter, habe sogar mal 33 ms gemessen.



    Meine Frage:
    Warum diese Schwankungen würde mich mal interessieren. Ob´s an der Hardware liegt? Oder der Software? Und welcher Software: Treiber und/oder Sequencer? Oder Zusammenspiel? Tatsache ist, daß solche Schwankungen bei 128 Samplen ASIO-Puffer nicht auftreten, höchstens mal ca 1 ms.



    Vielen Dank für Antworten! :)
    Sehr Gruß.

    Moin,


    ich kann dir zwar zu deinem speziellen Problem nicht direkt weiterhelfen, aber die minimal mögliche Latenz von Soundkarten ist schon teilweise sehr unterschiedlich. Ich habe mich für eine RME Digiface (mit Expresscard) entschieden,
    weil ich da bei meinen Anwendungen (Logic Multitrackrecording und Live-Mix mit SAC) bei vertretbarer Last für den Rechner auf 64 Samples (Windows XP SP 3 auf einem Mac) bzw. auf 32 Samples (Logic auf demselben Mac) gehen kann.


    Laut anderen Usern gibt es durchaus Soundkarten im gleichen Preisbereich, die mit ach und krach 128 Samples hinbekommen. Aufgrund meiner durchweg positiven Erfahrungen mit RME würde ich dir mal einen Test empfehlen. Ich würde daher vermuten, dass es bei dir an der Kombination Hardware/Treiber liegt.


    Grüße,
    7

    Zitat von Seven

    Moin,


    ich kann dir zwar zu deinem speziellen Problem nicht direkt weiterhelfen, aber die minimal mögliche Latenz von Soundkarten ist schon teilweise sehr unterschiedlich. Ich habe mich für eine RME Digiface (mit Expresscard) entschieden,...

    Danke für Deine Antwort. Würdest Du denn sagen, daß das Fireface400 (also mit Firewire) da weniger taugt ist, als Dein Digiface mit Expresscard? Habe gelesen, daß in der Treibersoftware minimal 48 Samples beim FF400 ausgewählt werden können...

    Zitat

    Trigger-To-Midi-Interface ist ein Yamaha DTXpress-Modul. (Habe das auch mal mit einem Alesis Trigger I/O verglichen. Das Alesis ist bei gleichen PC-Hard- u Softwareeinstellungen. bis zu knapp 5 ms langsamer. Gehe (in Anbetracht des Messergebnisses) also davon aus, daß das Yamaha-Modul fast vollkommen latenzfrei ist und Alesis eben nicht ganz.)


    Meine damaligen Messergebnisse bezüglich Alesis Trigger I/O Modul ergaben in etwa folgende Werte: 7-8ms Latenzen beim umwandeln der A-Triggersignale in Midi-Steuerbefehle am USB/Midi-Out. Ich bezweifele in Anbetracht der Tatsache das sich die Hersteller von herkömmlicher Modultechnik wie ROLAND/Yamaha eher wenig mit dem Thema latenzfreie Wandlung der Triggersignale am Midi-Out beschäftigt haben, dass das Yamaha DTXpress diese Umwandlung dann gänzlich latenzfrei bewerkstelligen sollte. Ich vermute eher das da Werte zwischen 3-4ms realistisch sind.


    Zitat

    Hat jemand bessere Ergebnisse? Vielleicht hat jemand eine andere Soundkarte daraufhin getestet? Ja, warum gehen eigentlich 64 Samples ASIO-Puffer nicht mehr klar (es knackst und furzt)? Ist das nur bei mir so, bzw. hat es mit der Stärke des Rechners zu tun? (laut Taskmanager ist da CPU-mäßig eigentlich nichts überlastet...) Oder liegt´s an der Soundkarte? Gibt´s eine die bei 64 Samplen lockerbleibt? (Wie schlägt sich da z.B. das RME-Fireface?) Oder an der Kommunikation mit dem Sequencer?


    Zitat

    Laut anderen Usern gibt es durchaus Soundkarten im gleichen Preisbereich, die mit ach und krach 128 Samples hinbekommen. Aufgrund meiner durchweg positiven Erfahrungen mit RME würde ich dir mal einen Test empfehlen. Ich würde daher vermuten, dass es bei dir an der Kombination Hardware/Treiber liegt.


    Das ist leider ein sehr komplexes Thema! Zum einen kann es auch daran liegen das innerhalb des PCI-Bussystems andere Komponenten den Datendurchsatz blockieren, (wie etwa Festplatten, DVD-Laufwerke usw.) auf der anderen Seite ist es eben so, dass ein gutes Audio-Interface auch nur dann ein wirklich gutes Interface ist wenn auch tatsächlich die dazugehörigen ASIO-Treiber (Windows System) sauber programmiert sind! Und im diesen Punkt lassen halt etliche Hersteller deutlich "Federn" Und auch wenn das hier immer wieder von meiner Seite aus wie absolute Werbung klingen möge, es ist halt momentan einfach so das die Firma RME in dieser Sache ziemlich weit die Nase vorne hat! Ändern könnte sich das schlagartig wenn die ganz großen "Global Player" wie Microsoft, Apple oder Intel endlich davon überzeugt werden können, dass ein völlig neues und schlankes BS entwickelt und optimiert für Audio/Video Echtzeitbetrieb das Licht der Welt erblicken müsste. Aber davon träume ich schon seit Jahren und das wahrscheinlich auch weiter vergeblich.


    Bis dahin sind gerade die PCIExpress Karten von RME (Multiface, Digiface, HDSPe usw.) für Echtzeitbetrieb für VST-Instrumente als das "Non Plus Ultra" zu betrachten. (Mal abgesehen von irgendwelchen Spezial Produkten in 5-stelligen Bereichen oder gar mehr)


    Diese Karten kann man bei ordentlicher Rechner Konfiguration praxisgerecht mit Buffersize Einstellungen von 32 Samples (0,7ms) störungsfrei benutzen. (natürlich abhängig von der jeweiligen Projektgröße) Und es ist richtig, dass die RME Geräte mit Firewire Schnittstelle und neuerdings auch mit USB Schnittstelle auf Windows Basis Buffersize Einstellungen bis zu 48 Samples erlauben. Wie oben erwähnt ist also momentan die PCIExpress Schnittstelle die schnellste!


    Übrigens benutzen meines Wissens alle - zu mindestens neueren - RME Geräte einen zusätzlichen sogenannten "Safety Buffer" je nach Bauart mit unterschiedlichen Buffergrößen (32-48-64 samples) welche sich aber nicht zum "Latenzjitter" addieren. Laut Hersteller ist damit eine Störungsfreie niedrige Latenz auch bei hoher CPU-Last möglich. Aber ab einer CPU Auslastung von 50% ist IMHO eigentlich kaum mehr ein störungsfreier Betrieb möglich ohne die Buffersize Werte deutlich zu erhöhen.


    Noch ein Tipp: Wenn man mit Cubase/Nuendo als Host arbeitet und einen Mehrkern Prozessor besitzen sollte, ist es bei Echtzeitanwendungen ratsam innerhalb von Cubase/Nuendo den Mehrkern Support abzuschalten! (unter Geräte konfigurieren - Erweiterte Optionen - Multi-Prozessor-Modus) Das kann schon einiges bewirken.


    Nicht zu vergessen sind natürlich alle grundsätzlichen Maßnahmen die ergriffen werden sollten um einen Rechner als DAW zu optimieren.


    Gruß


    Trommeltotti

    Zitat

    Noch ein Tipp: Wenn man mit Cubase/Nuendo als Host arbeitet und einen Mehrkern Prozessor besitzen sollte, ist es bei Echtzeitanwendungen ratsam innerhalb von Cubase/Nuendo den Mehrkern Support abzuschalten! (unter Geräte konfigurieren - Erweiterte Optionen - Multi-Prozessor-Modus) Das kann schon einiges bewirken.


    Gibt es dafür eine logische Erklärung? Woher hast Du diesen Tipp? So recht vorstellen kann ich mir das nicht.

    Zitat


    Gibt es dafür eine logische Erklärung? Woher hast Du diesen Tipp? So recht vorstellen kann ich mir das nicht.


    Ganz einfach: Hat man innerhalb von Cubase ein leistungshungriges VST Instrument für den Echtzeitbetrieb geladen (also mit kleinst möglichen Buffersize Einstellungen) und öffnet mit F12 das CPU/HDD Leistungsfenster und ändert obige Option dann stellt man schnell fest, dass wohl gegen allen vollmundigen Versprechungen der Hersteller ein optimaler Mehrkernbetrieb innerhalb der Audio-Software noch ein Wunschdenken ist! (zumindest einmal bei Steinberg)


    Deaktiviert man nämlich den Mehrkern Support innerhalb von Cubase sieht man wie die CPU-Leistungsanzeige (Die Cubase Anzeige!) deutlich zurückgeht und auch deutlich weniger nervös zuckt! Wie gesagt immer vorausgesetzt man benutzt sehr kleine Buffersize Einstellungen innerhalb des ASIO-Treibers. (so wie ich 32 Samples)


    Ich führe diesen Umstand darauf zurück, dass es eben in diesem Bereich seitens der Software Entwickler noch eine Menge zu tun gibt.


    Gruß


    Trommeltotti

    </iframe>

    Also meine alte VSL2020 von Steinberg ist meine bisher schnellste Karte was die Latenz betrifft. Mit 32Samples kann ich sie Knack und Furzfrei mit Addictive Drums und Cubase 5.5 unter XP32 SP3 spielen.
    Bei mir ist es jedoch wichtig bei XP32 nach dem Starten von Cubase den Cubase.exe Prozess im Taskmanager per Hand auf Echtzeit zu stellen, damit auch ja kein anderer Prozess dazwischen haut!
    Ich habe in einem 2.Rechner noch eine RME HDSPe 9632, die ist unter Vista 64 deutlich langsamer, da geht unter 5ms (256 Buffersize) gar nüscht.
    Aber Vista und Win 7 sind was Latenz anbetrifft eh langsamer als XP 32.
    Mit der RME 9632 komme ich nur mit ASIO4All noch weiter runter mit der Latenz.
    Der RME ASIO Treiber hat da ja noch diesen Safety Buffer seit einiger Zeit eingebaut, damit hat man zwar bei höherer ASIO Auslastung im Bereich 70-90% einen stabileren Betrieb (weniger Knackser oder Aussetzter),
    dafür aber leider keine low Lantency mehr.
    Ich weiß das andere mich dafür schlagen würden, jedoch betreibe ich die RME unter Vista 64 mit dem ASIO4All Treiber wegen der geringeren Latenz.

    Zitat

    Also meine alte VSL2020 von Steinberg ist meine bisher schnellste Karte was die Latenz betrifft. Mit 32Samples kann ich sie Knack und Furzfrei mit Addictive Drums und Cubase 5.5 unter XP32 SP3 spielen.


    Zitat

    Ich habe in einem 2.Rechner noch eine RME HDSPe 9632, die ist unter Vista 64 deutlich langsamer, da geht unter 5ms (256 Buffersize) gar nüscht.
    Aber Vista und Win 7 sind was Latenz anbetrifft eh langsamer als XP 32.


    Hallo Backbeat2,


    man müsste mal den Gegentest machen: Die RME HDSPe 9632 Karte in den ersten Rechner platzieren (wenn dieser denn eine PCIExpress Schnittstelle haben sollte) und die VSL2020 Karte in den Vista Rechner verbauen. (Geht dann wohl aber nicht weil IMHO keine Vista/Win7 Treiber verfügbar sind) Damit wäre aber erst ein aussagekräftiger Vergleich möglich.


    Ein DAW System auf Basis von Vista zu erstellen wäre ich auch eher vorsichtig. Wenn man sich so durch die einschlägigen Foren in den Tiefen des Internets durchwühlt, stellt man eigentlich fest das die meisten folgende Herangehensweise bevorzugen:


    Wenn man ein gut funktionierendes System auf Basis von WinXP 32bit zur Verfügung hat, meistens mit einem nicht mehr ganz aktuellen Rechner mit weniger als 2GB Ram, sollte man dieses System nicht unnötig verändern. Hat man hingegen einen recht aktuellen Rechner zur Verfügung mit mindestens 4GB Ram sollte man gleich auf das 64bit Window 7 BS setzen und Vista außen vor lassen.


    Daher könnte es durchaus Sinn machen Deinen zweiten Rechner - sollten die Bedingungen dafür vorhanden sein - diesen auf ein Win7 System umzustellen. (ein Lizenz -Upgrade von Vista auf Win7 ist in manchen Fällen ja kostenfrei) Ich kann nämlich kaum glauben - wenn die Konfiguration stimmig eingerichtet werden konnte - das die nativen ASIO4all Treiber performanter sein sollten als die RME ASIO Treiber! Da stimmt IMHO was nicht.


    Ich habe diesen Schritt bei mir erfolgreich bewerkstelligen können da meine DAW Hardware recht modern ist. (QC 6600 CPU, 4GB Ram) Mein RME Multiface läuft unter Win7 64bit "smooth" und ohne Probleme im Betrieb mit kleinsten Latenzen. (32 Samples) Erste "Glitsches" und "Knackser" erfolgen bei mir erst nach 55%-60% der ASIO-Leistungsanzeige in Cubase. Dafür muss man dann aber bei mir schon einige VSTi laden um diese Auslastung zu erreichen. Auch habe ich den Eindruck, dass Win7 ziemlich stabil im Betrieb ist und sich kaum aus der Ruhe bringen lässt. Das ändert aber nichts an der Tatsache, dass ein speziell auf Audio Bearbeitung abgestimmtes BS einen deutlichen Sprung in diesem Bereich bedeuten würde! Wenn nicht sogar eine Revolution darstellen würde! (wenn z.B. das System innerhalb von zwei-drei Sekunden hochgefahren ist usw.) Wenn ich demnächst mal wieder Mr. Bill Gates bei mir zum Kaffee und Kuchen einlade, werde ich ihn darauf hinweisen. ;)


    Gruß


    Trommeltotti

    Einmal editiert, zuletzt von trommeltotti ()

    Der Löwenanteil der Gesamtlatenz kommt aus meiner Erfahrung nie vom Audiointerface, sondern 1. von der trägen Verarbeitung der Triggermodule a la Roland / Alesis / etc. und 2. von der latenzbehafteten Arbeitsweise der Hostbasierten Systeme (letzteres überwiegt gewaltig).


    Anders ist es nicht zu erklären, dass man z.B. eine Latenz beim Triggermodul + MDI von (sagen wir mal beispielsweise) 5ms hat und beim Audiointerface von 2ms. Die Gesamtlatenz solcher Systeme liegt dann gerne mal bei 15ms. Da bringt die Optimierung eines Audiointerfaces um 1ms kaum was.


    Ich würde die Gesamtlatenz auch nicht per Mikrofon messen. Das bringt zuviele Variablen rein meiner Meinung nach. 30cm Entfernung des Mikros vom Pad, oder von den Speakern, machen schon 1ms Schallweg aus. Die einzig zuverlässige Messmethode ist, ein Y-Kabel am Pad anzuschließen und das Signal aufzunehmen. Mit dem gleichen Aufnahmegerät muss auf dem anderen Kanal der Audioausgang des Gesamtsystems aufgezeichnet werden (darf nicht die gleiche Kiste mit Cubase, etc. sein, die das Signal abspielt). Nur dann kommt man auf zuverlässige Gesamtlatenzwerte.


    Wenn jemand nach dieser Messweise wirklich nachvollziehbar und reproduierbar konstant deutlich unter 10ms liegt, wäre ich hellhörig.


    Solange sich die Latenzwerte allerdings bei hostbasierten Systemen in solchen Größenordnungen aufhalten, werde ich weiter bei 2ms Gesamtlatenz (von Padanschlag bis Audioausgabe) bleiben und BFD(2) Multisamples per Hardware-Lösung spielen.


    Sorry, ich weiß, dass ich keine lösungsfördernden Vorschläge äußere. Aber ich würde halt nur raten, ein konsequentes Meßverfahren wie oben beschrieben anzuwenden, um den einzelnen Komponenten und Latenzabschnitten wirklich auf den Pelz zu rücken.


    Viele Grüsse.

    | Sonor Lite | Sabian HH/AA | Pearl Mimic Pro | Clavia ddrum3 | Simmons SDS V |

    Zitat von lite

    Wenn jemand nach dieser Messweise wirklich nachvollziehbar und reproduierbar konstant deutlich unter 10ms liegt, wäre ich hellhörig.


    Solange sich die Latenzwerte allerdings bei hostbasierten Systemen in solchen Größenordnungen aufhalten, werde ich weiter bei 2ms Gesamtlatenz (von Padanschlag bis Audioausgabe) bleiben und BFD(2) Multisamples per Hardware-Lösung spielen.


    Also ich bin mit 10 - 15 ms ganz zufrieden. Merkt man doch eigentlich nicht (zumindest 10 ms), also ich merke es nicht. Ab 15 ms aufwärts allerdings schon. Ich glaube nicht, daß man 2 - 10 ms beim Spielen unterscheiden kann, ohne Haarspalterei zu betreiben. Ist jemand da anderer Meinung?


    Grüße!

    Zitat von lite

    Der Löwenanteil der Gesamtlatenz kommt aus meiner Erfahrung nie vom Audiointerface, sondern 1. von der trägen Verarbeitung der Triggermodule a la Roland / Alesis / etc. und 2. von der latenzbehafteten Arbeitsweise der Hostbasierten Systeme (letzteres überwiegt gewaltig).


    Da würd´ mich ja mal heftigst interessieren, welcher Hersteller bzw. welches Modul die am wenigsten träge Verarbeitung bis zum Midi-OUT liefert. Raffen das diese teueren Fritzen (Roland & Co) eigentlich, daß ihre Geräte eine "träge Verarbeitung" in Sachen Midi-Out aufweisen???


    Oder stimmt das gar nicht? Wie sind denn die konkreten Werte? Gibt es dafür überhaupt Angaben in den technischen Daten der Geräte??? Wenn nicht (und angenommen, es gibt diese Modul-Latenz), wäre das ja ein absolutes Armutszeugnis. Beim Alesis ist es das in der Tat, denn ich konnte keine Angaben finden, und es war echt lahmer als mein altes DTXpress-Modul, das ich für sehr (zumindest ausreichend) schnell halte. Da habe ich aber auch nichts in der Manual gefunden, oder täusche ich mich da?


    Und wie sind da die Roland-Module im Vergleich mit den Yamaha-Modulen zu bewerten?


    Und haben die Flaggschiff-Module eines Herstellers Roland oder Yamaha da bessere Werte als die günstigeren Geräte?

    Hi Martin,


    ich hab den gleichen Test gemacht wie du.
    Die Zeitdifferenz zwischen dem aufgezeichneten Anschlaggeräusch und Lautsprechersignal (RimClick-Sound) war bei mir 12 ms.
    Der Abstand der Mikrofone zu den Schallquellen war kleiner als 50mm um Laufzeiteffekte auszuschließen.
    Die im DAW angezeigten Latenzwerte halte ich für irrelevant, da wesentliche Systemkomponenten davon nicht erfaßt werden.
    Ich hab in meiner Aufnahmekette ein TD12, eine Echo Layla 3G (PCI) und WindowsXP mit CubaseLE4.
    Mein Rechner ist ein etwas angejahrter Aldi PC (DualCore2.66GHz) mit RAM Upgrade auf 2GB.
    Die System-Latency stört mich nicht beim Spielen.


    Zitat von trommeltotti

    Wenn man mit Cubase/Nuendo als Host arbeitet und einen Mehrkern Prozessor besitzen sollte, ist es bei Echtzeitanwendungen ratsam innerhalb von Cubase/Nuendo den Mehrkern Support abzuschalten! (unter Geräte konfigurieren - Erweiterte Optionen - Multi-Prozessor-Modus) Das kann schon einiges bewirken.


    Das ist wirklich interessant...


    Zitat von Martin6

    Da würd´ mich ja mal heftigst interessieren, welcher Hersteller bzw. welches Modul die am wenigsten träge Verarbeitung bis zum Midi-OUT liefert. Raffen das diese teueren Fritzen (Roland & Co) eigentlich, daß ihre Geräte eine "träge Verarbeitung" in Sachen Midi-Out aufweisen


    Das liegt auch an den verwendeten PADs, den Piezos und der intern verbauten Elektronik. Die durch den Anschlag des PADs ausgelöste Hüllkurve liefert erst nach ca. 0.8-2 ms verwertbare Ergebnisse. Die Verzögerungszeit kann in den Roland-Modulen eingestellt werden (Scantime,Masktime). Zu kurze Einstellung dieser Parameter hat aber andere Dreckeffekte zur Folge: Mehrfach-Trigger, Hot-Spots, Machine-Gun-Effekt, schlechtes Positional-Sensing. Dann kommt natürlich noch die (extrem lahmarschige) Datenübertragung über die serielle Midi-Schnittstelle dazu.


    Zitat von Seven

    Erlaubt ist was gefällt und vor allem was funktioniert


    Si, Senor :thumbup:


    Zitat von lite

    Ich würde die Gesamtlatenz auch nicht per Mikrofon messen. Das bringt zuviele Variablen rein meiner Meinung nach. 30cm Entfernung des Mikros vom Pad, oder von den Speakern, machen schon 1ms Schallweg aus. Die einzig zuverlässige Messmethode ist, ein Y-Kabel am Pad anzuschließen und das Signal aufzunehmen. Mit dem gleichen Aufnahmegerät muss auf dem anderen Kanal der Audioausgang des Gesamtsystems aufgezeichnet werden (darf nicht die gleiche Kiste mit Cubase, etc. sein, die das Signal abspielt). Nur dann kommt man auf zuverlässige Gesamtlatenzwerte


    Sorry, lite - aber da bin ich anderer Meinung. Schlag zu Schall ist das Einzige was zählt. Bei relativem Bezug der Zeit beim Aufzeichnen von Input und Output kann ich auch auf dem gleichen System mit großer Genauigkeit messen, da vom Mikrofon bis zur Harddisk immer die gleichen Funktionen durchlaufen werden. Durch die Subtraktion Latency = (Tout+x) - (Tin+x) fällt die unbekannte Größe weg. Voraussetzung ist "natürlich" ein sehr kleiner (am Besten gleicher) Mikrofonabstand.


    Zitat von Martin6

    Also ich bin mit 10 - 15 ms ganz zufrieden. Merkt man doch eigentlich nicht (zumindest 10 ms), also ich merke es nicht. Ab 15 ms aufwärts allerdings schon. Ich glaube nicht, daß man 2 - 10 ms beim Spielen unterscheiden kann, ohne Haarspalterei zu betreiben. Ist jemand da anderer Meinung


    Seh ich genauso. Ich kann's zwar hören wenn ich mir Mühe gebe. Aber beim Spielen behindert es mich nicht (bin halt kein Ästhet 8) ).
    Ein Kirchenorganist hats beim Vorzuhalten der Verzögerung beim Anblasen dieser monströsen Pfeifen sicher etwas schwerer.


    Ich möchte zum Schluß noch den Vorschlag von Lite aufgreifen, daß wir im drummerforum die gleiche Definition verwenden um Latency zu beschreiben.
    Die im DAW und ASIO angezeigten Werte halte ich für unbrauchbar weil
    1. Die Pads und Trigger
    2. Das Edrum-Brain
    3. Die Übertragungsdauer der Midi-Daten
    4. Die Rechenzeit des VSTi
    darin nicht enthalten sind.


    Vorschlag:
    1 Mikrofon (Elektret Kleinmembran) in kurzem Abstand zum Gummipad oder elastischen Rim am Meshhead
    1 Mikrofon (Elektret Kleinmembran) im Kopfhörer wobei der Kopfhörer mit dem Mikro in ein Kissen zur Schallisolation eigepackt wird
    Getriggerter VSTi Sound = Rimclick oder Cowbell
    Ein paar Anschläge aufzeichnen
    Wellenformen normalisieren
    Zeitlichen Versatz der aufgezeichneten Signale zwischen den beiden Mikrofonkanälen am DAW ausmessen


    Viele Grüße
    Peter


    P.S. über Feedback und konstruktive Kritik wäre ich euch sehr dankbar

    Zitat von trommeltotti

    (wenn z.B. das System innerhalb von zwei-drei Sekunden hochgefahren ist usw.)



    ungefähr so?


    [video]

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.
    [/video]

    Ja Matze, genau so! :rolleyes:


    Ich denke eine Erklärung folgt gelle?


    Auf dem Video ist ja deutlich ein "Macianer" zu erkennen. Ich habe mal irgend etwas von einer Software gelesen (Windows) welche den Rechner - in diesem Fall natürlich ein Laptop mit einem Akku - in eine Art "Schlafmodus" versetzt ohne dabei den Arbeitsspeicher die Betriebsspannung zu entziehen. (Welcher dann weiter vom Akku des Laptops versorgt wird) Das hält dann wohl einige Tage so. Das Ergebnis: Man klappt denn Monitor Deckel auf und siehe da: Schwuppdiwupp, der Arbeitsplatz steht sofort mit vorher geladenen Apps zur Verfügung.


    Ist da bei Dir was vergleichbares am Start?


    Gruß


    Trommeltotti

    Einmal editiert, zuletzt von trommeltotti ()

    pete55:
    Es ist schon richtig, dass die Zeit vom Schlag bis zum Eintreffen des Sounds am Ohr letztendlich die Gesamtlatenz beim Spielen darstellt. Nur wenn wir einzelne Komponenten und Konfigurationen anhand von Latenz beurteilen wollen, halte ich die Einbeziehung des Monitorweges nicht für sinnvoll. Dann hat nämlich User A bei gleichem Drummodul und gleicher Hardware einen anderen Latenzwert, weil der Weg vom Audioausgang des Moduls (oder Audiointerfaces) zum Messmikro ein anderer ist: kleine Boxen / große Boxen / Verstärker / ggf. Mixer (vielleicht auch noch digital – hehe :) ) / Mikrofonabstand / etc.. Man muss dann wieder drauf achten, dass hier keine Unterschiede aufkommen, wenn verschiedene Leute messen. Bei einem Y-Kabel und direktem Messen am Ausgang besteht das Problem nicht. Ein Y-Kabel am Pad und den Ausgang des Systems (Drummodul oder Audiointerface) halte ich immer noch für besser und eindeutiger. Der Rest ist zwar in der Praxis nicht unwichtig, aber macht es nicht einfacher, wenn man es messtechnisch und vergleichstechnisch nicht trennt.
    Nur meine Meinung dazu :)


    Habe Anfang der 90er 10ms mit einem Ensoniq ASR10 gehabt. Der Umstieg auf 2ms war für mich schon wahrnehmbar. Es fühlt sich für mich wirklich direkter an beim Spielen. 10ms sind natürlich noch kein Delay :) aber für mich im direkten Vergleich wahrnehmbar. Was ich nicht wahrnehme sind 4ms anstatt 2ms, wenn ich das eine Modul zum Ansteuern des zweiten Moduls per MIDI verwende.


    Zitat von Martin6

    Da würd´ mich ja mal heftigst interessieren, welcher Hersteller bzw. welches Modul die am wenigsten träge Verarbeitung bis zum Midi-OUT liefert.


    Ich kenne nichts schnelleres als Clavia's DDrums.



    Zitat von Martin6

    Und haben die Flaggschiff-Module eines Herstellers Roland oder Yamaha da bessere Werte als die günstigeren Geräte?


    Also ein 20 Jahre alter Simmons Drum-To-MIDI-Konverter ist zumindest flotter als ein TD-12 :)
    Mit Hüllkurven-Sample-Funktion gegen Crosstalk (2ms Scantime eingestellt wie bei Roland), aber natürlich damals ohne Position-Sensing-Zeugs, Cymbal-Zones, etc.


    Von daher kann man nicht unbedingt sagen, dass aktuelle hochpreisige Module automatisch schnell sind. Zumindest nicht bei Roland. Die Yamaha Module habe ich selbst nicht gemessen. Würde mich auch mal interessieren.


    Gruss :)

    | Sonor Lite | Sabian HH/AA | Pearl Mimic Pro | Clavia ddrum3 | Simmons SDS V |

    2 Mal editiert, zuletzt von lite ()

    Nochmal ´ne ganz andere Frage:


    PC vs. Labtop, USB-Karte (Midi + Audio)


    (d.h. Labtop + USB-Interface in Bezug auf die Hochwertigkeit der Hardware


    Was mich dringend interessieren würde:


    gibt es jemanden, der "ohne" Latenz (und damit meine ich unter 15 Millisekunden und auch nicht mehr als 128 Samples ASIO-Puffer-Einstellung) und ohne Bratzer mit Normalo-Labtop und günstigem USB-Interface (Stereo, so 100 - 200 Euro) VSTi-e-Drums spielt???


    Würde mich wundern! Wenn doch, bitte ich um Angabe aller Komponenten.


    Gruß. :)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!

Benutzerkonto erstellen Anmelden