• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Buffalo II

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
The only practical reason I can think of is because we are using the jitter eliminator (ASRC) feature and they are not.

McIntosh does the same thing. Only they use a PLL.

I on the other hand much prefer to let the ASRC work.

I think I read that the Weiss DAC202 uses some kind of external PLL for clocking. I guess everyone has their own way of doing it. I just thought using any ASRC always introduces jitter. Though ESS may be better than most.
 
The ASRC still acts like a filter though. Never completely eliminating jitter.
It does eliminate jitter in that timeframe. But the buffer is limited in size, so that limits the amount of jitter that can be removed. 50ns isn't that little though: it's 50000ps, while around 100ps is usually the jitter from a CD players clock. In other words: you'd have to find a pretty poor implementation to really be overrun by jitter.
 
I don't think it matters whether you use one clock or two in an ASRC. There is a belief that using even multiples of the original clock is beneficial. But in an ASRC the input clock and output clock are unrelated and the ASRC algorithm just calculates the new samples closest to the new clock rate.

Where it matters is in deriving the master clock frequencies, and this is typically during clock recovery. You get less jitter with a simple division than through a series of multiplication/division to get at the clock frequency
 
Where it matters is in deriving the master clock frequencies, and this is typically during clock recovery. You get less jitter with a simple division than through a series of multiplication/division to get at the clock frequency

For our Buf II the master clock is dictated, not derived (which I know you know) so really design needs to center around the master clock. :) But say in the case of SRC4192 it can be very critical to use master frequencies. And in a situation where you are using a chip like that two clocks would be ideal. But we are talking about two totally different apps.

In any case we designed it the way we have for a good reasons, and I am quite happy with the choice. Adding another clock in our configuration would only serve to increase the cost with no gain whatsoever. Nobody wins.

Cheers!
Russ
 
Last edited:
...But say in the case of SRC4192 it can be very critical to use master frequencies. And in a situation where you are using a chip like that two clocks would be ideal. But we are talking about two totally different apps.

...
Cheers!
Russ

Hi Russ,

Yes it would be ideal to use two clocks in the src4192 if you wish to support all the 44.1 and 48K families. But if you just want to upsample to a higher sample frequency then it seems from the theory that upsampling 44.1K to 176.4 (even multiple) would not get you closer or more accurate samples than upsampling to 192K (not an even multiple).
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.