Midi Hardware Jitter

[mink99]

Da es immer wireder fragen und probleme bezüglich Midi Jitter gibt, hab ich einfach mal nachgemessen.

Vorab:

Es geht um Midi Jitter, nicht um Midi Latenz. Der Testaufbau war folgender:

• Testsystem Win7 / 64 16 Gig / AMD 6 Core
• tool ist miditest (http://miditest.earthvegaconnection.com/) 64 bit
• gemessen Midi Clock / SPP / Note On - Off
• kein Sysex
• midikabel verbindet direkt input und output port d.h. input und outputlatenz werden als 1 wert gemessen, beim triggern z.b. einer MPC dürfte sich der Wert halbieren.

Folgende Interfaces

1.) LoopMidi (http://www.tobias-erichsen.de/software/loopmidi.html) um die interne Latenz des Midi Subsystems zu testen
2.) Esi M8UXL mit eigenen Treibern
3.) Motu 128 express mit eigenen Treibern
4.) Roland UM 1G mit eigenen Treibern

der erste Test zeigt, wieviel Jitter das MME / KS Subsystem von Windows erzeugt.

Message latency: 0.02 ms
Message jitter: 0.02 ms

Esi M8U XL

Message latency: 1.14 ms
Message jitter: 0.12 ms

Motu 128 express

Message latency: 4.72 ms
Message jitter: 0.35 ms

UM-1G

Message latency: 1.76 ms
Message jitter: 0.32 ms

ich habe dann noch mit einem No name interface getestet, das ist allerdings jedesmal abgestürzt....


Fazit erstmal:

1.) der hardware jitter ist bei nicht class compliant zugriff vernachlässigbar gering, bei class compliant zugriff fragwürdig (tut mir leid liebe linux fraktion)
2.) dem maximale Jitter der kürzlich vorgestellten Hardware Midiclock ist 460 mikrosekunden, also 0.4 ms, was ein sehr guter Wert ist, aber rein hardwaremässig von einem recht gut ausgestatteten PC auch erreicht werden kann. Edit : es sind 460 nanosekunden , da kommt ein PC mit bordmitteln nicht mit , Sorry das mü hat mich verwirrt

Offene Punkte

Wie mess ich jetzt reproduzierbar Applikationen ?
Wie mess ich jetzt reproduzierbar andere Clockgeber ?
Wie verlässlich ist miditest ?

 

[fanwander]

MIDI-Test muss systemimmanenterweise 50% des Fehlers selbst beitragen. Das ist immer so bei einem System das sich selbst misst.

 

[dbra]

Wie ist das jetzt bei den Class Compliant-Dingern? Sind die so mies, weil der "USB-MIDI-Standard" so mies designt ist, oder liegt's doch an den Betriebssystemen? Muß dazu sagen, das ich keine Ahnung hab, wie das nun im einzelnen technisch gelöst ist.

 

[mink99]

MIDI-Test muss systemimmanenterweise 50% des Fehlers selbst beitragen. Das ist immer so bei einem System das sich selbst misst.

Ich habe, um das etwas abzufedern, zuerst den Test mit loopmidi gemacht. Da es unwahrscheinlich ist, dass loopmidi selber jitter erzeugt, habe ich das "grundrauschen " hier erstmal gemessen.

Genaue aussagen über die Messgenauigkeit kann ich nicht machen, da ich den Code nicht zur Verfügung habe, und selbst wenn, auch keine Lust hätte, den zu analysieren. Es ging mir erstmal um ne Hausnummer , wo sind wir hier überhaupt, sind wir bei einer, 0,1 oder 10 Millisekunden . Ich hatte auch nicht erwartet, dass wir hier unter 0.5 msec sind, selbst wenn wir das verdoppeln, ist 1 msec noch nicht wirklich so schlimm.

Wichtig war mir, nicht das oft beschriebene Messverfahren zu nehmen, indem die geloopten mididaten auf einem zweiten Kanal wieder aufgezeichnet werden, denn dort ist der overhead, den die daw erzeugt, sicherlich höher als der jitter, der auf Seiten Hardware erzeugt wird.

Zum Thema class compliant geh ich morgen mal in die Recherche ....

 

[Anonymous]

