Emagic Unitor-8 / Midi Interface latency tweaking

Origineel geplaatst door rvooh
welja, Cubase ondersteund de timestamping technologie in de AMT niet, en vice versa..

is dan toch maar logisch dat je het afzet?
ik dacht gehoord te hebben dat het in het verleden wel de bedoeling was dat cubase dit zou gaan ondersteunen, maar dat het er niet van gekomen is...

Het gaat hier om timestamping op driverniveau. Driverlevel timestamping zou eigenlijk de 'opvolger' van de proprietary technieken als AMT, LTB etc. zijn, in de zin dat iedere driver (ieder merk midi-interface dus) het zou kunnen implementeren om strakkere timing te bereiken.

Enerzijds lees ik dat DirectMusic timestamping volledig ondersteunt, anderzijds schijnt het ook voor MME-drivers mogelijk te zijn om timestamping te gebruiken. Er staat een boel info op http://www.wdmaudiodev.de/ maar da's behoorlijk technisch en al snel boven m'n pet... ;) Wie het in detail wil begrijpen moet anders misschien eens contact opnemen met Evert v.d. Poll (de auteur van MidiTest en developer van 3rd-party drivers voor MIDI interfaces).

<EDIT> Het lijkt erop dat er verschil bestaat tussen 'timestamping' in het algemeen en de betekenis van de checkbox 'use system timestamp' in Cubase SX.
De checkbox schakelt vermoedelijk *niet* tussen timestamping aan/uit, maar tussen verschillende reference clocks voor timestamping; zie latere posts... </EDIT>


Verder is het inderdaad zo dat Steinberg ooit native AMT zou gaan ondersteunen (linkje naar de announcement staat hier ergens in deze thread) maar volgens Emagic heeft Steinberg na het ontvangen van de specs nooit meer wat laten horen.
 
Laatst gewijzigd:
mja dan moet de AMT dit ook ondersteunen, en dat is niet het geval denk ik..

is volgens mij idd zo dat er ook in het systeem een "open" timestamping technologie zit (is bij CoreMidi op OSX iig zo)
maar dan moeten de Apple/Emagic drivers dit ook ondersteunen. (dat betwijfel ik, zeker niet op windows)
en cubase ook (maar dat zal wel zo zijn).

Infeite bestaat er op dit forum nog altijd geen allesomvattende thread mbt hardware midi interfaces en hun resultaten op de verschillende platformen en applicaties.
 
Klopt, Rvooh... zover ik kan zien doet CoreMIDI op OSX hetzelfde als wat DirectMusic wil bereiken onder Windows, te weten het implementeren van timestamping op driverniveau. Hierdoor zou custom technology op hoger niveau (zoals Emagic AMT, Steinberg LTB, Motu MTS etc.) niet langer noodzakelijk zijn.

Wat betreft "use system timestamp" wordt het trouwens nog verwarrender...
Volgens deze site staat de "use system timestamp" in Cubase niet voor de keuze tussen het gebruik van timestamping of niet, maar welke clock wordt gebruikt voor het timestampen.

The two-clock problem

All MIDI interfaces on Windows timestamp their data before providing it to the application. This avoids timing problems when the application doesn’t immediately see the incoming notes, perhaps due to higher-priority interrupts, or things chewing up CPU time, or simply a burst of notes too quick for the app to process. The app just looks at the timestamp, does a quick calculation, and poof: instant latency compensation for all MIDI. This has been part of the MIDI driver spec forever.

But Windows provides two different multimedia timers - specifically, one called timeGetTime, or TGT, and one called QueryPerformanceCounter, or QPC. The QPC timer is more precise (although the actual precision is up to the motherboard), and often more accurate, but it’s only available on newer versions of Windows, and there were some motherboards a while back that had major inaccuracies with it, and some current dual-CPU boards still don’t keep the two CPUs in sync.

So drivers, especially Windows MIDI drivers, that descend from older code, or have to work on older OS’s, or that are simply more cautious, are likely to use TGT, which is what Nuendo normally uses; the VST and ASIO specs are based on TGT. Newer drivers, especially those written under DirectMusic, are likely to use QPC. Since the two end up out of sync on most PCs, you’ll end up with timing problems in Nuendo if your MIDI driver uses QPC.

This problem is likely to affect any sequencer, not just Nuendo - although some sequencers might be based around QPC instead of TGT, and thus they’ll have problems with exactly the interfaces that work fine on Nuendo and vice versa. Sonar does have a hidden option that lets you ignore ALL timestamping from the interface, which is fine unless Sonar can’t keep up with the interface, at which point you’ll have really sloppy timing on ANY interface.

