Asynchronous Sample Rate Conversion

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
guys ... I have to agree with AMT, but for a different reason. This recent discussion should be moved to another thread ... because it's important that the info doesn't get LOST at the end of this long thread !! :D

I think it's a VERY important discussion ... which clocks are most important (jitter sensitive) on the various popular DACs. And although it is certainly relevant to ASRC, it's importance goes BEYOND this topic, and deserves it's own thread :) Agreed?

AMT - care to start a new thread, in case we can't get this section moved? ;)
 
werewolf, this information is absolutely first rate. You've made a tremendous contribution to this forum.

I've had this bookmarked for a while, but I have a few new questions:

I have a new design that uses the TI SRC4192, which is pin-compatible with AD1896. Both have a bypass mode, where the output is copied directly from the input. I use this mode when the transport is known to be slaved off the DAC's master clock. However, because of the overall architecture, the output port clock is double the input port. So if a CD player is running from my DAC's 22.5792MHz clock, we have something like this:

Code:
CDP -> S/PDIF -> CS8415A -> 44.1kHz i2s -> SRC4192 -> 88.2kHz i2s -> DF1704 -> 705.6kHz RJ -> PCM1704
........................................^ bypassed ^

I believe that in this mode the ASRC will simply copy the incoming sample to the output port twice. Is that your thought? If so, what effect does that have on the signal? Is it neutral or detrimental to the information in the signal?

Regards,
jwb
 
No,in Bypass mode, the assumption is that the SRC4192 input and output port sampling rates are exactly the same. Therefore, LRCKI must be the same rate as LRCKO, and BCKI must be the same rate as BCKO. This can only happen if LRCKI is connected to LRCKO, and BCKI is connected to BCKO. This connection is not performed internally in the SRC4192 - you must perform the connection external to the SRC4192. The SDIN data is internally routed to the SDOUT pin, which is the definition of Bypass mode for the SRC4192

Regards,
Marek
 
part 3?

Where’s the jitter reduction? - promised in first post

Werewolf gives us a fine tutorial on asynchronous sample rate conversion via polyphase filtering extending over dozens of posts with perhaps one or two sentences hinting at the actual means of jitter reduction

I would like to see a similarly detailed explanation of “the real jitter reduction” – the following is my best guess based on an understanding of digital filtering and the few hints in Werewolf’s tutorial and the AD1896 data sheet

Presumably the core concept is the differential measurement of the phase/frequency difference between input and output clocks that is insensitive to the local clock running the chip, followed by the asrc translation of the incoming data to the (filtered estimate) of the output clock phase/frequency – the actual asrc process is an enabling technique, making this approach possible but asrc is not the source of the jitter reduction

The jitter reduction comes from the filtering of the “phase” (frequency ratio) estimate between the input and output clock

This is done in the digital domain so it is possible to have performance that exceeds some analog phase /frequency measurement/filtering implementations but much more information is necessary to establish the advantages/tradeoffs

This scheme clearly has some advantages (performance with wide range of input/output clock frequencies) and a few less obvious consequences; the output clock must be very low jitter since if the asrc is working with the filtered phase estimate, instantaneous output clock jitter isn’t compensated

Further, those indulging in pride of ownership over the accuracy of their output clock should realize that the net effect of this phase/frequency filtering/asrc translation process is very similar to a pll in that the incoming transport clock frequency is still controlling the effective reproduction sample rate
 
hey guys ... sorry to be gone for so long.

jcx, allow me to address a few of your points :

To summarize the jitter reduction we discussed on page 8, the ASRC filters incoming jitter through the long-time-constant averaging in the polyphase selection process. Remember that it's not the polyphase length, but rather number of polyphase filters that ultimately determines time base resolution (the polyphase length typically impacts transition band slope). As stated, the number of polyphase filters is huge ... selecting the correct one when an output sample is requested requires long-term averaging for precision. And this long averaging provides jitter filtering.

In the ASRC, this filtering is done purely digitally of course. Yes, the residual jitter is ultimately "mapped" to the output data ... must be, because it's not mapped to the output clock ... but the jitter filter bandwidth can be VERY low (typically only a few Hertz), resulting in a very significantly attenuated jitter, before it is mapped to the output data.

