Digi Design 002
- Thread starter DopeMan2K
- Start date
Keep in mind that, as with all Firewire interfaces, there are serious latency issues that may affect the way you work.
Firewire is great in those circumstances where a PCI card isn't possible -- and it's got plenty of throughput so you can run multitrack material that wouldn't be possible with, say, a USB (1.1) interface -- but because the standard [Firewire] buffer size is large and takes a while to fill up, a dedicated PCI card interface will deliver much lower roundtrip latency times.
Hotshot chip designer Joe Bryan of Universal Audio recently wrote, “Most ADCs and DACs have only about 27 to 34 samples of delay in their internal digital (downsampling) filters, plus a few samples in the hardware interfaces. That means the total A/D/A delay is around 64 samples, or 1.33 ms at 48 kHz, not 1.5 ms for each A/D or D/A conversion...”
However, FireWire “transfers data every 125 microseconds, but the hardware actually has significantly larger buffers, and the ‘standard’ AM824 protocol [used in mLAN and other implementations] is moving towards using several hundred samples of buffering to overcome multidevice bridging and merging issues. These delays are unacceptable in professional audio applications, so there is still a need for a low-cost, low-latency, multichannel, digital audio transport.” Bryan says he's working to form an industry group to create a better transport standard.
[Quoted in October Electronic Musician Letters Column
http://emusician.com/ar/emusic_letters_27/index.htm ]
However, you can mitigate the problem somewhat by making use of the "zero-latency" monitoring now built into many of the newer outboard interfaces. This is no miracle, despite some of the ridiculous and sometimes misleading hype you will see, however. It simply means that there is a "headphone mix" type output before the initial A-to-D conversion. Some devices actually add some rudimentary reverb or other effects to this mix to get over many singer's objections to hearing their voices 'dry' in the monitor. [Interestingly, the lowly SoundBlaster has had this zero latency monitoring functionality for years. But you'd think from some company's hype that this was some great new advance. The great new advance is that some of the first generation of USB and Firewire devices didn't have this sensible and predictably desirable feature and early adopters screamed like stuck pigs when they confronted the latency issues of their new devices.]
Firewire is great in those circumstances where a PCI card isn't possible -- and it's got plenty of throughput so you can run multitrack material that wouldn't be possible with, say, a USB (1.1) interface -- but because the standard [Firewire] buffer size is large and takes a while to fill up, a dedicated PCI card interface will deliver much lower roundtrip latency times.
Hotshot chip designer Joe Bryan of Universal Audio recently wrote, “Most ADCs and DACs have only about 27 to 34 samples of delay in their internal digital (downsampling) filters, plus a few samples in the hardware interfaces. That means the total A/D/A delay is around 64 samples, or 1.33 ms at 48 kHz, not 1.5 ms for each A/D or D/A conversion...”
However, FireWire “transfers data every 125 microseconds, but the hardware actually has significantly larger buffers, and the ‘standard’ AM824 protocol [used in mLAN and other implementations] is moving towards using several hundred samples of buffering to overcome multidevice bridging and merging issues. These delays are unacceptable in professional audio applications, so there is still a need for a low-cost, low-latency, multichannel, digital audio transport.” Bryan says he's working to form an industry group to create a better transport standard.
[Quoted in October Electronic Musician Letters Column
http://emusician.com/ar/emusic_letters_27/index.htm ]
However, you can mitigate the problem somewhat by making use of the "zero-latency" monitoring now built into many of the newer outboard interfaces. This is no miracle, despite some of the ridiculous and sometimes misleading hype you will see, however. It simply means that there is a "headphone mix" type output before the initial A-to-D conversion. Some devices actually add some rudimentary reverb or other effects to this mix to get over many singer's objections to hearing their voices 'dry' in the monitor. [Interestingly, the lowly SoundBlaster has had this zero latency monitoring functionality for years. But you'd think from some company's hype that this was some great new advance. The great new advance is that some of the first generation of USB and Firewire devices didn't have this sensible and predictably desirable feature and early adopters screamed like stuck pigs when they confronted the latency issues of their new devices.]
HOWEVER -- as I researched the Mbox I realized that Pro Tools apparently has no functionality to handle latency offsets -- even on tracks monitored with "zero-latency" direct monitoring each subsequent track is laid down with a growing latency [from non-monitoring related hardware issues] from the first -- to avoid this "latency snowball" the user must manually shift each new track by the latency offset amount after it is recorded but before recording the next overdub.
Now... I don't know if this stunningly klugey workaround applies to the 002 as well -- but if it does and it's not addressed I would think that that would be a definite deal-killer.
As a 6 year veteran of HD recording (on PCs) I can't imagine selling the Mbox -- let alone the 002 which costs more than four times as much -- as a "studio-in-a-box" when it requires this awkward and work-flow-thwarting kluge.
If anyone else has some insight into this issue, I'm dying to know more. (As far as I can tell from the Digidesign User Conference Digi themselves are mostly not very forthcoming on latency issues. But the users are not.)
And here's a very pertinent thread that works out most of the issues -- completely without any official help from Digidesign even though it was asked for multiple times -- from the Digidesign User Conference:
http://duc.digidesign.com/cgi-bin/ubbcgi/ultimatebb.cgi?ubb=get_topic;f=24;t=012344
Now... I don't know if this stunningly klugey workaround applies to the 002 as well -- but if it does and it's not addressed I would think that that would be a definite deal-killer.
As a 6 year veteran of HD recording (on PCs) I can't imagine selling the Mbox -- let alone the 002 which costs more than four times as much -- as a "studio-in-a-box" when it requires this awkward and work-flow-thwarting kluge.
If anyone else has some insight into this issue, I'm dying to know more. (As far as I can tell from the Digidesign User Conference Digi themselves are mostly not very forthcoming on latency issues. But the users are not.)
And here's a very pertinent thread that works out most of the issues -- completely without any official help from Digidesign even though it was asked for multiple times -- from the Digidesign User Conference:
http://duc.digidesign.com/cgi-bin/ubbcgi/ultimatebb.cgi?ubb=get_topic;f=24;t=012344
Last edited:
Well... it's not as bad as I first thought... or maybe as it first was... I'm still a bit confused but it looks like (from some posts in the DUC that requested a fix from Digi specifically for the issue) that when it first came out you could not mute the through-the-box monitoring of currently recording channels from PT -- which really would make it almost impossible to overdub.
It certainly strikes me as weird that Pro Tools (which DIgi would clearly like us to think of as the plus ne plus ultra of recording software) has no provision for setting a latency offset for sample conversion (even though time-stamping apparently sidesteps USB latency issues).
As I pointed out somewhere I used a Sound Blaster Live (which at 44.1 has a whopping latency of something like 160-170 ms [even though it's right there on a PCI card... because of its on-the-fly sample conversion from its internal clock rate of 48kHz -- but that's a whole 'nother story) for a handful of projects and had no problems whatsoever because all the PC software I used allowed you to set a latency buffer (basically an offset) -- or more commonly, analyzed the latency of a given card and set a default value for you.
So you didn't have to go in and shift ("nudge") each new track around to compensate for the latency like you do in Pro Tools. That's how us plebes on PC based DAWs do it -- or have it done for us, more to the point.
It certainly strikes me as weird that Pro Tools (which DIgi would clearly like us to think of as the plus ne plus ultra of recording software) has no provision for setting a latency offset for sample conversion (even though time-stamping apparently sidesteps USB latency issues).
As I pointed out somewhere I used a Sound Blaster Live (which at 44.1 has a whopping latency of something like 160-170 ms [even though it's right there on a PCI card... because of its on-the-fly sample conversion from its internal clock rate of 48kHz -- but that's a whole 'nother story) for a handful of projects and had no problems whatsoever because all the PC software I used allowed you to set a latency buffer (basically an offset) -- or more commonly, analyzed the latency of a given card and set a default value for you.
So you didn't have to go in and shift ("nudge") each new track around to compensate for the latency like you do in Pro Tools. That's how us plebes on PC based DAWs do it -- or have it done for us, more to the point.