das wären dann (der höstwert des gemessenes jitters - 0.35 ms) bei 44,1 kHz/16bit
15(,435) samples hin und her Gewackel bei einmal midi raus (oder hab ich mich verrechnet?)
viel weniger als ich dachte

steht dir auch coremidi zu Verfügung?

 

[7f_ff]

Gruss

 

[mink99]

das wären dann (der höstwert des gemessenes jitters - 0.35 ms) bei 44,1 kHz/16bit
15(,435) samples hin und her Gewackel bei einmal midi raus (oder hab ich mich verrechnet?)
viel weniger als ich dachte

steht dir auch coremidi zu Verfügung?

Dass der jitter viel weniger ist als ich dachte, hat mich auch verwundert.... Ich hatte mit Werten zwischen zwei und 5 msec gerechnet. Ich muss jetzt mal ne Idee bekommen, wie ich Software messe... Ich nehme an, viel Gewackel kommt von der Software .....

Coremidi (nen Mac) hab ich zwar da, aber keine Messtools. Sorry .

 

[Anonymous]

kein problem
ich hab auch was zwischen 2 & 10 ms erwartet
lol, anscheinend haben wir alle zahlen im kopf wo jemand latenz und jitter zusammengezählt hat oder so
nur weiter so, schluss mit den mythen

 

[Anonymous]

http://www.eigenzone.org/2012/12/04/midi-jitter

 

[Anonymous]

Für die Messung von Note On und Off hätte ich einfach Midi-Ox genommen, damit alles aufgezeichnet, als Text abgespeichert, in Midi umgewandelt, analysiert, oder direkt analysiert ohne Umwandlung nach Midi. Mir gefällt die Umwandlung nach Midi, dann kann man sich auch die Ergenisse anhören, ob man selbst auch etwas feststellen kann.

SPP, weiss ich nicht, ob das auch von Midi-Ox aufgezeichnet werden kann.

Midi-Clock, wird leider von Midi-Ox nicht aufgezeichnet, soweit ich feststellen konnte. Auch kann man Midi-Clock Events, leider, nicht in Note On+Off umwandeln, über Filter. Schade.

Immerhin den Note On/Off Teil könnte man zumindest gut mit Midi-Ox analysieren. Auch als Vergleich zu Messwertern anderswo. Am besten mehrere Methoden durchführen, die Ergebnisse der Methoden auch untereinander vergleichen, wenn es da keine Übereinstimmung gibt, viel Spass.

 

[Anonymous]

Offene Punkte

Wie mess ich jetzt reproduzierbar Applikationen ?
Wie mess ich jetzt reproduzierbar andere Clockgeber ?
Wie verlässlich ist miditest ?

Source-Gerät (Hardware oder 1. Laptop), Messgerät (2. Laptop)
Im Messgerät lädt man Midi-Ox, über die Midischnittstelle laufen die Events rein. Daraus folgt, immer gleiche Anfangs-/Messbedingungen für die Events von aussen. Im Messgerät, kein Internet, keine Firewall, keine anderen Anwendungen.

 

[peebee]

http://www.midiclock.de/data/Midiclock_Jitter_DE.pdf

 

[mink99]

http://www.midiclock.de/data/Midiclock_Jitter_DE.pdf

Gerade dieses Dokument, was nicht wirklich seriös ist, hat mich veranlasst , selber mal zu testen.

1.) wenn ich mit einer externen midi Clock arbeite, die eine daw (z.b. ableton) fernsteuert, dann kann ich diese nur per midi Interface in die daw einbinden, d.h. die daw erhält die Clock über das natürlich jitterbehaftete midi Interface. Deshalb wollte ich feststellen, wieviel overhead ein midi Interface (kein 10 Euro Teil , sondern ein ernstzunehmendes) erzeugt.
2.) dabei ist noch zu beachten, wie genau die daw bei externer Synchronisation dann der Clock folgen kann.
3.) Auch ist hier auf eine möglichst geringe Latenz und jitter im audiopfad zu achten, da natürlich die Latenz der anderen angeschlossenen Geräte, die sich gegen die gleiche Clock synchronisieren, nicht bekannt ist.

Derzeit haben wir die Situation, dass wir bei computerunterstützter Musik zwar audio sehr präzise und nahezu jitterfrei abspielen können, dass aber externe midi Geräte im Timing Probleme haben. Es bringt jetzt überhaupt nichts, wenn jetzt durch ein solches Gerät wie die midiclock HW plötzlich midi tight läuft, und dafür audio dann jittert.

 

