Midi Hardware Jitter

...also mal einfach gesagt, um so schneller der Multiplexer ist, umso "verzerrter"/"verschmierter" wird das digitale Signal.
Im Bereich der Übertragungstechnik sollte das ja immer ein schöner Puls 50% sein :D .
Ist es aber leider nicht.
Wenn dieser Puls nun zeitlich verschmiert wird kann es zu einer Fehlinterpretation kommen, anstatt "1" wird "0" gelesen, oder umgekehrt.

Früher(nachm Krieg, BTX :mrgreen: ) gabs schöne Protokolle wie z.B. X.25 die immer noch überprüft haben ob das Datenpaket auch richtig angekommen ist, und falls nicht das Ganze nochmal geschickt haben, die Netzwerke der Post waren nach dem Krieg ja kaum ausgelastet, da konnte man schon mal so mit Informationen um sich schmeissen :mrgreen: !
 
@Mink - habe mir eben Reaper installiert - die Midi Verzögerungen sind ähnlich, muß ich aber nochmal genauer testen...
wo zum Geier stellt man denn den Metro Klick beim Pre Recorden (hätte gerne 1 Takt Vorzähler) ein ???

UPDATE: Jau 6-7 ms beim Shruthi - paßt ! :)

grüsslies
ilse
 
Xpander-Kumpel schrieb:
Hach ist diese Jitter-Diskussion schön!

Im Berufsleben habe ich auch damit zu tun, aber da ist was völlig anderes mit gemeint("verschmiertes" Signal, was eine Signalfehlinterpretation auslöst, Nachrichtentechnik), als das was hier diskutiert wird.
Deshalb halte ich mal lieber mein kleines Schnäutzchen...
Ohne die mathematische Formel kann man natürlich unendlich weiterdiskutieren. Du kannst die Formel bestimmt jetzt hier aufschreiben, oder? Ausserdem nein, Jitter sollte oft die gleiche oder fast gleiche Bedeutung haben. Ansonsten, ich möchte unterschiedliche Formeln für Jitter und ihre Namen sehen. Danke.
 
Reden wir dann hier wirklich von Jitter nur weil das in der Messsoftware namentlich so steht, oder gehts nicht eigentlich eher um Latenzen?
 
