Jump to content


Please note: You can easily log in to MPN using your Facebook account!

MIDI 2.0 Timing Resolution - More Info


Recommended Posts

The Jitter Reduction part of MIDI 2.0 is pretty cool. The resolution is 32 microseconds (!), and multiple events can have the same time stamp to make sure things really do happen at exactly the same time.

 

Another cool aspect is that it is possible for MIDI 1.0 devices to take advantage of this. I'm not sure whether manufacturers will go back and update firmware or whatever for MIDI 1.0 devices, although some probably will. However even when MIDI 2.0 comes out, there will still be situations where new MIDI 1.0 devices are manufactured, because they won't need the extra resolution and such. These can incorporate Jitter Reduction time stamps.

 

The bottom line is that timing will be much tighter. Another twist is that timing doesn't deteriorate as data streams get more complex.

Link to comment
Share on other sites



  • Replies 25
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

I was building a MIDI accessory. I noted that the standard optocoupler circuit in the MIDI spec takes the output at the collector with a pullup and wondered what about using a pulldown at the emitter. You have to amplify the weaker output but the transients are a LOT faster. Faster propagation time too.
Link to comment
Share on other sites

I don't think we're going to be seeing a lot of opto-couplers and 5-pin DINs in the future, there's probably more MIDI going over USB these days than over DIN.

 

Interestingly the Universal MIDI Packet, which incorporates MIDI 1.0 and MIDI 2.0, is transport-agnostic. So if there's a new UniversalFireThunderbus protocol 15 years from now, the data won't care about the change.

Link to comment
Share on other sites

This is actually a big deal. Anyone with a big modular rig and a DAW has had to deal with sync issues. There are products specifically to solve these issues. Glad to hear of this - this is a foundational capability that won't make a big splash initially, but over time will become critical.
Link to comment
Share on other sites

This is actually a big deal. Anyone with a big modular rig and a DAW has had to deal with sync issues. There are products specifically to solve these issues. Glad to hear of this - this is a foundational capability that won't make a big splash initially, but over time will become critical.

 

There's a lot about the MIDI 2.0 spec that was designed with the intention of it lasting as long as MIDI 1.0. That's a tall order in today's tech world, but I think there's a pretty good shot at that becoming true. I'm sure there will be additions, as there were to the MIDI 1.0 spec, but the core specs seem pretty forward-looking.

Link to comment
Share on other sites

I don't think we're going to be seeing a lot of opto-couplers and 5-pin DINs in the future, there's probably more MIDI going over USB these days than over DIN.

 

Interestingly the Universal MIDI Packet, which incorporates MIDI 1.0 and MIDI 2.0, is transport-agnostic. So if there's a new UniversalFireThunderbus protocol 15 years from now, the data won't care about the change.

 

We are both EEs. Optocouplers and current loops were the key to preventing ground loops. Ground loops are a problem with USB MIDI. How does MIDI 2.0 propose to resolve ground loops without optocouplers?

Link to comment
Share on other sites

We are both EEs.

 

Well, actually I'm not. Dropped out of college after a year, to tour with a rock and roll band :)

 

Optocouplers and current loops were the key to preventing ground loops. Ground loops are a problem with USB MIDI. How does MIDI 2.0 propose to resolve ground loops without optocouplers?

 

There's nothing that prevents companies from using MIDI 1.0 / DIN / opto-couplers if they think that will serve their needs better. MIDI 2.0 is more MIDI, not less MIDI.

 

I haven't experienced problems with USB and ground loops, so it hasn't really been on my radar. My understanding is that something like a USB controller is just feeding data, not audio, into a system, so ground loops become a factor only after the system has to interface with audio...yes? So far I haven't seen anything in MIDI 2.0 about audio over USB, just data.

Link to comment
Share on other sites

We are both EEs.

 

Well, actually I'm not. Dropped out of college after a year, to tour with a rock and roll band :)

 

I'm an EE, but most of what I know about audio and solving problems with audio equipment wasn't learned in college, but rather from my ham radio experience early on (long before college) and from a few audio engineering experts half way through my vanilla career as a g'u'mmint injineer.

 

I haven't experienced problems with USB and ground loops, so it hasn't really been on my radar. My understanding is that something like a USB controller is just feeding data, not audio, into a system, so ground loops become a factor only after the system has to interface with audio...yes? So far I haven't seen anything in MIDI 2.0 about audio over USB, just data.

 

