E Drum Recording

Zitat von Beeble

Damit hat ein Midigerät an einem Rechner angeschlossen NUll Latenz!

Das stimmt natürlich nicht. Bei der Übertragung über USB (bei PCI in geringerem Maß auch), im Interface selber, bei den Treibern und bei der Weiterverarbeitung können jeweils zusätzliche Latenzen auftreten. Bei schlechten Midi-Interfaces mit schlechten Treibern dauert es durchaus auch mal mehr als 5ms, bis ein Midi-Signal aus einem Midi-Interface auch wirklich einem Computerprogramm zur Verfügung steht.

Im Rest deines Beitrags hast du leider auch ziemlich viel durcheinander gebracht.

Robo, lies mal bitte genau was ich geschrieben habe.
Es geht nicht um die Gesamtlatenz, auch nicht über die Latenz des Audiointerface. Es geht um die Latenz dieses Midi over USB Kabels.
Dort gibt es keine Latenz. Latenz entsteht erst wenn die Mididaten verarbeitet werden und natürlich bei der analogen Ausgabe des Sounds eines VSTi über das Audiointerface.
Eine einfacher 2 Byte langer Midibefehl aus Note on/off hat eine Länge von etwa 800 Microsekunden, der kommt auch am Rechner an wenn er losgeschickt wird, ohne Latenz.
Das sind Zeiten die du sicher nicht einmal messen könntest.
Ein USB 1.02 kann ein Byte jede Microsekunde ( ein tausendstel einer Millisekunde) übertragen.
Der einzige Nachteil von dem ach so schnellen USB ist die Tatsache das dieser vom Prozessor verwaltet wird und im Gegensatz zu einer mit eigenem Bus verwalteten RS232 Schnittstelle nicht so oft abgefragt wird.
Bei USB 1 war das etwa eine Abfrage alle 1 ms. Ich weiss nicht ob sich das verbessert hat.
Aber ganz sicher dauert es keine 5ms bis ein Midisignal den USB Bus durchlaufen hat.

wenn du das was ich da ziemlich viel durcheinander gebracht habe noch richtig stellst wäre es sicher hilfreicher als es nur zu schreiben.

Es geht einmal um den Transport eines MIDI-Signals und einmal um dessen Weiterverarbeitung.
Mag mal jemand einen aussagekräftigen, grafischen Latenz-Zeitstrahl mit Beispielwerten für alle Komponenten anfertigen ? Den würde ich gern oben anpinnen dann.
Sowas könnte man ggf. auch gemeinsam konstruktiv erarbeiten.

Zur Inspiration:

Ich hab vor ein Video zu machen, wie man die Latenzen messen kann etc. Das geht in eine ähnliche Richtung wie dein Bild, im Zuge dessen kann man das Ganze ja weiter erarbeiten und konkretisieren.

Beeble, vielleicht ist dein Beitrag einfach missverständlich formuliert oder wir reden aneinander vorbei. Ich versuche mal darauf einzugehen:

Zitat von Beeble

Es geht nicht um die Gesamtlatenz, auch nicht über die Latenz des Audiointerface. Es geht um die Latenz dieses Midi over USB Kabels.
Dort gibt es keine Latenz. Latenz entsteht erst wenn die Mididaten verarbeitet werden und natürlich bei der analogen Ausgabe des Sounds eines VSTi über das Audiointerface.

Ok, ich spreche von der Zeit, die zwischen folgenden Zeitpunkten vergeht:
Zeitpunkt A: Ein Eine Midi-Nachricht ist "gerade eben" in einem an den Computer angeschlossenen USB-Gerät/-Interface/-Adapter/-Konverter vollständig angekommen (oder ggf. erzeugt worden).
Zeitpunkt B: Dieselbe Midi-Nachricht steht einem Programm (z.B. Drum-Sampler) im Computer zur Weiterverarbeitung zur Verfügung.