ich hab mal Wiki bemüht(obwohl da ja auch nicht alles rechtens ist:

"Als Jitter [ˈdʒɪtɚ] (engl. für „Fluktuation“ oder „Schwankung“) bezeichnet man das zeitliche Taktzittern bei der Übertragung von Digitalsignalen, eine leichte Genauigkeitsschwankung im Übertragungstakt (engl. Clock). Jitter ist als Störsignal im Normalfall unerwünscht. Allgemeiner ist Jitter in der Übertragungstechnik ein abrupter und unerwünschter Wechsel der Signalcharakteristik. Dies kann sowohl Amplitude als auch Frequenz und Phasenlage betreffen. Der Jitter ist die erste Ableitung einer Verzögerung (engl. Delay). Die spektrale Darstellung der zeitlichen Abweichungen wird als Phasenrauschen bezeichnet. Jitter ist nicht zu verwechseln mit Quantisierungsfehlern.

In der Netzwerktechnik wird mit Jitter außerdem die Varianz der Laufzeit von Datenpaketen bezeichnet. Dieser Effekt ist insbesondere bei Multimedia-Anwendungen im Internet (wie Internet-Radio und Internet-Telefonie) störend, da dadurch Pakete zu spät oder zu früh eintreffen können, um noch rechtzeitig mit ausgegeben werden zu können. Der Effekt wird durch einen sogenannten Jitterbuffer, einen speziellen „Datenpuffer“ reduziert, allerdings zum Preis von zusätzlicher Laufzeit, was vor allem bei Dialoganwendungen stört. Dieser Effekt spielt außerdem in der Prozessleittechnik eine Rolle. Kritische Prozessinformationen müssen innerhalb einer bestimmten Zeit verschickt und empfangen werden. Wird der Jitter zu groß, ist ein rechtzeitiges Eintreffen der kritischen Prozessinformationen nicht gewährleistet."

Satz Nummer 3 ist das Problem was man in der ÜT manchmal hat, ich vermute mal das das nicht das gleiche Problem ist was bei Midiverbindungen auftritt.
 
TonE schrieb:
Jitter sollte oft die gleiche oder fast gleiche Bedeutung haben. Ansonsten, ich möchte unterschiedliche Formeln für Jitter und ihre Namen sehen. Danke.

http://de.wikipedia.org/wiki/Jitter

Hier im Zusammenhang mit midi sind wir zugegebenermassen etwas vereinfachend .

Zum einen interessiert uns die maximale Abweichung , in msec ,
Zum anderen interessieren uns nur ausschliesslich frequenzverschiebungen, amplitudenverschiebungen und phasenverschiebungen nicht ,
die deterministischen Anteile können hier als Latenz herausgerechnet werden ....

Latenz ist hier die immer gleiche Verschiebung der Ticks , jitter die variable Verschiebung ...



In der signaltechnik werden alle Werte benötigt .....
 
Xpander-Kumpel schrieb:
Wir planen und betreiben ein separates Taktnetz für die SDH und DWDM, das heißt es gibt Planungsprämissen wieviele Netzelemente hintereinandergeschaltet werden dürfen damit alles läuft(Ringproblematik, Taktschleifen etc.).
Dann gibts noch verschiedene Taktqualitäten, wobei das fast alles an den Geräten so megastrong im Takt ist, das man sich da kaum noch Gedanken machen muß.
Als Clock haben wir meistens Cäsium-Normale oder leiten den Takt von der Hauptvermittlungseinheit, GPS-Takt oder den Netzübergängen ab.
Seit ca.16Jahren bei verschiedenen Betreibern, fast noch nie ein Problem damit gehabt.

Bei welchem Verein arbeitest Du denn? Klingt ja doch sehr nach Telco-Biz :) Vendor von Systemtechnik, Operator oder Diensteanbieter? Bei mir ist es ein Operator, Netztechnik, OSS...
Lustig ist ja noch Synchronisation über IP bei z.B. Pico BTS, Femto Zellen oder auch all IP und LTE.

Bei LTE sollte übrigens ein vernünftiger Operator den Traffic von den eNodeBs zum MME über IPSEC abwickeln.
 
Mannesmann Mobilfunk, Vodafone, Deutsche Bahn.
Netzplanung GSM, UMTS, LTE, ATM, Richtfunk, SDH, IP, DWDM, Core, Kabel, MSC/BSC, RNC, Takt, Media Gateway, blahblahblubb :D also alles was hinter der Funkantenne der Basisstation/Node B kommt.
 
swissdoc schrieb:
Xpander-Kumpel schrieb:
Wir planen und betreiben ein separates Taktnetz für die SDH und DWDM, das heißt es gibt Planungsprämissen wieviele Netzelemente hintereinandergeschaltet werden dürfen damit alles läuft(Ringproblematik, Taktschleifen etc.).
Dann gibts noch verschiedene Taktqualitäten, wobei das fast alles an den Geräten so megastrong im Takt ist, das man sich da kaum noch Gedanken machen muß.
Als Clock haben wir meistens Cäsium-Normale oder leiten den Takt von der Hauptvermittlungseinheit, GPS-Takt oder den Netzübergängen ab.
Seit ca.16Jahren bei verschiedenen Betreibern, fast noch nie ein Problem damit gehabt.

Bei welchem Verein arbeitest Du denn? Klingt ja doch sehr nach Telco-Biz :) Vendor von Systemtechnik, Operator oder Diensteanbieter? Bei mir ist es ein Operator, Netztechnik, OSS...
Lustig ist ja noch Synchronisation über IP bei z.B. Pico BTS, Femto Zellen oder auch all IP und LTE.

Bei LTE sollte übrigens ein vernünftiger Operator den Traffic von den eNodeBs zum MME über IPSEC abwickeln.

Die all Ip-Lösung wurde ja schön von z.B.Huawei unter der Prämisse verkauft das, wie der Name sagt, alles über IP läuft.
Die Realität sieht leider ganz anders aus, alle Voice-Anwendungen und die Synchronisation laufen wie eh und je über PCM30/G.703.
Schön die Katze im Sack gekauft und toll jetzt auch dahinter zwei verschiedene Netze(Paket und Leitung) die eine völlig unterschiedliche Architektur haben betreiben zu müssen. Es gibt wohl auch synchrone IP-Netzmöglichkeiten, aber das hat leider grad niemand zur Hand :D .
 
