Midi Hardware Jitter

Dieses Thema im Forum "Controller & MIDI" wurde erstellt von mink99, 23. April 2013.

  1. mink99

    mink99 aktiviert

    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 ?
     
  2. MIDI-Test muss systemimmanenterweise 50% des Fehlers selbst beitragen. Das ist immer so bei einem System das sich selbst misst.
     
  3. dbra

    dbra Ehrenpräsident des Technofreunde Ohlenburg e.V.

    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.
     
  4. mink99

    mink99 aktiviert

    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 ....
     
  5. Anonymous

    Anonymous Guest

    :supi:

    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 :mrgreen:

    steht dir auch coremidi zu Verfügung? :mrgreen: :kaffee:
     
  6. 7f_ff

    7f_ff aktiviert

    :supi:


    Gruss
     
  7. mink99

    mink99 aktiviert

    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 .
     
  8. Anonymous

    Anonymous Guest

    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 :selfhammer:
    nur weiter so, schluss mit den mythen :fressen:
     
  9. Anonymous

    Anonymous Guest

  10. Anonymous

    Anonymous Guest

    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.
     
  11. Anonymous

    Anonymous Guest

    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.
     
  12. peebee

    peebee -

  13. mink99

    mink99 aktiviert

    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.
     
  14. max123

    max123 -

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

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

    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!
     
  15. mink99

    mink99 aktiviert

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

    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.
     
  16. max123

    max123 -

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


    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.

    [​IMG]

    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 :)
     
  17. mink99

    mink99 aktiviert

    Ist angepasst ...,
     
  18. swissdoc

    swissdoc back on duty

    Wobei sich dann die Frage stellt, ob die Latenz stabil ist, oder auch mit einem Jitter behaftet ist :)
     
  19. mink99

    mink99 aktiviert

    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....
     
  20. Anonymous

    Anonymous Guest

    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
     
  21. max123

    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!
     
  22. tom f

    tom f Moderator

    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
     
  23. mink99

    mink99 aktiviert

    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 ?
     
  24. powmax

    powmax aktiviert

    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 :shock:
     
  25. mink99

    mink99 aktiviert

    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 ..... :nihao:

    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 . :roll:
     
  26. powmax

    powmax aktiviert

    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
     
  27. mink99

    mink99 aktiviert

    Tönt logisch ....
     
  28. powmax

    powmax aktiviert

    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
     
  29. Anonymous

    Anonymous Guest

    ö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 :invader2:
    ich bin gespannt wie ein flitzebogen wie bitwig das lösen will ...
     
  30. dbra

    dbra Ehrenpräsident des Technofreunde Ohlenburg e.V.

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

Diese Seite empfehlen