Wenn du andere Zeitpunkte meinst, haben wir aneinander vorbei geredet. Ich denke aber, das sind die interessanten Zeitpunkte, weil das Signal genau dazwischen außerhalb unserer Kontrolle ist, und alles vom Design des USB-Geräts, dem Übertragungsprotokoll und dem Treiber abhängt. Und zwischen den Zeitpunkten gibt es auf jeden Fall eine Latenz.

Vielleicht kannst du ja auch mal genauer schreiben, welche Komponente und welche Verarbeitung du bei der Formulierung "wenn die Mididaten verarbeitet werden" meinst?

Zitat

Eine einfacher 2 Byte langer Midibefehl aus Note on/off hat eine Länge von etwa 800 Microsekunden, der kommt auch am Rechner an wenn er losgeschickt wird, ohne Latenz.
Das sind Zeiten die du sicher nicht einmal messen könntest.

So klingt das für mich nach einem Widerspruch, vermutlich ist es nur unglücklich formuliert?

Hier scheinst du über die Übertragung über ein klassisches Midi-Kabel (mit den runden Steckern) zu reden, richtig? Um die geht es mir nicht mehr, da ich erst ab dem Zeitpunkt gerechnet habe, an dem das Midi-Signal schon vollständig in einem USB-Gerät ist.

Trotzdem der Vollständigkeit halber: Ein Note on/off ist 3 Bytes lang und die Übertragung über ein Midi-Kabel dauert 0,96ms. Die Signalflanken, die du vielleicht meinst, wandern zwar mit Lichtgeschwindigkeit durch das Kabel (ca. 3,3ns pro Meter, das ist tatsächlich vergleichsweise einfach messbar), für die Latenz musst du aber die Übertragungsdauer des gesamten Signals berücksichtigen.

Zitat

Ein USB 1.02 kann ein Byte jede Microsekunde ( ein tausendstel einer Millisekunde) übertragen.
Der einzige Nachteil von dem ach so schnellen USB ist die Tatsache das dieser vom Prozessor verwaltet wird und im Gegensatz zu einer mit eigenem Bus verwalteten RS232 Schnittstelle nicht so oft abgefragt wird.
Bei USB 1 war das etwa eine Abfrage alle 1 ms. Ich weiss nicht ob sich das verbessert hat.

Eben weil USB diesen Abfrage-Takt hat, ist es für die Latenz egal, wie schnell ein einzelnes Byte übertragen werden kann, denn man muss immer erst auf den nächsten Takt warten. Und Warten bedeutet Latenz. Genau darauf wollte ich unter anderem hinaus.

Zitat

Aber ganz sicher dauert es keine 5ms bis ein Midisignal den USB Bus durchlaufen hat.

Bei guten Geräten mit guten Treibern vergehen zwischen den oben genannten Zeitpunkten A und B sicher weniger als 1ms. Bei schlechten Geräten können es aber durchaus auch mal mehr als 5ms sein, und genau das war meine Aussage. Zusätzlich zu der USB-Latenz kann in diesen Fällen z.B. dadurch viel Zeit vergehen, dass wegen einer ungünstigen Architektur das USB-Gerät die Daten eben nicht so schnell wie möglich über den USB-Bus schickt und der Treiber die Daten nicht so schnell wie möglich weiterleitet.

Zitat von RoboBlaster

Beeble, vielleicht ist dein Beitrag einfach missverständlich formuliert oder wir reden aneinander vorbei.

wahrscheinlich beides

Ok. Ich versuche mal: 10 Finger auf dem Keyboard greifen in die Tasten, ein Midiwort wird erstellt und auf die Reise geschickt. Nicht gleichzeitig sondern schön der Reihe nach wie bei serieller Übertragung üblich.
dieses ganze Signal ist ist etwa 10ms lang, je nachdem was noch an Daten mitgeschickt wird auch länger. Ohne Verzögerung kommt das Signal am USB Port an. Blöderweise wird aber nur alle 1-5 Millisekunden der Port abgefragt.
(normalerweise einmal pro ms, ich habe aber gelesen das die Hersteller gerne auch 5ms nehmen um auf Nummer sicher zu gehen. Wusste ich bisher auch nicht)
Im schlimmsten Fall kommen die Daten erst nach 5ms in den Rechner. da stehen sie dann aber sofort zum Weiterverarbeiten zur Verfügung.