[max123]

Das sieht ja schonmal sehr interessant aus was du da gemessen hast. Mein Senf dazu ist folgender:

2.) dem maximale Jitter der kürzlich vorgestellten Hardware Midiclock ist 460 mikrosekunden, also 0.4 ms, was ein sehr guter Wert ist, aber rein hardwaremässig von einem recht gut ausgestatteten PC auch erreicht werden kann.

Fast, du hast dich um den Faktor 1000 verlesen, es sind 460 NANOsekunden, das macht theoretische 0.015 Samples Jitter bei der angestellten Rechnung.

Wie mess ich jetzt reproduzierbar Applikationen ?
Wie mess ich jetzt reproduzierbar andere Clockgeber ?

Am besten misst du sowas natürlich mit einem Oszilloskop. Für eine erste Abschätzung kannst du aber deine Soundkarte verwenden und den Test wie bei Innerclocksystems schön beschrieben ist durchführen. (http://www.innerclocksystems.com/New ICS Clock Watch.html)
Damit hast du natürlich nur eine Zeitauflösung, die der Abtastrate deiner Soundkarte entspricht, auf Sampleebene kannst du aber natürlich damit auf jeden Fall eine Aussage machen.

Das Stichwort zur Synchronisation eine DAW auf einen externen Takt lautet PLL. Eine PLL gleicht dir - sofern sie korrekt dimensioniert ist - den Jitter gut aus und reagiert damit auch immer etwas träge auf sprungförmige Veränderungen der Vorgabe. Bestes Beispiel ist Live8, das bei zu starken Änderungen gern mal ins Stottern gerät. Je weniger Jitter man der PLL zumutet, desto weniger oszilliert sie um den eigentlichen Takt umher. Das ist die Aussage, die ich auch schon im midiclock-Thread getroffen habe. Für die Unseriösität unseres Jitter-Reports auf der Webseite http://www.midiclock.de entschuldige ich mich hiermit Und werde bei Gelegenheit mal etwas Fundierteres verfassen!

 

[mink99]

Das sieht ja schonmal sehr interessant aus was du da gemessen hast. Mein Senf dazu ist folgender:

2.) dem maximale Jitter der kürzlich vorgestellten Hardware Midiclock ist 460 mikrosekunden, also 0.4 ms, was ein sehr guter Wert ist, aber rein hardwaremässig von einem recht gut ausgestatteten PC auch erreicht werden kann.

Fast, du hast dich um den Faktor 1000 verlesen, es sind 460 NANOsekunden, das macht theoretische 0.015 Samples Jitter bei der angestellten Rechnung.

Sorry, die Abkürzung uSec, die du benutzt hast, sind mikrosekunden

Zum Thema Synchronisation :

Jede Kette ist so stark wie ihr schwächstes Glied. Selbst wenn ich eine supergenaue Clock über ein jitterndes system in den Rechner einspiele, so erreiche ich maximal die Genauigkeit des midi Interfaces als dem derzeit schwächsten Glied . Ausserdem fällt zumindest bei ableton (weiss aber nicht, ob das auch für 9 gilt) die pdc flach und internes midi kann auch nicht mehr kompensiert werden.

Nicht falsch verstehen : als masterclock in einem rein auf Hardware basierten Setup ist midiclock ne prima Sache. Through Box dran und fertig....

In einem Hybrid system pc/hardware denk ich, muss man schon genau wissen, auf was man sich einlässt.

 

[max123]

Die us, wo ist sie so benutzt? Hab ich was übersehen?

Jede Kette ist so stark wie ihr schwächstes Glied. Selbst wenn ich eine supergenaue Clock über ein jitterndes system in den Rechner einspiele, so erreiche ich maximal die Genauigkeit des midi Interfaces als dem derzeit schwächsten Glied .

Da stimme ich dir voll und ganz zu! Ich formuliere es aber um und sage, wenn bisher schon selbst die Masterclock aus einer DAW einen Jitter von einigen ms aufweist, dann wird das nicht besser wenn sich eine DAW darauf synchronisieren soll, die Jitter addieren sich im worst case.