Nuendo and Cubase 2.20 provide an option in the DirectMusic settings called “Use system timestamp”. This tells Nuendo that for MIDI tracks, they should keep track of time using QPC, not TGT. This affects only DirectMusic drivers. That means that if you have a Windows MIDI driver that uses QPC, you’ll have to use the emulated DirectMusic drivers, which is the exact opposite of what is normally recommended! Hopefully future versions will offer this option in both DirectMusic and Windows MIDI flavors.

Dit stukje dateert nog van voor de tijd van Cubase SX 3.1, en sindsdien heeft Steinberg inderdaad deze option ook beschikbaar gemaakt voor Windows MIDI drivers (a.k.a. MME drivers, al schijnt dat ook weer niet helemaal accuraat te zijn qua benaming...)
Verder is inderdaa bekend dat er (juist met moderne multicore processors!) behoorlijke issues zijn rondom het in sync houden van de diverse clocks van het systeem.

Toch weet ik het zo net niet. Het verhaal dat MIDI timestamping al zo oud is als de weg naar kralingen en overal al in zit gebakken klopt weer totaal niet met de verhalen die ik heb gelezen over de voordelen van timestamping in DirectMusic vs. het ontbreken hiervan in Windows Midi / MME drivers. En weer ergens anders valt te lezen dat de USB MIDI spec helemaal geen timestamping zou ondersteunen, kortom, raadselachtig... :D

En om dat dan weer te verklaren kwam ik nog wat commentaar tegen op bovenstaande quote van de hand van de genoemde Evert v.d. Poll... toch de moeite van het quoten waard:

I really appreciate what you are trying to do. This page has given me some insights.

However, I feel that there are a couple of points where your information is not correct or incomplete.

To start off: DirectMusic drivers are the only MIDI drivers that timestamp MIDI data. Older drivers could not do this. It's quite a crucial difference. How and where MIDI data is timestamped depends on API used (MME or DirectMusic) and the type of driver. If you use the MME API then MIDI data is timestamped by the MME OS layer, not by the driver. If you use the DirectMusic API then the timestamp is either derived from the driver (if it's a true DirectMusic driver) or done by the OS layer (for emulated ports).
What this means is that the device driver has absolutely no influence on which clock is used to timestamp. The DirectMusic API uses a timestamp based on units of 100 nanoseconds. I am pretty sure that this clock is derived from QueryPerformanceCounter in all cases (but only Microsoft could tell you that for sure).
The MME API uses a timestamp based on units of 1 millisecond. Whether this timestamp is based on QueryPerformanceCounter I could not tell you. What I do know is that the MIDI driver has no influence on this. It's an OS matter.

The effect this information has on the decision which MIDI port to use is hard to say. The big problem is that we can only make educated guesses about what exactly goes on inside Cubase SX. Steinberg is reluctant to provide information, to say the least.

My own feeling is that in most cases it's best to use the DirectMusic ports because they have a much more precise timestamp. If there are no true DirectMusic ports, use the emulated ones.

One good reason to use the windows MIDI ports is if you want to be able to record sysex dumps. This simply does not work with most DirectMusic drivers (and that IS a driver issue).

Read my story about that issue here:
http://miditest.earthvegaconnection.com

It surprises me to read that the Midex8 works best in emulated mode. As far as I know it is not even possible to use it in this mode with Cubase SX. This at least is true for the Midex3 and I'm guessing that the same is true for the Midex8.

I am still investigating the option of 'Use system timestamp'. It is still unclear what Steinberg means by that. My own tests indicated a substantial increase in MIDI timing jitter when this option was CHECKED. This was the case with true DirectMusic ports. Emulated ports didn't seemed to suffer from this effect. I somehow suspect that by checking this option you tell Cubase NOT to use the DirectMusic timestamps, which is the exact opposite of what I thought it would do.

Kortom, vrijwel niemand die het precies weet, omdat de heren leveranciers de zaken ongelofelijk onduidelijk hebben én houden. Je zou je haast af gaan vragen waarom dat is - het kan niet alleen maar te maken hebben met verkoopcijfers...
Nou ja, anyway, de reden dat ik dit nog plaats is dan ook niet dat ik nog verwacht de performance van m'n Unitor op te krikken (ben eigenlijk dik tevree zoals het nu is...), maar gewoon ter lering en vermaak. Ergens hoop ik dat iemand met ontzettende detailkennis de rookwolken rond dit onderwerp nog eens komt wegblazen... ;)
 