Die Reiseroute des Midisignals sieht dann so aus:
-Vom drücken der Tasten bis zur Ankunft des Signals am USB Eingang vergehen etwa 32 Microsekuden, hier reden wir mal nicht von Latenz, das läuft noch unter Echtzeit.
Den Job erledigt ein UART Chip, dieser ist diskret, also kein Prozessor und hat Null Latenz.
- Jetzt gibts dann die erste Verzögerung auf die wir keinen Einfluss haben, nämlich den Datenstau am USB Port, der mindestens 1-5ms beträgt.
- die Software die jetzt mit den Daten macht was sie soll unterliegt dem Prozessortakt und auch da findet alles im nano- und microsekundenbereich statt.
also entweder werden die Daten einfach nur gespeichert oder auch von einem VSTi wie in unserem Fall verarbeitet. Zwischengespeichert bzw. gebuffert wird da nix, da es sich hier um Echtzeitanwendung handelt.
Vom drücken der Klaviatur bis zum Auftauchen in der DAW vergehen also bis zu 5ms.

Nun zum VSTi:
Die Daten müssen in Echtzeit verarbeitet werden, wenn das nicht klappt wird nicht gewartet sondern schlimmstenfalls gehen Daten verloren. Meistens läuft aber die Software dann gar nicht oder lässt sich auf entstprechend schwachen System nicht instalieren oder betreiben oder läuft einfach nicht zufriedenstellend.
Nun kommt der nächte Teil der Kette auf den wir keinen Einfluss haben und der auch wieder eine Verzögerung mit sich bring, die D/A Wandlung über das Audiointerface.
Die Performance ist abhängig von der Hardware des Geräts und der Hardware des Rechners sowie der dazugehörigen Software(Treiber)
Ähnlich wie beim USB Port werden hier die Signale zwischengespeichert. Das ist die Samplerate. Das bedeutet die Signale werden Portionsweise gewandelt. Je kleiner die Portionen(Samplerate) desto schneller werden sie ausgegeben und die Latenz wird kleiner. Je größer der Buffer desto größer wird die Latenz. Man könnte meinen das man einfach immer die kleinstmögliche Samplerate einstellt um so die kleinstmögliche Latenz zu bekommen.

Der Haken ist , das alles in Echtzeit rausgeht, egal ob die Hardware mit dem Umwandeln fertig ist oder nicht, alles muss raus, auch wenns nicht fertig geworden ist. Man hört Knackser und Aussetzer im schlimmsten Fall gibts Mecker und Abstürze, der Rechner ist überfordert. Wählt man eine hohe Samplerate, dauert es länger bis das Paket rausgeht, aber es ist auch genügend Zeit sauber zu rechnen. Das Resultat ist ein sauberes Signal aber eine höhere Latenz.
Der Datenstrom ist dabei immer gleich. Ob wenig, dafür aber schnell hintereinander, oder viel und dafür langsam.

Zitat von RoboBlaster

Trotzdem der Vollständigkeit halber: Ein Note on/off ist 3 Bytes lang und die Übertragung über ein Midi-Kabel dauert 0,96ms.

Kann man sich vorstellen wie ein Zug der das Keyboard verlässt. Die Lok ist schon im Bahnhof(USB Port)angekommen während der letze Wagon noch im Keyboard steckt.
Der Bahnhof hat aber nur alle paar ms mal geöfnet und im schlimmsten Fall schaft es nicht der ganze Zug vor Schliessung einzufahren
Dann käme hier noch mal Latenz hinzu!? Also im schlimmsten Fall ein vielfaches von 5ms je nach länge des Midiworts.

Rechnen wir mal zusammen:

