Skip to main content

I built a PC-based DAW out of a MOTU PCI 424 card and pair of MOTU 24IO interfaces to be used as a way to generate a large number of simulated Sonar signals. SONAR (no pun intended) is the DAW application. While I was checking the system out, I noticed a delay between the two interfaces, meaning that this MOTU system is not sample accurate! I have direct measurements of this using an Agilent digital scope. What's worse, the timing offset between the two units changes between system restarts - boot the PC one time and you measure one value of time offset between the units. Boot it again and you get something different.

I have called into Tech Support and am waiting MOTU's response. IMO, there is an initialization issue with the PCI 424 card and Windows. I don't believe that SONAR is implicated in this problem.

If you are sticking to a single MOTU interface, no problems. If you are working multiple MOTU 24IO interfaces I wouldn't go there right now - they don't synchronize.

Topic Tags

Comments

dpd Wed, 09/19/2007 - 20:39

I'm still measuring with my new test signal (about 10 cycles of a 12 khz sine wave sampled at 96 khz). So far, 4.4 uSec is the predominant value, but we have measured up to nearly 26 uSec. I am having one of my techs conduct about 10-12 measurements from a complete cold reboot of both 24IO interfaces and the PC in the exact same sequence.

Next up is to vary the sequence to see what impact, if any, this has.

MOTU knows about this and has my number. I've been waiting all week for them to call to discuss.

It appears that MOTU is missing a 'synchronize NOW' function that sends a signal from the PCI-424 to the interfaces.

dpd Thu, 01/10/2008 - 19:36

UPDATE:

After nearly 6 months of back and forth with MOTU, they have confirmed my diagnosis: Multiple 24IOs connected via their PCI-424 card DO NOT MAINTAIN SAMPLE-ACCURATE SYNCHRONIZATION. Furthermore, the timing offset between these units VARIES each time the interfaces are rebooted. The offset is, however, fixed (constant) when the units boot.

My measurements - using calibrated, high-end engineering laboratory equipment - have shown timing offsets (at 96 K) to be as high as 10+ uSec (note: that's over 1 full sample!).

I do not know if this problem exists with their other interface products.

Boswell Fri, 01/11/2008 - 05:40

I'm glad you got a response and a sort of admission from MOTU. This type of time synchronization problem is more common than you would believe. In my day job is as an electronic design consultant, I quite often get called in to investigate effects of this sort, but only from equipment manufacturers who are enlightened enough to realise they have a problem.

The usual cause of this effect is lack of care or forethought in the design of the phase-lock loops and frequency dividers. To generate a higher-frequency bit clock (e.g for ADAT or FireWire/Audiowire) from a sample clock typically needs a x256 phase-locked frequency multiplier, and then dividers down from that. It's usually the lack of reset to a known value in the frequency dividers on startup that causes random phasing of the output sample clock.

dpd Fri, 01/11/2008 - 22:01

Hmm - interesting point. I've had to design multi-channel data acquisition systems that are located over long runs of cable, to the point where the propagation velocity of the cable needs to be accounted for in the design. That system used a PLL in each DAQ subsystem and I had to design a robust reset sync pulse / counter to go along with the PLL to ensure all 12 of them perfectly synchronized.

My personal belief is that MOTU failed to ensure the PCI-424 card has a way to reset all connected interfaces to the exact same clock edge in order to maintain interface-interface time synchronization. It wouldn't surprise me if the clocking PLL was involved, since the time synchronization changes each time an interface is rebooted.

I have no idea what MOTU is going to do about this.

Boswell Mon, 01/14/2008 - 04:45

dpd wrote: My personal belief is that MOTU failed to ensure the PCI-424 card has a way to reset all connected interfaces to the exact same clock edge in order to maintain interface-interface time synchronization. It wouldn't surprise me if the clocking PLL was involved, since the time synchronization changes each time an interface is rebooted.

Something along those lines. I've worked on enough of these now to have a good idea of what's causing it and to suggest ways of fixing it, but that's my professional life and I'm here on these forums as an experienced amateur.

x

User login