Laatst gewijzigd:
Origineel geplaatst door Hanz
Ik ben benieuwd of er nog vragen / opmerkingen zijn!

1) Waarom heb je bij aanschaf van je midi interface destijds niet deze test gedaan om te kijken wat het verschil tussen USB en serieel was?

2) Ben je het met mij eens als ik opmerk dat voor Cubase je beter een midex (tweedehands nu) kan scoren?
 
Beide vragen zijn in deze thread al beantwoord (zie ergens de eerste paar posts...)
Ten overvloede:

1) Seriele kabel was niet voorhanden, en omdat Emagic sterk aanraadt de USB aansluiting te gebruiken heb ik dit zo ook gedaan.

2) Bij een *correct geconfigureerde* Midex zal de MIDI performance vermoedelijk beter zijn als er puur gebruik wordt gemaakt van Cubase.

Echter, aan deze (eerdere) conclusie kan ik toevoegen dat het verschil tussen de Unitor en, zeg, de Midex behoorlijk veel kleiner is als je de Unitor serieel aansluit en system timestamp uitschakelt. Aan de hand van de beperkte set data die Fuse heeft ingestuurd zou je zélfs kunnen concluderen dat de Unitor voor algemeen MIDI gebruik (d.w.z. andere applicaties dan Cubase) beter performt, maar omdat de testset niet identiek was en Fuse geen complete test heeft uitgevoerd met MIDItest is dit niet zeker.

Het enige voordeel dat de Midex biedt boven een willekeurige andere MIDI interface is het bieden van een native DirectMusic driver, waardoor timestamping volledig wordt ondersteund. Hierdoor wordt de oorspronkelijk minder strakke timing van de Midex 'weggestreken' (een soort latency compensation, eigenlijk) tot een strakker geheel.
Let wel, naar ik begrijp uit diverse bronnen kan het nogal een knutselwerk zijn (qua driver instellingen) om de Midex juist te configureren; gebeurt dat niet, dan wordt er juist een matige MIDI performance geleverd. Ik zou dit best eens uit willen zoeken maar ik heb geen Midex tot mijn beschikking. Het lijkt me veel zinvoller dat een bezitter van een Midex dit eens structureel onderzoekt en beschrijft.

In hoeverre het verstandig is om een Unitor te vervangen door een Midex, dat is een puur persoonlijke afweging. Gezien de zeer beperkte latency (nog te compenseren middels het trucje dat ik eerder in deze thread beschreef) en de extreem lage jitter / peak jitter van de Unitor heb ik persoonlijk niet de behoefte om nog te switchen naar een Midex om een zeer beperkte performance winst te behalen. Zou er morgen een gratis Midex voor de deur liggen, dan zou ik deze waarschijnlijk gebruiken voor Cubase (en de Emagic ernaast gebruiken... :D)

De eerdere 'algemene' conclusies van Fuse ("Midi Sync bagger") rondom de (on)stabiliteit van diverse MIDI interfaces tijdens het gebruik van MIDI clock in diverse applicaties, zijn ronduit onjuist. Zelfs als er géén gebruik wordt gemaakt van buffering/timestamping technieken in de (DirectMusic) driver, dan nog kan de AMT-8 / Unitor-8 zeer strakke MIDI clock doorgeven, zo blijkt uit de objectieve tests. De door Fuse gevonden verschillen zijn hoogstens verklaarbaar door foutieve meting, foutieve meetmethode, onjuist geconfigureerde MIDI interfaces of onterecht meegenomen externe invloeden.
Het lijkt me grappig de door Fuse uitgevoerde test nog eens in het openbaar uit te voeren (en inhoudelijk verder te analyseren), bijvoorbeeld een keertje tijdens een meeting, om te kijken of de resultaten te reproduceren zijn...
 
Laatst gewijzigd:
Vraag ik me toch af hoe jij dit alles had kunnen testen zonder dat open source midi test programmaatje?

Maar goed. De beste methode is degene die werkt.
*aait z'n midex8*
 
Origineel geplaatst door fuse
2) Ben je het met mij eens als ik opmerk dat voor Cubase je beter een midex (tweedehands nu) kan scoren?

Als je wil weten hoe het voelt om in je reet geneukt te worden zonder je maagdelijkheid daadwerkelijk op te geven: volmondig ja! Voor al uw andere pleziertjes: geen Steinberg.
 