Zur Veranschaulichung der Wirkungsweise einer PLL als Jitterreduktion soll dieses Bild hier dienen. Das gelbe ist eine jitternde Clock, das blaue das Ausgangssignal der PLL. Quelle der Grafik ist RME.

Diese Art von PLL kann man auch in Software realisieren. Aber sie hat halt ihre Grenzen. Und wenn du dir den Jitter noch größer als auf dem Bild vorstellst, dann ist auch die PLL nicht mehr in der Lage, sich stabil darauf einzuschwingen.

Solange der Jitter aber (durch ein gutes Interface) in dem Bereich liegt, für den die PLL ausgelegt wurde, so kann man (sofern man es sauber implementiert hat) den Jitter glattbügeln. Und dann ist alles auf einmal nur noch Latenz

 

[mink99]

Ist angepasst ...,

 

[swissdoc]

Und dann ist alles auf einmal nur noch Latenz

Wobei sich dann die Frage stellt, ob die Latenz stabil ist, oder auch mit einem Jitter behaftet ist

 

[mink99]

Ich bin dabei, die nächste Runde Test einzuleiten . Diesmal externe Synchronisation von Apps .

In der Vorbereitung bin ich auf ein interessantes Phänomen gestossen.

Testaufbau:

Rechner wie gehabt. Mit midiclock Software auf loopmidi , 120 bpm

Loopmidi Out an ableton 8 Clock in , ableton auf externe sync, einfachen 4taktiken drumloop geladen
Loopmidi Out an midiclockdetect

Play

Für die ersten 4 Takte ist ableton grausam Out of sync. Es startet mit der bpm des Projekts und schwingt sich langsam ein, bis nach ca 4 Takten die bpm Anzeige zwischen 119 und 122 bpm schwankt. Wenn die bpm des Projekts schon auf 120 bpm stehen, dann ist das einschwingen schneller, es braucht 1-2 Takte, bis das schwanken 119-122 erreicht wird.

Midiclockdetect ist nach ca 1 Takt stabil auf 120

Dies ist keine echte Messung , lediglich die bpm Anzeige von ableton war hier das Messgerät . Wie zuverlässig die ist, frage an die ableton Spezialisten hier.

Bezüglich der Genauigkeit von midiclock Software und midiclockdetect stehe ich in Kontakt mit dem Developer. Der ist übrigens total nett. Wie auch die Jungs von der Hardware Clock....

 

[Anonymous]

hm, ich bin kein ableton experte aber
auf die bpm anzeige in ableton würd ich mich nicht verlassen
so zur Orientierung ( wir sind bei Hausnummern so&so ja)
aber bei allen daws hat das anzeigen von was auch immer keine priorität - hauptsache audio fängt nicht an zu stottern ...
(mag bei protools und pyramix anders sein, keine Ahnung)
aber bei dem gängigem kram ...
da hilft wohl nur nachher im audioeditor nachschauen

 

[max123]

Hallo Mink,

schoen, dass du das weitertreibst! Auf die BPM-Anzeige von Ableton kannst du garnichts geben.

Ich wuerde an deiner Stelle wie die Jungs von Innerclock Systems vorgehen, um die BPM deiner Messung zu bestimmen. Das ist zwar sehr sehr muehsehlig, dafuer aber billig:

Nutz dein Abletonprojekt wie gehabt und synce es mit einer beliebigen midiclock, lege aber auf eine Spur ein Klick mit hartem Attack, damit du genau sehen kannst wann der Ton anfängt. Gebe diese Spur auf einem seperaten Kanal deiner Soundkarte auf und recorde sie mit einem anderen System. Analysiere dann den Abstand der Samples und berechne daraus die BPM, die Ableton tatsächlich interpretiert. Damit hast du eine Aussage ueber den Jitter deines Sounds.

Dass sich Ableton die ersten paar Takte einschwingt ist voellig normal und deutet auf eine langsame Sprungantwort / große Zeitkonstante des Clock-Filters hin. Große Zeitkonstanten bedeuten immer ein glaettenderes Verhalten von Filtern und mehr Stabilität, dafür aber auch eine trägere Reaktion auf schlagartigen Start.

Das muss du dir wie eine große Schaukel vorstellen: je größer die Masse ist die da schaukelt, desto weniger lässt sie sich durch kleinere Ungenauigkeiten beim Anschubsen vom schaukeln abhalten.

