MBox Latency - the "164 Sample shift" problem....

[Release]

Is this something that's fixable since it only applies to the Mac version?

I'm looking at either the MBox or the 002r and this is a big concern for me. I want to quickly record ideas and not edit something everytime I lay a track down. I downloaded the manuals for both and it was only mentioned in the Mbox documents...is this a probelm on the 002 too?

The PTLE 6.4 updater renders my AMIII card obsolete and since I use my machine for things other than audio, once OSX/Panther goes to the next version, I'll be forced to get one or the other (MBox or 002r). Any suggestions? I'm not doing anything professional, just an expensive hobby.

[tele_player]

It's not a problem on the 002, and it shouldn't be a problem on the Mbox. Digidesign fixed it in 5.3.3 for Windows, but I don't know if the fix has made it into the latest 6.4 on both platforms.

It's easy to test - search here and in the Windows forum and you should find posts describing how to measure it.

I would definitely test it, since in at least one case (5.3.3 on XP), shifting by 164 samples was the wrong thing to do.

[Release]

It looks like it still in there according to the PDF "Mbox_Basics_Guide_6.4" that is on the website.

From Page 14:

Avoiding Latency with Multiple Overdubs (Macintosh Only)
When you record multiple tracks sequentially in Pro Tools, it is possible to inadvertently build up latency problems, beginning with the second pass.
For example, if you recorded drums on your first pass, the drums will have a delay (of 164 samples)
during playback. If you lay down a new track, using the original drums as a timing reference,
you will be trying to match your timing to when you hear the drums.
When your new track is played back, it will be 164 samples late. Each subsequent track can
compound the timing problems.

To compensate for latency:
1 Click on the Grabber tool.
2 Select the second pass of your multitrack recording by clicking on it with the Grabber tool.
3 Choose Edit > Shift.
4 In the Shift dialog, select “Earlier” and enter 164 into the samples field.
5 Click OK.
6 If desired, repeat steps 1–4 for every new recording pass.

This nonsense will not work for me. Is this even something they can fix or do people just live with this?

[davetron5000]

Isn't there a monitoring option for MBOx that is basicaly zero latency? I have not experienced this wiht my 002R, but I haven't measured it, either.

[jlcnyc]

while we are on the subject...does the 164 sample latency apply to all recording? Are tracks that are recorded with soft synths also "late"?... or is latency just an A/D conversion issue?

Mbox PTLE 6.4
OS 10.3.2
G5 dual 1.8

[ricupad]

It's not a monitoring issue - the recorded audio ends up in the track 164 samples later than it was played. I set up the shift value before recording, but it's a drag (no pun intended) to have to move the track after recording before you can judge if it's in time or not. Of course, 164 samples is less than 4ms (w/ 44.1 or 48Khz), so you won't notice the difference on many occasions.
The recording procedure is as follows: arm the track(s) that you are going to record into. Then MUTE the output of those tracks. then search the right balance for recording with the 'Mix' knob and the phones level knob. After recording, shift the recorded audio 164 earlier, unmute the tracks and then you get to listen what you just played... It's not actually as bad as it sounds.
The other thing that's not so cool about the Mbox, is that there's no Master Output level control: only headphone level, so if you need to adjust the level for your speakers,you have to do it within PT or from your mixer or amp.

But then, you get what you pay for.

[tele_player]

Regardless of what the docmentation says, if I had an Mbox, I'd test it. It takes about a minute, and there's no good reason for the bug to still exist. But that doesn't mean that it doesn't exist.