usb / firewire

The Central Station locks to it's digital input. But since both the MOTU interfaces were locked to the UA 2192, the clock should be passed on from the MOTU's to the Presonus.
 
The Central Station locks to it's digital input. But since both the MOTU interfaces were locked to the UA 2192, the clock should be passed on from the MOTU's to the Presonus.

That's what I thought you were going to say. If the UA2192's output is not hooked directly to the Central Station, you aren't truly removing the MOTU clock from the picture by any stretch of the imagination. Devices don't ever pass a clock through in the analog domain. They regenerate the clock using a PLL circuit. Thus, the clock the Presonus is getting is basically coming from the MOTU interface's clock circuits, NOT the UA2192 (though not from the MOTU's crystal). In such a configuration, you could be getting jitter either from the PLL circuit in the MOTU or from the PLL circuit in the Presonus getting fooled by slightly low or unclean digital output from the MOTU.

Ultimately, this is the fault of the Presonus hardware, as a proper PLL circuit should smooth out any variation in the clock stability. However, obviously there's some flaw in the MOTU that is tickling the flaw in the Presonus hardware. The real question, then, is whether the flaw is in the input circuit of the MOTU (in which case it would color all recordings using the MOTU's converter when driven by an external clock) or in the output circuit of the MOTU (in which case it would only color recordings done with that external converter).

To figure out whether the input or output is at fault, do one more test. Hook the UA2192 to the FireWire interface, hook its output to the PCIe interface's input and sync the PCIe interface to that input. Hook the PCIe interface's output to the Presonus.

If in that configuration, everything is clean, then the FireWire interface's digital sync output is pissing off the Presonus (but not the MOTU PCIe hardware) and you can safely use the FireWire hardware as long as you don't try to slave the Presonus off of it.

If in that configuration, things still sound bad, then it might be that the MOTU PCIe hardware can't lock to output of the MOTU FireWire hardware cleanly, or it could mean that the MOTU FireWire interface isn't regenerating a clean clock when taking input from the UA2192. To figure out which... yup, you guessed it. One more test.

Using the internal converters of the MOTU, do a test recording using an external clock, then repeat that recording using the internal clock. If the internal clock sounds better, it is a PLL bug in the MOTU FireWire hardware. If both sound good, it's a bug in the digital output of the MOTU FireWire hardware. If both sound bad, it is a very severe PLL bug in the MOTU FireWire hardware and worth a complaint.
 
Interesting. I'll try those other comparisons you mention. It will have to wait a few weeks though because my Traveler is in my live rack at a theater right now.

I should point out that the Traveler does not sound bad, just not quite as good as the PCIe based interface in a head to head comparison.

Thanks for that long detailed post, I appreciate the time you took to write that.
 
EM has an artical about digital clocking this month that touches on this.

FireWire and USB break the stream of samples into packets of data and transmit them sequentially. The packets are received by buffers in the receiving device, reassebled into the original sample stream and then sent from the buffer at the appropriate time as determined by the device's sample clock - a process called reclocking, FireWire and USB are not dependant on embedded clocks for timing.

It goes on to say FireWire and USB send packets that are synchronization messages, but the architecture of the interfaces can introduce small variations in the transmission of these packets. When a phase-locked loop at the receiving end tries to extract the clock from the slightly irregular timing messages, jitter is created.
 
Back
Top