Origineel geplaatst door Hanz
1) Seriele kabel was niet voorhanden, en omdat Emagic sterk aanraadt de USB aansluiting te gebruiken heb ik dit zo ook gedaan.

beargumenteren ze dit ook?
 
Origineel geplaatst door Catalunya
beargumenteren ze dit ook?

Ja, ergens in een obscuur postje op de Unitor8 Yahoo Group.
Daar schrijft Michael Haydn dat de doorvoersnelheid van de Unitor input-port limited is.
Dwz. de bandbreedte van de RS232 verbinding is theoretisch voldoende voor 6 van de 8 midiports bij volledig gebruik.
De USB verbinding heeft deze limiet niet.
 
Origineel geplaatst door fuse
2) Ben je het met mij eens als ik opmerk dat voor Cubase je beter een midex (tweedehands nu) kan scoren?

Nou, ik zou me nu toch behoorlijk lullig voelen als ik mensen zo'n advies had gegeven. :duivels:
 
En dat komt van iemand die er meer dan 2 jaar over heeft gedaan om een vinkje in de driversettings te vinden.

Slaap maar lekker verder, prutser.
 
kusje!

kusje!

:luv:

... o ja, ik bied 10 euro voor je Midex. Altijd al zo'n mooie paperweight willen hebben!
 
Dat jij goedkoop was wisten we allang.
 
Kies uw wapen dames:

pink_purse.JPG


Of:

impEU2.jpg
 
:D Het gaat er niet om wat je hebt. Maar wat je ermee doet.
 

Attachments

  • pickford-(guns).jpg
    pickford-(guns).jpg
    62,9 KB · Bekeken: 122
Origineel geplaatst door Hanz
Ja, ergens in een obscuur postje op de Unitor8 Yahoo Group.
Daar schrijft Michael Haydn dat de doorvoersnelheid van de Unitor input-port limited is.
Dwz. de bandbreedte van de RS232 verbinding is theoretisch voldoende voor 6 van de 8 midiports bij volledig gebruik.
De USB verbinding heeft deze limiet niet.

hey Thanx Hanz!

Dat is wel een prima argument en een reden een lange USB kabel te scoren, aangezien mijn interface om praktrische redenen 3 meter verwijderd staat van mijn computer. Maakte de lengte van zo'n kabel trouwens nog uit voor de snelheid van de datastroom?
 
Hoi Erik, lengte van de kabel maakt in de praktijk niet veel uit, als het maar niet te gek wordt.
USB schijnt theoretisch gelimiteerd te zijn op 5 meter, waarschijnlijk behaal je in de praktijk zelfs met een langere kabel nog wel resultaat.
Ik weet nog wel dat ik ooit een nullmodemkabel had van een meter of 10 die het gewoon deed, was erg handig om Doom te kunnen spelen met 2 pc's in verschillende kamertjes... ;)

USB is misschien makkelijker, maar gezien de performance (zie resultaat eerder in de thread) zou ik je toch aanraden te gaan voor de RS232 verbinding.
 
Origineel geplaatst door Hanz
USB is misschien makkelijker, maar gezien de performance (zie resultaat eerder in de thread) zou ik je toch aanraden te gaan voor de RS232 verbinding.

Dankjewel Hans

Achterop staat bij die verbinding Mac!! Kun je hem dan ook voor PC gebruiken? Welke stekker moet er dan aan de andere kant zitten om aan te sluiten op de PC?
 
Als het goed is heb je 3 verbindingsmogelijkheden bij een Unitor mkII:
-USB (wel bekend denk ik)
-RS422 Mini-DIN (bijschrift: Mac)
-RS232 DB9 (bijschrift: PC -> aansluiten op de seriele poort van je PC, vermoedelijk ook DB9)

DB9-RS232.gif


Bij de Unitor mkI ontbreekt trouwens de USB aansluiting.

De juiste bedrading van de RS232 verbinding komt erg nauw; het gaat hier om een soort-van nullmodem kabel. Een willekeurige nullmodem zal vrijwel nooit werken; zelf (laten) maken is het devies. De specificatie van de bedrading van deze kabel staat in de manual van de Unitor (tipje: over 2 bladzijden heen, vergeet de 2e bladzijde niet!).

Manual kan je downloaden hier: http://download.info.apple.com/Apple_Support_Area/emagic/Hardware_Manuals/Unitor 8 en.pdf
 
Back
Top