in <1ms ist das Signal am USB Port des Rechners, je nach Länge dauert es nochmal 10ms bis alles drin ist.
Danach wird flux gerechnet im für uns nicht relevanten "Echtzeitbereich" von einigen Nanosekunden.
Schnell raus mit den Daten ans Interface zum wandel..ups..dh. ja wieder über USB raus und wieder warten.. nochmal 5ms im schlimmsten Fall.
Das flotte Interface braucht vielleicht 6ms, bis endlich ein Audiosignal zum Lautspecher geht.

sind zusammen 1ms+10ms+10ms+6ms
Also haben wir eine Latenz von ca.27ms die wir einkalkulieren müssen.
Ach ja, beim Drummodul kommen wirklich noch einige ms Latezn hinzu, da intern noch gerechnet wird.
Roundabout sollte man als eDrummer eine Latenz von 30ms einplanen

Habe ich noch was vergessen?

Klingt ziemlich versiert und plausibel, aber 30ms kann ich mir nicht vorstellen, das wäre ja viel zu viel!
Wie gesagt, ich wollt mal ein Thread eröffnen zur Messung das Latenz. Ihr könnt mir ja mal sagen, was ihr von der methode haltet:

Ich schließe ein normales Mikro an mein USB Interface an. Am selbigen ist auch das TD 11 per MidiKabel dran. Die Sounds am TD 11 sind augeschaltet, die Sounds kommen über VSTi/Cubase. Am Interface ist auch ein Kopfhörer angeschlossen.
Ich lege Das mikro auf die Snare und den Kopfhörer lege ich so, dass er direkt am Mikro liegt. Ich nehme eine Audiospur auf und haue mit dem Stick auf die Snare. Das Mikro nimmt also zwei Signale auf. Einmal das Signal wie der Stick das Fell trifft und einmal wie der Kopfhörer die Ausgabe macht. Da die Eingangslatenz ja für beide Signale gilt,"kürzt" die sich quasi weg und die Differenz zwischen den beiden Signale müsste meine gesamte Latenz zwischen Anschlag und Kopfhörerausgabe sein. Ist der Gedankengang soweit korrekt?

Komplizierter wäre es dann ja noch, die Midilatenz mit reinzubringen. Ich könnte natürlich in Cubase noch eine Midispur aufnehmen und die Differenz sehen, zwischen dem Anschlagsevent und der Midinote. Aber ich denk, da "kürzen" sich die Eingangslatenzen nicht so schön weg. Dann müsste man von dem Audioevent die ASIO Eingangslatenz abziehen (zB 4ms).Also müsste man das Audioevent zB 4ms nach vorne schieben und könnte dann sehen, wieviel später das Midievent aufgezeichnet wurde. Die große Frage ist da naütrlich, wie zuverlässig die Latenzen in Cubase angezeigt werden?

Zitat von gecka88

Die große Frage ist da naütrlich, wie zuverlässig die Latenzen in Cubase angezeigt werden?

sehr genau. die lässt sich ja aus Bustakt und Samplerate zu 100% errechnen. Bei mir wird sie mit 2 Nachkommastellen angezeigt.

Vielleicht eine Möglichkeit Audio, Midi und Gesamtlatenz zu messen:
Mikro an das Pad, Lautsprecher/KH auch direkt ans Mikro.
Vsti laden, Anschlagen , Midi aufzeichnen, Anschlag aufnehmen und das VSTi Audio auch noch mitnehmen.
Dann hättest du 3 Spuren.
Das Midievent wird wohl das erste sein was aufgezeichnet wird, gefolgt von dem Anschlag, vielleicht auch andersrum. Zuletzt wird der VST Sound kommen.
Die Latenz kannst du mit dieser Methode aber nur in Relation ermitteln.