"Ground loop" isn't the right term for the problem that can occur in audio when there are USB connections involved. It's essentially the "Pin 1 problem" as described by Neal Muncy and thoroughly discussed in the June 1995 issue of the AES Journal (now available as an AES special publication). Computers can have a lot of crap on their ground that gets connected to the ground of the audio device through the shield of a cable. If the ground system of the audio device isn't properly designed to keep the audio and chassis grounds bonded for a very low impedance connection, that ground noise can be introduced on to the audio.

 

Audio manufacturers have been hip to this for a while now, and are doing a better job with internal grounding than they did in the 1980s - 1990s, when the noise floor for your average Shure mixer or Yamaha synth was high enough so that Pin 1 noise was, well, down in the noise. But as noise floor lowered, the influence of external noise became more bothersome.

Link to comment
Share on other sites

The Jitter Reduction part of MIDI 2.0 is pretty cool. The resolution is 32 microseconds (!), and multiple events can have the same time stamp to make sure things really do happen at exactly the same time.

 

Just wondering if/how this applies to a guy using a DAW/computer sending midi out to a synth or two and perhaps a light controller and/or effects unit for live performances. You're still sending midi data through a serial port whether it be USB or 5 pin DIN at the 31.25k baud rate and two events can't happen at exactly the same time.

Link to comment
Share on other sites

The Jitter Reduction part of MIDI 2.0 is pretty cool. The resolution is 32 microseconds (!), and multiple events can have the same time stamp to make sure things really do happen at exactly the same time.

 

Just wondering if/how this applies to a guy using a DAW/computer sending midi out to a synth or two and perhaps a light controller and/or effects unit for live performances. You're still sending midi data through a serial port whether it be USB or 5 pin DIN at the 31.25k baud rate and two events can't happen at exactly the same time.

 

They can if they wait to respond until the right time according to the time stamp. Each device might not receive the data at the same time, but it it's able to sit there and wait until the time (relative to the time stamp) comes around, they can all fire off at the same time. It could slow down the near-real time response a bit but the worst case shouldn't be any worse than that of the slowest-responding device. That's sometime a problem with soft synths, but not because of data transfer, rather it's because of how long the program takes to produce the sound.

 

Another side of the coin is - who cares? If you're programming the same drum hit on four different snares, yeah, you might notice some flamming, but time code synchronization could improve this. And who's going to notice if the lights change 20 milliseconds after the explosion sample plays?

Link to comment
Share on other sites

The Jitter Reduction part of MIDI 2.0 is pretty cool. The resolution is 32 microseconds (!), and multiple events can have the same time stamp to make sure things really do happen at exactly the same time.

 

Just wondering if/how this applies to a guy using a DAW/computer sending midi out to a synth or two and perhaps a light controller and/or effects unit for live performances. You're still sending midi data through a serial port whether it be USB or 5 pin DIN at the 31.25k baud rate and two events can't happen at exactly the same time.

 

The limitations of the 31.25k Baud rate doesn't exist inside the computer, only if feeding something like an external hardware synth using 5-pin DIN. The new Universal MIDI Packet (UMP) data structure in MIDI 2.0 handles data entirely differently compared to MIDI 1.0, although you can embed MIDI 1.0 data in the packet for backwards compatibility. One of the biggest differences in MIDI 2.0 hardware will be UMP compatibility.

 

If 32-bit controllers had to send their data out at 31.25 kBaud, we'd all be in trouble!

Link to comment
Share on other sites

"Ground loop" isn't the right term for the problem that can occur in audio when there are USB connections involved. It's essentially the "Pin 1 problem" as described by Neal Muncy and thoroughly discussed in the June 1995 issue of the AES Journal (now available as an AES special publication). Computers can have a lot of crap on their ground that gets connected to the ground of the audio device through the shield of a cable. If the ground system of the audio device isn't properly designed to keep the audio and chassis grounds bonded for a very low impedance connection, that ground noise can be introduced on to the audio.

 

 

Totally agree. This is also the case with AES/EBU. A few years ago I had a bitch of a time figuring out why moving my mouse caused audible artifacts. Once I lifted all 8 shield grounds on my RME AES-32 DB25 connectors life was good.

Link to comment
Share on other sites

On second thought...how is this not a ground loop? The noise that"s on the computer ground should be going to ground via the computer AC. But instead it"s making its way to the audio device via the shield connections in my AES/EBU case or USB pin 1 and into the audio signal; either via coupling or 'substrate bleeding' onto the signal lines/circuits. I believe that"s still a type of ground loop although the source of the noise is understood.

 

Is the USB pin 1 issue so different that it"s not technically a ground loop?

Link to comment
Share on other sites

 

Is the USB pin 1 issue so different that it"s not technically a ground loop?

 

