ASRC is "de-jitterizer" for DAC ICs. It makes DACs work synchronous to some good clock nearby.
What ASRCs don't do is eliminate input jitter.
ASRCs are a kind of digital system which literally represent DAC and ADC combo, where DAC and ADC have different clock domains.
Let's say the internal DAC gets jitter from I2S input. It's waveform gets shaped with that jitter.
Then internal "ADC" samples the waveform at precise time periods driven by precise clock, and sends it to I2S output.
Therefore, we've got 24bit jitter analyzer for i2s.
To see what's going on, we'd use popular J-Test signal as we use in regular DAC-ADC jig.
Which ASRC would suit the rig? It should be old to not use kind of PLL/averaging on inputs, but have good/precise math engine to have good sampling precision.
What ASRCs don't do is eliminate input jitter.
ASRCs are a kind of digital system which literally represent DAC and ADC combo, where DAC and ADC have different clock domains.
Let's say the internal DAC gets jitter from I2S input. It's waveform gets shaped with that jitter.
Then internal "ADC" samples the waveform at precise time periods driven by precise clock, and sends it to I2S output.
Therefore, we've got 24bit jitter analyzer for i2s.
To see what's going on, we'd use popular J-Test signal as we use in regular DAC-ADC jig.
Which ASRC would suit the rig? It should be old to not use kind of PLL/averaging on inputs, but have good/precise math engine to have good sampling precision.
...ASRCs are a kind of digital system which literally represent DAC and ADC combo, where DAC and ADC have different clock domains.
Let's say the internal DAC gets jitter from I2S input. It's waveform gets shaped with that jitter.
Then internal "ADC" samples the waveform at precise time periods driven by precise clock, and sends it to I2S output.
I find this description insufficiently clear as referenced to the functionality of ASRC's.
To see what's going on, we'd use popular J-Test signal as we use in regular DAC-ADC jig.
The 'popular' J-Test is not a completely revealing Test Procedure.
Interesting Thread, good.
PS:
I had the pleasure of browsing through your hmepage.
I believe you have done a very good job on the TDA1541A Dac.
Cheers
Last edited:
"Which ASRC would suit the rig? It should be old to not use kind of PLL/averaging on inputs, but have good/precise math engine to have good sampling precision."
Even the first gen ASRC from Analog Devices did a very good job of finding the optimum for sample rate conversions. I don't think this approach will get you far. Actually I'm finding the inexpensive SPDIF receivers can achieve essentially perfect, jitter free reconstruction of the waveform. Jitter issues today are more ones of lousy sources or broadband phase noise reducing the SNR of a DAC. I don't see a lot of benefit from using USB as a source, certainly not enough to overcome the barriers and challenges of USB for that reason.
If you want to see Jitter on I2S clocks you need to create a clock recovery system to make a "perfect' clock to reference the clock under test. This is sort of a guide to the issues: Clock Recovery?s Impact on Test and Measurement | Tektronix . You could also phase lock a low noise crystal oscillator to your clock and then use a number of techniques to measure the phase noise. In the end looking at the analog signal coming out of a DAC is the best way to test. All of the upstream problems and fixes are there.
Even the first gen ASRC from Analog Devices did a very good job of finding the optimum for sample rate conversions. I don't think this approach will get you far. Actually I'm finding the inexpensive SPDIF receivers can achieve essentially perfect, jitter free reconstruction of the waveform. Jitter issues today are more ones of lousy sources or broadband phase noise reducing the SNR of a DAC. I don't see a lot of benefit from using USB as a source, certainly not enough to overcome the barriers and challenges of USB for that reason.
If you want to see Jitter on I2S clocks you need to create a clock recovery system to make a "perfect' clock to reference the clock under test. This is sort of a guide to the issues: Clock Recovery?s Impact on Test and Measurement | Tektronix . You could also phase lock a low noise crystal oscillator to your clock and then use a number of techniques to measure the phase noise. In the end looking at the analog signal coming out of a DAC is the best way to test. All of the upstream problems and fixes are there.
As Demian implied every ASRC has some sort of PLL that estimates the input-output clock rate; it's just a matter of loop filter bandwidth. According to Jitter Reduction Using PLL and ASRC Devices, the SRC4192 has a (way to) high PLL bandwith so might be at least partially suitable for what you intend to do. Just keep in mind that you'll see both jitter of the input and output clock, along with jitter introduced by the internal PLL circuit. A dedicated analog setup will surely provide much higher resolution (and is, in fact, no that difficult to design).
Not sure if that lines up with my experience... Which receiver do you refer to?
Most AES receivers have a PLL bandwidth of several 100 Hz, so will pass the low-frequency jitter spectrum of the source right to the converter. Note that this will not show up with the standard AES jitter measurement procedures.
Samuel
Actually I'm finding the inexpensive SPDIF receivers can achieve essentially perfect, jitter free reconstruction of the waveform. Jitter issues today are more ones of lousy sources or broadband phase noise reducing the SNR of a DAC.
Not sure if that lines up with my experience... Which receiver do you refer to?
Most AES receivers have a PLL bandwidth of several 100 Hz, so will pass the low-frequency jitter spectrum of the source right to the converter. Note that this will not show up with the standard AES jitter measurement procedures.
Samuel
- Status
- Not open for further replies.