Genau geht das nur mit einem Mehrkanal Oszilloskop.
Signal am Piezotrigger direkt in einen Kanal am Oskar, das ist der Referenzpunkt.
Auf den zweiten Kanal das reine Midisignal was aus dem Rechner wieder raus kommt.
Auf dem dritten das Audio vom VSTi.
Genaugenommen müsstest du erst mal nur die Modullatenz ermitteln: Piezo direkt rein und den Midiausgang am Modul auch in den Oskar.
Alternativ dürfte ein Mikro direkt am Hitpunkt keinen Unterschied zur Piezoabnahme machen, ist ja physikalisch das selbe.

Ich meine sowas hatten wir hier schon mal..

aber mach mal, bin gespannt

gecka88, anstatt ein extra Mikrofon zu nehmen gibt es auch die Möglichkeit, einfach das Piezosignal direkt am Pad abzuzweigen (mit einem Y-Kabel) und es dann genau so weiter zu verwenden wie du es mit dem Mikrofonsignal vor hattest. Es kann aber sein, dass nicht alle Eingänge so ein Signal vertragen.

Beeble, den Rest deines Beitrags jetzt mal außer Acht gelassen: Ich wollte hauptsächlich darauf hinaus, dass du Annahmen wie die folgenden nicht einfach treffen kannst:

Zitat von Beeble

Ohne Verzögerung kommt das Signal am USB Port an

Zitat von Beeble

da stehen sie dann aber sofort zum Weiterverarbeiten zur Verfügung

Zitat von Beeble

hat Null Latenz

Statt dessen musst du auch in all diesen Fällen, auf die du dich jeweils beziehst, mit Latenzen rechnen. Im Idealfall sollten die zwar möglichst gering sein, aber davon kann man nicht pauschal ausgehen. Es gibt leider auch Fälle, in denen genau dort deutliche Latenzen auftreten.

Zitat von RoboBlaster

auch die Möglichkeit, einfach das Piezosignal direkt am Pad abzuzweigen

schrieb ich ja schon.

Zitat von RoboBlaster

Statt dessen musst du auch in all diesen Fällen, auf die du dich jeweils beziehst, mit Latenzen rechnen.

ich rechen gerne mit Latenzen, aber da gibts ausnahmsweise mal keine. Der UART hat keine Latenz und Software hat auch keine.

Zitat von RoboBlaster

Es gibt leider auch Fälle, in denen genau dort deutliche Latenzen auftreten.

Nenn mal bitte so einen Fall, ich verstehe nicht was du damit meinst.

Mal zur Verdeutlich ein Beispiel:
Sagen wir man schlägt um 12:00:000 Uhr aufs Fell (also um 12 Uhr, 0 Minuten und 0 Miliskeunden).
Und gehen von ein paar Vereinfachungen aus. Also ohne Softwarelatenz, CPU und RAM Latenz.
Ausgangswerte: 3ms Modullatenz, 2ms Midilatenz, 40ms ASIO Eingangslatenz, 50ms ASIO Ausgangslatenz. Die Werte sind so gewählt worden, dass es sich einfach verdeutlichen lässt.:

1. 12:00:000 - Schlag aufs Fell
2. 12:00:003 - Modul hat den Schlag "digitalisiert" und Midisignal erzeugt und übers Midikanal geschickt (1. + 3ms Modullatenz)
3. 12:00:005 - Midiaufzeichnung in der DAW und Übertragung des digitalen Snaresounds an das Audiointerface (2. + 2ms Midilatenz des Rechners, ja es ist strittig ob die existiert usw., aber gehen wir mal einfach davon aus, dass die 2ms beträgt)
4. 12:00:040 - Aufnahme in der DAW vom akustischen Schlags auf das Pad durch Mikrofon (1. + 40ms Eingangslatenz)
5. 12:00:055 - Ende der D/A Wandlung des Snare Sounds im Audio Interface, der Sound ertönt an den Kopfhörern (3. + 50ms Ausgangslatenz)
6. 12:00:095 - Aufnahme in der DAW des SNaresounds aus dem Kopfhörern vom Mikrofon (5. + 40ms Eingangslatenz)