Oh, I'm just a stickler. It's a special case of a ground loop. I guess that technically it's not a pin 1 problem because pin 1 of a USB connector doesn't carry the ground. But because it's an issue with the metal housing of the connector and the cable shield, I consider it to be in the "Pin 1 Problem" (P1P) category.

Link to comment
Share on other sites

The Jitter Reduction part of MIDI 2.0 is pretty cool. The resolution is 32 microseconds (!), and multiple events can have the same time stamp to make sure things really do happen at exactly the same time.

 

Another cool aspect is that it is possible for MIDI 1.0 devices to take advantage of this. I'm not sure whether manufacturers will go back and update firmware or whatever for MIDI 1.0 devices, although some probably will. However even when MIDI 2.0 comes out, there will still be situations where new MIDI 1.0 devices are manufactured, because they won't need the extra resolution and such. These can incorporate Jitter Reduction time stamps.

 

The bottom line is that timing will be much tighter. Another twist is that timing doesn't deteriorate as data streams get more complex.

 

 

32 microseconds?

 

Isn't that 1,000,000 / 32?

or

1 bit at 31,250 bps?

 

Taken from "M2-104-UM_v1-0_UMP_and_MIDI_2-0_Protocol_Specification,pdf" section 4.8.2 and 4.8.3.

 

Strange number that, now where have I come across it before?

 

Oh! Yes.

One bit at the old MIDI 1 DIN interface transmission rate.

Isn't it odd that the same things keep turning up again and again?

Nothing new under the sun, eh?

 

To be honest, I've been reading and re-reading that part of the protocol specification (section 4.8) and haven't yet been able to relate it to real life.

 

I expect it's me.

 

Say a two handed chord (six notes) played on a MIDI 2 compliant keyboard (sending either MIDI1 or MIDI2 messages, UMP encoded) has the timestamp prepended to each Note On,

but the six messages happen to get split across two USB packets because of USB timing, just how do they get reassembled at the receiving end (also MIDI2 compliant),

assuming it's a computer with VSTi's or some kind of new sound module?

 

Does the first batch of notes get delayed in the input buffer awaiting the second, or what?

Or, is it completely irrelevant in this situation?

 

Sorry, I just can't figure it out.

 

Can't wait for the MIDI 2 SMF specification to arrive.

MIDI 2 files are going to get quite a bit bigger, aren't they?

 

Oh, and will a MIDI 2 file name sufffix be different from a type 1?

e.g. filename.md2

And I suppose the file header information will change too?

 

Enquiring 74 year old minds need to know. ;-)

 

JohnG.

Akai EWI 4000s, Yamaha VL70m, Yamaha AN1x, Casio PX560, Yamaha MU1000XG+PLGs-DX,AN,VL.

 

Link to comment
Share on other sites

 

Is the USB pin 1 issue so different that it"s not technically a ground loop?

 

Oh, I'm just a stickler. It's a special case of a ground loop. I guess that technically it's not a pin 1 problem because pin 1 of a USB connector doesn't carry the ground. But because it's an issue with the metal housing of the connector and the cable shield, I consider it to be in the "Pin 1 Problem" (P1P) category.

 

 

Despite the number of hours/days/weeks I've spent chasing ground loops my brain doesn't easily remember what I've learned. It also doesn't rest until things make sense. I always appreciate a refresh and the potential to learn something new that I may have missed. Thanks Mike and Mike for your insights.

Link to comment
Share on other sites

 

Is the USB pin 1 issue so different that it"s not technically a ground loop?

 

Oh, I'm just a stickler. It's a special case of a ground loop. I guess that technically it's not a pin 1 problem because pin 1 of a USB connector doesn't carry the ground. But because it's an issue with the metal housing of the connector and the cable shield, I consider it to be in the "Pin 1 Problem" (P1P) category.

 

Nope.

 

The metal housing could be connected to chassis ground at any port. Therein lies the crucial difference.

 

"Pin 1 problem" argues the purpose of pin one. In the audio world of XLR balanced connections, it is accepted that pin 1 is SIGNAL GROUND and the metal housing is CHASSIS GROUND. Chassis and signal ground should NEVER be connected. Chassis is the earth connection at power entry; signal ground is far removed from that as it is referenced at a tap of the secondary of the power transformer. Due to this configuration there is a very real possibility of voltage potential difference between the two grounds. Short them together and you create a closed loop where noise current can now flow.

 

Same problem exists in the USB interconnect. Metal housing (potentially) connected to chassis to earth, signal ground (pin 1) connected to a tap on the power transformer secondary. It's not a "special case of ground loop", it's the same configuration with the same vulnerability to ground loop.

 

