H/W Buffer Size Induced MIDI/MTC Latency bug?

[Burbree]

002 Rack
PT 9.03
Mac OSX 10.6.5/10.6.8
4gb RAM
Sync Setting Internal
30 FPS
4 Processors
95% CPU

The Protools Reference guide says on page 691

" If you are monitoring the output of external MIDI instruments with an external mixer or sound system (or headphones), there is no latency. If, however, you are monitoring the output of your MIDI devices through a Pro Tools interface (such as 003 family devices), your MIDI tracks sound slightly later than your audio tracks. The larger the setting for the H/W Buffer Size (128, 256, 512, or 1024 samples), the larger the latency."


Well I don't monitor through my 002R but I have found there definitely is H/W Buffer induced MIDI playback latency in Protools 9.03 even with RTAS instruments. Up till now I've been using the MIDI track offsets and setting external midi instruments MIDI offset to the buffer size setting with some success. However..

I've noticed there is also a direct correlation between the H/W Buffer size setting and a delay on the MTC output.

I measured this making a new session at 44.1 24Bit @ 120 BPM and by routing a click track to an audio track manually through Bus 1-2 and routing my MPC 2000XL (set to sync to incoming MTC generated by protools from the 002's midi output at 30FPS and set to 120 BPM) to inputs 7/8 on my 002 Rack. By recording the two tracks I can measure the difference between the two clicks and thereby measure the MTC delay as well as protools internal MIDI delay. Obviously the MPC's timing engine varies and is different to Protools, so I took three random readings across a recording of 24 Bars. Note these results:

(In making the measurement I factored in Protools internal MIDI delay, Delay Compensation is turned off)

These readings will probably prove useful for anyone using MIDI in protools so that they can set their offsets accordingly.


@32 H/W Buffer size

Protools H/W Buffer size induced internal MIDI delay: 31 Samples

MTC Delay in addition to internal MIDI delay: Between 58-105 Samples


@64 H/W Buffer size

Protools H/W Buffer size induced internal MIDI delay: 31 Samples

MTC Delay in addition to internal MIDI delay: Between 72-101 Samples


@128 H/W Buffer size

Protools H/W Buffer size induced internal MIDI delay: 63 Samples

MTC Delay in addition to internal MIDI delay: Between 148-201 Samples


@256 H/W Buffer size

Protools H/W Buffer size induced internal MIDI delay: 127 Samples

MTC Delay in addition to internal MIDI delay: Between 200-435 Samples


@512 H/W Buffer Size

Protools H/W Buffer size induced internal MIDI delay: 255 Samples

MTC Delay in addition to internal MIDI delay: Between 600-717 Samples


@1024 H/W Buffer Size

Protools H/W Buffer size induced internal MIDI delay: 511 Samples

MTC Delay in addition to internal MIDI delay: Between 1146-1533 Samples


Heres a picture to demonstrate: link

Interestingly the delay for external MIDI instruments is increased yet further when Delay Compensation is turned on.

There are no other delays on my setup my mixer and patchbay is all analogue. Just to be sure I also recorded the protools click back into protools through my mixer at all the above settings and on inspection it was sample accurate.

I tried another experiment where I made a .wav file of the protools click sound, put that on my MPC and triggered it from a beat locked MIDI track in protools which produced similar delay reading results with less variation supposedly because protools timing engine is more accurate.

Even if we account for a 5ms (or 221 sample @44.1) MIDI device latency the above figures clearly show that the playback latency grows proportionally to the H/W Buffer size.

MIDI playback latency is bad enough but surely the MTC sync output should not be delayed in this way. I don't how much this affects film and television folks but a 1400 sample (nearly a whole frame) delay latency is clearly audible when slaving an external drum machine.

Conclusion:

The H/W Buffer size induced internal MIDI delays appear to be fixed between Avid and Core Audio devices. Can this delay be factored into a future release?

OR at the very least can Avid include a MTC output offset so that this can also be adjusted manually??

[daeron80]

Good work. I think it's always been that way. I know it was in 7.x. It would be nice if they would make it work as stated in the Ref Guide.

BTW, it's expected that delays should change when Delay Compensation is turned on, since what it does is delay everything to match the greatest processing latency, or something along those lines. If it didn't delay the audio from Analog ins, things would get out of sync.

[Burbree]

I agree that external MIDI has suffered for a while but I'm convinced the MTC latency is a new thing or at least has got worse..maybe music has just become more mechanical so its more noticeable!

With regard to ADC, surely regardless of whether compensation is going on internally or not when the timeline hits say 00:00:10:00, thats a real-world time location reference, the MTC received by the slave device at that exact moment should be that exact timecode as well, it shouldn't be received a 1000 odd samples later..

[daeron80]

Originally Posted by Burbree

With regard to ADC, surely regardless of whether compensation is going on internally or not when the timeline hits say 00:00:10:00, thats a real-world time location reference, the MTC received by the slave device at that exact moment should be that exact timecode as well, it shouldn't be received a 1000 odd samples later..

It is. But the audio sent from the slave device, upon entering PT, gets delayed. ADC makes everything late in order to keep everything in sync. It looks at each audio stream entering a bus, determines which is being delayed the most due to processing (plug-ins, other busses) and delays all other streams entering that bus by enough to match, up to the limit set in the engine dialog.

[Burbree]

Yes bro that's how ADC works but thats not how I have things set up..
Maybe this will explain it clearer:

Protools > Timeline = 00:00:10:01 > analogue outputs plugged into SSL > Plays a click

MPC 2000XL Slaved to MTC > Timecode received 00:00:10:00 > analogue outputs plugged into SSL > oops not yet

Resultant sound from mix buss on SSL > We are Flam-ily

So to reiterate regardless of what compensation is going on internally in protools (And I hasten to add that in the examples in my big post above ADC was turned off and the session contained nothing more than a click track and two audio tracks with no plugins) real world hardware external devices should be receiving their information whether it be a note-on message or MTC on the beat, in sync, in time, however you want to put it

MIDI and MTC are being sent later and later from protools the higher you raise the H/W buffer size. My experiments show that these delays are not due to MIDIs inherent latency, or MIDI hardware jitter but rather a bug.

If memory serves MTC is sent as quarter frames and should be frame accurate, you only get jitter problems generally if you're trying to send other MIDI data out of the same output as well as MTC.

it would be great if anyone with a Sync IO could chime in and replicate the above to see if it does the same with that..

[daeron80]

Ah, external mixing of the sources. Sync is going to be a nightmare in that situation no matter what. But it seems like delaying MIDI and MTC is the right thing for the program to do, as long as it delays it by the same amount as the audio. What I've always done with external MIDI modules is run everything into PT, get it in sync there, and print.

[Burbree]

Originally Posted by daeron80

it seems like delaying MIDI and MTC is the right thing for the program to do, as long as it delays it by the same amount as the audio.

As my tests show it doesn't..

Even the internal MIDI delay is unacceptable..

What I've always done with external MIDI modules is run everything into PT, get it in sync there, and print.

Thats what I do now.. everything gets printed to audio. Then moved about. I just don't understand why things are getting worse, why should I need to do this when back in '97 I was slaving MPCs to Protools 4 for weeks at a time, with no problems

[daeron80]

Originally Posted by Burbree

back in '97 I was slaving MPCs to Protools 4 for weeks at a time, with no problems

1997 - that would be either a Core III or 24-MIX system. Probably an Opcode MIDI interface. With native systems, it's a whole different ballgame. Without dedicated processors, the program has to slip stuff around the best it can.

[Burbree]

Haha, nearly.. d24 PCI, two farms and a Mark of the Unicorn Midi Time Piece..

Digidesign always prided itself on having a realtime DAW, i.e events would only play if everything can be played back simultaneously, no slipping.

It's interesting and even sad that given the leaps and bounds advances made in technology in the past 10 years in some respects we're regressing

[daeron80]

It's still solid on TDM. The slippage is a necessary consequence of going native.