Was ist mit class compliant, warum sind die so schlecht ?

Zunächst einmal, class compliant heisst nicht gut oder schlecht. Es heisst einfach nur, das es einer bestimmten Spezifikation
(Usbmidi1 oder usbmidi2, die links hab ich verschusselt) entspricht.
Probleme mit class compliant Geräten , ausser die Hardware ist Schrott, gibt es eigentlich nur unter Windows, iOS und osx haben dort keine Schwierigkeiten. Häufig werden bei hochpreisigen Geräten für Windows Treiber angeboten, während sie unter coremidi classcompliant betrieben werden.

Es ist der generische midi Treiber für windows, der hier die Probleme bereitet.
Drei Probleme sind dokumentiert, ein viertes wurde mit Windows 7 nach nur 15 Jahren behoben.

Erstes Problem : der gegnerische Treiber ist nicht multiclientfähig, mehrere Applikationen können nicht gleichzeitig auf dasselbe Gerät zugreifen. Spezielle Treiber des Herstellers machen dies möglich, wenn es die Hardware und das Entwicklungsbudget hergibt. Spezielle Tricks auch... :roll:

Zweites Problem: der windowstreiber kann keine zwei gleichen Geräte kaskadieren, d.h. man muss , wenn man mehrere usb midi interfaces verwenden will, unterschiedliche Geräte nehmen. Das war lange das Problem mit den esi Geräten , bis es hier Treiber gab .

Drittes Problem : die buffergrösse für sysex Messages ist beim Windows Treiber angeblich nur 1024 Bytes gross, was nahezu jeden sysex Transfer scheitern lässt.

Gelöst wurde inzwischen das Problem Nummer 4 , dass alle midi Interfaces "USB Audio device" mit laufender Nummer heissen, und sich von zeit zur zeit die Nummer des konkreten Interfaces änderte. Dies führte dazu, dass bei einem gespeicherten Projekt nach dem Laden die Zuordnung der angeschlossenen Geräte auch nicht mehr stimmte.

Berichtet wird auch, dass das timestamping einzelner midi Messages potenziell fehlerbehaftet ist, wenn man die die midi Daten erzeugende Applikation genau nach den Microsoft Vorgaben schreibt. Ob das allerdings heute noch gilt, kann ich nicht sagen.....
 
powmax schrieb:
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
Wenn ich den Shruthi eine Midi Note schickt und mir das am Oszi anschau sieht das für mich so aus, dass
der kleine immer auf einen/den nächsten 0-Durchgang der Wavtable wartet bis der den VCA wieder neu triggert
somit kommt bei solchen digitalen Synths diese Zeitschwankung auch dazu und das hat nix mit Midi Jitter zu tun ...
ölg widy
 
mal ne frage, ich hab hier 2 bis 3 geräte (hardware) die midi clock ausgeben können. wie kann ich am sinnvollsten messen welche die "beste" clock ist?
es handelt sich um einen OP-1, ein OPLAB und die R&M Midiclock. natürlich denke ich das die midiclock von R&M am saubersten läuft aber ich würd einfach gern mal die clocks der 3 geräte gegeneinander "antreten" lassen. jemand ne idee wie sich das bewerkstelligen liese?
 
Wenn du einen wirklich stabilen Rechner hast ....
Nimmst du dir nen wirklich stabilen Slave , dein freundlicher Nachbar hat bestimmt noch einen rumliegen ...
Eine sr 16 oder
Eine Boss dr670 oder was in der Geräteklasse
Dort machst du dir nen simpel Beat (16tel HH , 1/4 Bd und Snare auf 2&4)

Dann nimmst du in deiner daw mit diesem beat jeweils einen Audio track auf, mit der gleichen bpm
In der daw stellst du die gleichen bpm ein, schneidest in jedem Track die ersten 2 Takte ab und zupfst dann die 3 Tracks in das Raster , da sie wahrscheinlich nicht exakt gleich schnell sind.