I studied power transmission, power supply design, and computer systems in college and have been a systems engineer with experience in grounding practices since 1988.

 

The MIDI 1.0 specification solved the ground loop problem with its current loop architecture which does not need a reference, and by mandating that pin 2 (cable shield) be connected to ground at the MIDI output/thru ports but NOT at the input port.

 

I make my own MIDI cables and I/O panels with DIN jacks. I always had intermittent MIDI hiccups over the years. When I built my stage MIDI system the hiccups went into overdrive. I found I had inadvertently created a closed circuit from cable shield to chassis ground. When I assembled my MIDI cables, the cable clamp on the plug connected to cable shield. That clamp is the metal housing of the MIDI plug. At my custom I/O panel, the metal housing on my MIDI DIN jacks connected to chassis through the rack panel through rack rails through rack devices whose chassis were tied to power earth. Insert plug into jack and poof, a closed circuit between grounds. Although no one could hear the ground noise, it had corrupted the MIDI signals. I had to open all my DIY MIDI cables and add shrink sleeving to insulate the shield wire from the cable clamp, and bingo no more MIDI hiccups. NEVER connect MIDI pin 2 shield to chassis.

Link to comment
Share on other sites

32 microseconds?

 

Isn't that 1,000,000 / 32?

or

1 bit at 31,250 bps?

 

We were not specifically targeting a match to the 1 bit at 31,250 bps. It just turned out that way.

We had a certain number of time bits available and practical timing accuracy goals to meet.

It's a convenient time value for devices with a 1 MHz clock.

 

To be honest, I've been reading and re-reading that part of the protocol specification (section 4.8) and haven't yet been able to relate it to real life.

...

Say a two handed chord (six notes) played ... get split ...

 

Does the first batch of notes get delayed in the input buffer awaiting the second, or what?

 

Removing jitter always requires adding latency. When the connection is first made there is a burst of JR Timestamps data so the receiver can make some determination about jitter on the connection, then add an appropriate amount of latency. That might typically be up to a few milliseconds. From there the Sender puts JR Timestamps on every message. The receiver is delaying everything coming in, reassembling it and assigning timing according to the JR Timestamps of each event, before performing the data.

 

Can't wait for the MIDI 2 SMF specification to arrive.

MIDI 2 files are going to get quite a bit bigger, aren't they?

 

Oh, and will a MIDI 2 file name sufffix be different from a type 1?

e.g. filename.md2

And I suppose the file header information will change too?

 

MIDI Association members are working on defining the SMF2 format now. It will have notable differences from the original formats. I predict it will take another year to complete.

 

Mike.

Mike Kent

- Chairman of MIDI 2.0 Working Group

- MIDI Association Executive Board

- Co-Author of USB Device Class Definition for MIDI Devices 1.0 and 2.0

 

Link to comment
Share on other sites

Thanks very much for your rapid response, SynMike.

 

We were not specifically targeting a match to the 1 bit at 31,250 bps. It just turned out that way.

We had a certain number of time bits available and practical timing accuracy goals to meet.

It's a convenient time value for devices with a 1 MHz clock.

 

Sorry, I didn't mean to imply that you were copying the DIN interface transmission rate, just isn't it odd how when we do things like this we turn up with the same number?

A 1 MHz clock subdivided will often give the convenient figure of 31,250.

And, of course, it existed before MIDI, because it happens to be a clock frequency we can feed to the UART.

 

Removing jitter always requires adding latency. When the connection is first made there is a burst of JR Timestamps data so the receiver can make some determination about jitter on the connection, then add an appropriate amount of latency. That might typically be up to a few milliseconds. From there the Sender puts JR Timestamps on every message. The receiver is delaying everything coming in, reassembling it and assigning timing according to the JR Timestamps of each event, before performing the data.

 

Okay, yes a trade off. Thanks for that, I'll have to think about the implications. It certainly makes more sense now. (Thinking cap goes on.)

 

MIDI Association members are working on defining the SMF2 format now. It will have notable differences from the original formats. I predict it will take another year to complete.

 

Mike.

 

Okay, yes, thought it might take a while.

 

Do we have any insights to completed parts yet?

Header, obviously, but still three file types; 0,1 & 2?

Similar chunks perhaps with more in them, but maybe new group chunks?

Any changes to delta timing?

TPQN still the same?

 

Curious minds are seeking early insights.

(Especially this one.)

 

Thanks again,

JohnG.

Akai EWI 4000s, Yamaha VL70m, Yamaha AN1x, Casio PX560, Yamaha MU1000XG+PLGs-DX,AN,VL.

 