Compare to a PLL - analog filtering, tough to get a jitter filter bandwidth as low as a few Hertz without encountering other problems (VCO noise, jitter accomodation). Yes, the jitter "remains" on the output clock instead of data ... BUT, if the jitter is small enough, data & clock jitter are indistinguishable (remember, the right sample at the wrong time is the wrong sample).

BOTTOM LINE : the ASRC can reduce jitter further, simply because the bandwidth of the jitter filter is lower. And, the process is done purely digitally, meaning less chance for other noise sources to corrupt the process.

Output clock must be low jitter? You bet it does. It calls for a very clean, LOCAL crystal oscillator driving the output clock rate ... and presumably the nearby DAC as well.
 
Well, this thread was certainly more theoretical/foundational in nature ... and no doubt some of the experts here on diy have more hands-on experience :) I have had limited experience with the CS8420, it's notoriously difficult to use. The new CS8421 looks better in this regard. The specs on the Analog Devices device look very good indeed. Don't know much about the TI device, other than what I've seen in the data sheet.

In addition to ease-of-use, I'd say the important specs to consider are :

1. Large Signal to (Noise+Distortion) : S/(N+D) specs, at the intended sample frequencies of interest. Look for tests performed at higher frequency fundamentals. Large signal performance is significant, because residual high frequency images (that will ultimately alias back into baseband) scale in amplitude with the fundamental.

2. Whatever specs you can find about jitter filtering ... corner frequency at different sample rates, and roll-off rate. Lower is, in general, better, but does imply longer lock or aquisition time, and slower tracking in applications with more rapidly varying input rates.

3. Standard digital filter specs like passband ripple and transition bandwidth are of course important, but stopband attenuation can be misleading. This is because in ASRC applications, it's really the total integrated stopband energy that's important, more than maximum stopband level.

Hope that helps ...
 
mikewu99 said:
In the PCM1704 the BCLK line is the only clock that matter wrt jitter. WCLK is simply used to enable the parallel latching of data.

To get technical about it only one BCLK edge per sample is critical for jitter - the aforementioned second leading edge after WCLK goes high. All other clock edges are just used for reading in data.

You can actually tell from the timing diagram in figure 2 of the PCM1704 datasheet that BCLK is the true clock of the chip. Note that the timing for WCLK and DATA are all setup/hold times relative to BCLK. This implies that only BCLK drives edge-sensitive devices.


Hi

Jiitery signals entering the DAC chips WILL polute the conversion clock therefor it helps to lower the jiter on data and wclk too.

cheers
 
Guido Tent said:
Hi

Jiitery signals entering the DAC chips WILL polute the conversion clock therefor it helps to lower the jiter on data and wclk too.

cheers
through what mechanism?

WCLK and DATA are sampled (or "reclocked", you could say) by SCLK. Unless the jitter on WCLK and DATA is so bad that an incorrect high or low is sampled (because, say, a WCLK or DATA *edge* is sampled) then any jitter on those lines will be completely rejected.
 
Unfortunately the inputs (*all* the inputs, not just the clocks) modulate the power supply inside the chip, and capacitively couple with the rest of the circuitry. So jitter on any input probably has some non-zero effect. I'm not sure if those effects will be audible, however.
 
jwb said:
Unfortunately the inputs (*all* the inputs, not just the clocks) modulate the power supply inside the chip, and capacitively couple with the rest of the circuitry. So jitter on any input probably has some non-zero effect. I'm not sure if those effects will be audible, however.
I've been thinking about this, and i'm personally wondering if having jitter on the other lines would be beneficial.

If all inputs of a CMOS chip change at the same instant, it would typically cause a large single current draw pulse. If they change at a slightly separated interval (say, due to jitter) then the single pulse will be spread into multiple smaller pulses, and thus the rail should "nose dive" less.

Which might be a good thing. Or it might be a bad thing, because the transient on the rail is spread out more in time. Who knows?
 
gmarsh said:

through what mechanism?

WCLK and DATA are sampled (or "reclocked", you could say) by SCLK. Unless the jitter on WCLK and DATA is so bad that an incorrect high or low is sampled (because, say, a WCLK or DATA *edge* is sampled) then any jitter on those lines will be completely rejected.


on chip crosstalk

On a PCM63 it was that bad, that reclaocking wclk and data helped. On smaller packages it is different, no experience (yet)

best
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.