Bei extremem Zoom wirst du dann sehen, wie die einzelnen Beats in einem Track ein paar Samples früher oder später sind. Immer so 1-2 . Der am wenigsten abweicht ist der beste Master .
 
mink99 schrieb:
Wenn du einen wirklich stabilen Rechner hast ....
Nimmst du dir nen wirklich stabilen Slave , dein freundlicher Nachbar hat bestimmt noch einen rumliegen ...
Eine sr 16 oder
Eine Boss dr670 oder was in der Geräteklasse
Dort machst du dir nen simpel Beat (16tel HH , 1/4 Bd und Snare auf 2&4)

Dann nimmst du in deiner daw mit diesem beat jeweils einen Audio track auf, mit der gleichen bpm
In der daw stellst du die gleichen bpm ein, schneidest in jedem Track die ersten 2 Takte ab und zupfst dann die 3 Tracks in das Raster , da sie wahrscheinlich nicht exakt gleich schnell sind.

Bei extremem Zoom wirst du dann sehen, wie die einzelnen Beats in einem Track ein paar Samples früher oder später sind. Immer so 1-2 . Der am wenigsten abweicht ist der beste Master .

haha das einzige gerät das ich auftreiben könnte wäre der stabile rechner (mein macbook) alles andere wüsst ich grad nich woher ich nehmen sollte. elektronik musiker die sowas haben sind hier selten :D

aber egal. ich nehm einfach die midi clock als master gerät und fertig. dafür hab ich sie immerhin gekauft und so kann ich jedes gerät aus der reihe nach belieben zuschalten und mit resync wieder richtig eintakten. ich hab auch vorhin mal einen (nicht representativen) test gemacht und muss sagen dass das ipad am wenigsten zuckt wenn es von der midiclock gesynced wird (und das sogar via wlan!)
 
@max123: Wenn auch völlig üblich in der Wissenschaft, ist es trotzdem immer fragwürdig, wenn die Untersucher ihr eigenes Produkt einbeziehen (wg. bewußtem und unbewußtem Bias). Außerdem ist bei mir der Unterschied zwischen 38ms und 400ns zwei Größenordnungen und nicht "drei" wie in den Conclusions geschrieben.

Grundsätzlich wäre ein Timing-Jitter von 38ms katastrophal, den hört jeder, und man muß sein Setup schon unglaublich schlecht konfigurieren, um auf solche großen Werte zu kommen.

Man muß immerhin bedenken, daß bei 120 BPM alle 20.8ms ein 0xF8 eintrifft. Das ist eine Frequenz von 48Hz. Um 38ms Jitter zu erreichen, müßte man schon mindestens eine MIDI-Clock aus der Rechnung nehmen (z.B. durch einen Wackelkontakt) und die Glättung/Prädiktion des Empfängers ausschalten.

Die MIDI-Clock darf sich sogar zwischen die Bytes der MIDI-Kommandos drängen und wird daher bei einem mittelmäßigen Master nur um maximal 10/31250 = 0.32ms von der eigentlichen Position verzögert. Ein perfekter Master verzögert bis 0.16ms eher das kollidierende MIDI-Kommando (da er ja "weiß", wann genau er die nächste MIDI-Clock schicken muß), so daß bei einem guten Sender selbst unter Belastung ein maximaler Jitter von nur +-160ns auftritt.

Was will ich mit dem ganzen Zeug sagen: 38ms Jitter ist nie das Problem eines mittelmäßigen oder besseren Senders, sondern des Setups und/oder Empfängers/Slaves.
 
swissdoc schrieb:
C0r€ schrieb:
Die Webseite funktioniert leider nicht mehr!

miditest (http://miditest.earthvegaconnection.com/) 64 bit

Ich habe die Datei aber bei mir noch gefunden.

Hast Du beide Versionen 32/64 bit und könntest Du diese evtl. verfügbar machen? Wäre super. Danke.

Edit: Version 4.6 und die Page an sich sind unter web.archive.org noch zu finden.


Jep THX
am 27Jul2010 ist es noch zu finden.
Die 64Bit scheint obsolet schade :cry:
 


Zurück
Oben