So und die Differenz von 12:00:095 (6.) und 12:00:040 (4.) wäre doch die Latenz von 45ms, also 40ms Eingangslatenz, 2ms Midilatenz und 3ms Modullatenz. Die Differenz von 45ms wäre dann genau die Latenz die zwischen Schlag aufs Fell und Sound aus den Kopfhörerern vergehen würden. Das wäre zumindest das Ergebnis was ich logisch erwarten würde. Sehr ihr das soweit auch so?

Zitat von Beeble

Nenn mal bitte so einen Fall, ich verstehe nicht was du damit meinst.

Denk einfach an die praktische Umsetzung. In solchen Interfaces steckt ja i.d.R. letztendlich ein Microcontroller. Ich will jetzt hier keinen halben Programmierkurs schreiben, aber zwischen Hardware, APIs, Funktionsumfang, verwendeten Frameworks, Prioritätensetzung, Programmiererfahrung usw. gibt es eben jede Menge Potenzial, so etwas mit relativ wenig oder eben auch mit jeder Menge Latenz zu implementieren. Auf der PC-Seite gilt Ähnliches.

Zitat von gecka88

Mal zur Verdeutlich ein Beispiel:
Sagen wir man schlägt um 12:00:000 Uhr aufs Fell (also um 12 Uhr, 0 Minuten und 0 Miliskeunden).
Und gehen von ein paar Vereinfachungen aus. Also ohne Softwarelatenz, CPU und RAM Latenz.
Ausgangswerte: 3ms Modullatenz, 2ms Midilatenz, 40ms ASIO Eingangslatenz, 50ms ASIO Ausgangslatenz. Die Werte sind so gewählt worden, dass es sich einfach verdeutlichen lässt.:

1. 12:00:000 - Schlag aufs Fell
2. 12:00:003 - Modul hat den Schlag "digitalisiert" und Midisignal erzeugt und übers Midikanal geschickt (1. + 3ms Modullatenz)
3. 12:00:005 - Midiaufzeichnung in der DAW und Übertragung des digitalen Snaresounds an das Audiointerface (2. + 2ms Midilatenz des Rechners, ja es ist strittig ob die existiert usw., aber gehen wir mal einfach davon aus, dass die 2ms beträgt)
4. 12:00:040 - Aufnahme in der DAW vom akustischen Schlags auf das Pad durch Mikrofon (1. + 40ms Eingangslatenz)
5. 12:00:055 - Ende der D/A Wandlung des Snare Sounds im Audio Interface, der Sound ertönt an den Kopfhörern (3. + 50ms Ausgangslatenz)
6. 12:00:095 - Aufnahme in der DAW des SNaresounds aus dem Kopfhörern vom Mikrofon (5. + 40ms Eingangslatenz)

So und die Differenz von 12:00:095 (6.) und 12:00:040 (4.) wäre doch die Latenz von 45ms, also 40ms Eingangslatenz, 2ms Midilatenz und 3ms Modullatenz. Die Differenz von 45ms wäre dann genau die Latenz die zwischen Schlag aufs Fell und Sound aus den Kopfhörerern vergehen würden. Das wäre zumindest das Ergebnis was ich logisch erwarten würde. Sehr ihr das soweit auch so?

Alles anzeigen

Ich sehe gerade ich habe mich offensichtlich vertan. Ich habe das mal korrigiert und fett gemacht.

Der letzte Abschnitt ist falsch und wäre so korrekt:
So und die Differenz von 12:00:095 (6.) und 12:00:040 (4.) wäre doch die Latenz von 55ms, also 50ms Ausgangslatenz, 2ms Midilatenz und 3ms Modullatenz. Die Differenz von 55ms wäre dann genau die Latenz die zwischen Schlag aufs Fell und Sound aus den Kopfhörerern vergehen würden. Das wäre zumindest das Ergebnis was ich logisch erwarten würde. Seht ihr das soweit auch so?[/quote]

Könnte das mal jemand bestätigen oder dementieren