Ableton hat dazu nie viel geschrieben, ich bin da auch nicht weiter vorgedrungen als sporadischen Emailkontakt und Vertröstungen. https://forum.ableton.com/viewtopic.php?f=1&t=165235 ist ein kleiner Hinweis auf ihre (notwendige!) PLL/Tiefpassfilterung der eingehenden Clocks. Den Algorithmus könnte man aber noch gehörig verbessern!

 

[tom f]

ohne jetzt alles zu lesen: was nutzt denn bitte der reine jitter-wert beim ausgebenden system wenn jeder empfänger eben doch zwischen 2 bis 15 ms lag hat, bzw. selber auch nich jittert?
am ende zählt die gesamtperformance und man kann die beiden werte nicht trennen

mfg

 

[mink99]

Eine reine Latenz kann ausgeglichen werden. Wenn man immer konstant 6 ms Verzögerung hat, so kann man die midispur um genau diese 6 ms vorziehen und alles passt.

Bei jitter geht das nicht. Wenn hier der Note on je nach dem mal 2 ms früher und mal zwei ms später kommt, dann wird es herausfordernd das auszugleichen.

Wenn das bei einem Clock Signal passiert, dann ist das in den Auswirkungen noch viel schwerwiegender. Wenn dann die Sounds, die vom sequencer kommen," nur " phasenverschiebungen haben, ist das noch gut , wenn man die eigentlich zum gleichen Zeitpunkt auftreten sollenden Töne einzeln hört, ist die Katastrophe da....

Aber mal ein Gedanke ..... Wie gross ist eigentlich der jitter eines menschlichen Schlagzeugers ?

 

[powmax]

Real Test sind doch immer was Feines...

DAW Midi Out per USB in SL MKII von da via DIN Kabel in die ESI M8U Midi Patchbay dann zum Shruthi - Audio Out in Wandler -> USB Aufnahme DAW - vergehen bei mir 6-7 ms. Der Wert schwankt immer ein wenig was wohl am Synth liegt. Selbes Spiel mit dem Kawai K3 -> 16 - 20 ms

 

[mink99]

Real Test sind doch immer was Feines...

DAW Midi Out per USB in SL MKII von da via DIN Kabel in die ESI M8U Midi Patchbay dann zum Shruthi - Audio Out in Wandler -> USB Aufnahme DAW - vergehen bei mir 6-7 ms. Der Wert schwankt immer ein wenig was wohl am Synth liegt. Selbes Spiel mit dem Kawai K3 -> 16 - 20 ms

Könntest du mal testweise das ganze ohne die Patchbay messen, wäre mal interessant, was die Patchbay an overhead produziert ? Aber nur wenn das keine umfangreichen Umbauten bedeutet .....

Obwohl ich sagen muss, dass das sl mk2 nicht unbedingt das ideale USB midi Interface ist. Ist allerdings unglaublich praktisch, wenn der Rechner aus ist, hat man die midi Outs auch zur Verfügung . Mach ich bei meinem axiom auch .

 

[powmax]

Moin Mink,

da ist kein großer Unterschied, zumindest für mich nicht 100% meßbar, weil der Shruthi immer im Timing schwankt: ca. 1 bis max. 2 ms. Oder anders ausgedrückt: gehe ich davon aus, dass die Latenz vom SL MK2 zur Patchbay sehr gering ist - sicher unter 1 ms.

grüsslies
ilse

 

[mink99]

Tönt logisch ....

 

[powmax]

Wenn man nun 2 ms vom Wandler + 1 ms USB Midi Gedöns abzieht heißt das der Shruthi hat eine Reaktionszeit vom Midi In bis zum Audio Output von ca. 2 - 3 ms - ja deees is doch Suppieeee

geüsslies
ilse

 

[Anonymous]

öhm, nebenbei und etwas ot
passt aber zu dem ganzen dinge die zusammen im sync krach machen wollen zeug
2 (oder mehr) computer und die gleiche zeit ... das geht nicht ohne wordclock von aussen, die werden immer driften weil der Quarz ... blah blah
ich bin gespannt wie ein flitzebogen wie bitwig das lösen will ...

 

[dbra]

Hast recht, da ist schon Präzision im Attosekundenbereich gefragt. Sonst kann das nichts werden.