Link to comment
Share on other sites

 

The metal housing could be connected to chassis ground at any port. Therein lies the crucial difference.

 

"Pin 1 problem" argues the purpose of pin one. In the audio world of XLR balanced connections, it is accepted that pin 1 is SIGNAL GROUND and the metal housing is CHASSIS GROUND. Chassis and signal ground should NEVER be connected. Chassis is the earth connection at power entry; signal ground is far removed from that as it is referenced at a tap of the secondary of the power transformer. Due to this configuration there is a very real possibility of voltage potential difference between the two grounds. Short them together and you create a closed loop where noise current can now flow.

 

That's correct when you're inside the box, but when you have two boxes connected together that might (and usually do) have different voltages between the cable shield and the brown stuff under the house, that's something that must be dealt with. Good practice is to bond the signal ground (pin 1) to the shield at one single point inside the box, as closely as possible to where the cable enters the box, and with the lowest impedance path as possible.

 

Where we started running into problems was with audio devices built with XLR and 1/4" connectors mounted on the circuit board, with Pin 1 (or the phone plug sleeve) having a haphazard path to the chassis ground, often through a circuit board trace, or a connector with a metal shell secured to a plastic case.

 

As a sometimes tech writer, I try to avoid (and correct) the use of terms that have become part of the vernacular that may not be completely accurate. "Ground loop" has become the common term for any cause of hum that occurs when two boxes are connected by a cable. This is most critical with unbalanced connections where the cable shield carries signal current. When there's a separate conductor between the boxes that carries ground but (hopefully) no signal, then the current caused by different ground potentials between Pin 1 on the two units, hum is induced locally within the box rather than being carried along with the signal on a conductor between the boxes. That's the distinction. But, yes, there is a "loop," but there's a more accurate description.

 

As an off-topic warning, I'm getting rather testy about the use of a couple of other contemporary popular terms/. One is the use of "saturation" to describe distortion resulting from anything, not just from a component that limits the maximum level that its output can reach regardless of input level, with a rise of harmonic distortion between the onset of non-linearity and maximum output level. And then there's "pivot," a term that's been overused by news media lately. I don't want to hear about a musician who has "pivoted" from playing bars to composing background music for the local podcasters.

 

Grumble, grumble, grumble.

Link to comment
Share on other sites

As a sometimes tech writer, I try to avoid (and correct) the use of terms that have become part of the vernacular that may not be completely accurate.

 

The more accurate term is "0v reference". They are relative to their local power systems. "Chassis ground" is the 0v reference relative to utility power source (can vary with countries other than US though). "Signal ground" is the 0v reference relative to a signal. "Analog ground" and "digital ground" are 0v reference relative to the power supply in a local device. Never assume these are all the same potential. Design convention is to couple any non-chassis 0v reference to chassis through a low value resistor with a cap across it so that ground noise flows across the resistor and not through local circuits.

 

"Ground loop" has become the common term for any cause of hum that occurs when two boxes are connected by a cable. This is most critical with unbalanced connections where the cable shield carries signal current. When there's a separate conductor between the boxes that carries ground but (hopefully) no signal, then the current caused by different ground potentials between Pin 1 on the two units, hum is induced locally within the box rather than being carried along with the signal on a conductor between the boxes. That's the distinction. But, yes, there is a "loop," but there's a more accurate description.

 

You're an EE. I would argue that the more accurate description lies in the Thevenin (or Norton) theorem. Any network of closed loops consisting of voltage sources (or current sources for Norton) and passive impedances can be reduced to a single loop with a single voltage source and impedance. When you have two ground points with non-equal potentials, this fits the definition of a voltage source. Connect them together and you create a closed loop. Since they are ground points they are technically a ground loop which follows Thevenin's theory.

Link to comment
Share on other sites

So when making a USB connection causes hum, how do you fix it?

 

USB hub with isolated ports.

 

I didn't know there was such a thing, but sure enough, at least that description brings up several different models. Not cheap, though, and some with pretty poor English descriptions. Have you guys verified that this sort of gadget works to eliminate hum in a practical setup?

 

Single port USB 2 - $30

 

4-port USB 3.1 - $220

Link to comment
Share on other sites

So when making a USB connection causes hum, how do you fix it?

 

USB hub with isolated ports.

 

I didn't know there was such a thing

 

Nor did I. The single power USB2 you referenced looks to be specifically about audio isolation. I got the impression that the 4-port one was more about if something bad happened on a port, it wouldn't happen to the other ports, or the port into which the hub connects. Or something.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...