Asynchronous Sample Rate conversion (ASRC) DACs

[amirm]

ISTM we rather do need a specific jitter test signal designed for HDMI - J test was specific to AES3's use of bi-phase mark coding and designed to provoke that into doing its worst. Presumably HDMI has different foibles as the physical layer's different?

That's right. I think it is actually worse than that. I suspect if one changed things like video resolution those jitter charts would all change!

 

[WLVCA]

I ordered the Emotiva XDA-2 Dac and should have it next week.

Curious to see what it sounds like.

 

[opus111]

I looked for internal pics of that but the only one I could find was a tad small - looks like they're using two power supplies. One switcher and one toroid. What did they change in technical details since the XDA-1 DAC? That one was using AD1955.

 

[WLVCA]

The chip is the same - AD1955.

They are also using the the AD1896 ASRC to attenuate jitter - same as the Benchmark DAC 1.

ASRC can be disabled.

The XDA-1 only had 16/44 via the USB input, XDA-2 is 24/192.

Apparently they've made changes to the analog output stages, too.

They also fixed the problem they had with the volume control on the XDA-1, it lost bits when you turned it down.

I owned an XDA-1 but sold it about 6 months ago.

 

[opus111]

I remember rather a lot of 'noise' on the forums about the volume control when the XDA-1 first was released - like it was 'linear' rather than log so the useful working range was rather limited. Then later didn't they fix that with a firmware update? So now do they have an analog volume control?

 

[WLVCA]

Yes, the XDA-2 volume control is analog, a lossless resistor ladder.

The did make a change to the volume control on the XDA-1, don't recall the details, but they never made it lossless.

 

[opus111]

Curious - how have they done that? Hopefully not one of those integrated chips with an on-board opamp like CS3310 ?

 

[WLVCA]

I can't answer that one - not certain of the details.

 

[opus111]

OK thanks - I'll keep my eyes peeled and see if I can find out and will post it up here when I do.

Their website says 100dB range in 0.25dB steps so its not one of the usual suspects (CS3310 or PGA23xx). Could be one of the newer parts from Cirrus though...

 

[jkeny]

Yes exactly. Instead of just toggling the low-order bit as J-test tries to do, we need to induce rate changes and see how they track the input and what artifacts they generate at the rate changes. Tracking errors here as you explain create distortions.

But will rate changes not happen anyway during the J-Test & that rate change distortion show on the graph?
I presume the rate change occurs naturally anyway, as a result of a drift between the calculated average speed of the input clock & the output clock?

Here's my simplistic understanding of the workings of ASRCs & why it is not the solution to jitter & indeed introduces it's own problems:

A portion of an incoming digital stream gets stored in a small buffer (not the whole song) - it gets clocked out of this buffer by a new local clock. You can never say the two clocks are the same, there will always be some difference between them so whether you are clocking out at a completely different sample rate, (usually called upsampling to 192KHz or whatever) or using the same nominal clock speed, the following applies.

It's required to recalculate the output amplitude of the outgoing sample based on an algorithm applied to the input sample's & surrounding sample's. Why? Because the output sample is being shifted in time & therefore not the same slice in time through the waveform so the amplitude at this new point in time will be different to the original. This requires an operation on the sample called interpolation i.e the new amplitude is calculated from the sample & surrounding samples. To calculate the new amplitude requires an interpolation ratio.

Calculating the interpolation ratio is where the problem arises - what is the input clock speed? The original clock fluctuates, so the clock speed has to be calculated as an average of the clock speed of a number of samples. This is an average figure & therefore may match some or none of the samples clock, certainly not all or even many. So firstly, just to be mathematically accurate about all this, this is incorrect & we will have amplitude errors on the output as a result. So for all the samples whose clock speed do not match exactly the average speed there will be an amplitude error on the output. Will this error be small enough to be inaudible?

The second problem arises because we have to keep a check on the buffer & if it is filling up too quickly our average clock calculation has to be re-done because the new samples are at a faster average clock rate. This means that the interpolation ratio is re-calculated & will be different to the last ration which applied to the last block of samples. Will this change in ratio cause a jump in distortion at this transition? It is speculated that it will & experience suggests that there is a limiting threshold below which ASRCs do not improve the sound.

 

[Vincent Kars]

A nice article on ASRC: http://www.iet.ntnu.no/courses/fe8114/slides/upsanddownsofasrc.pdf
The math is a bit over my head

 

[Phelonious Ponk]

OK...so here's a dumb question: If jitter is the bane of digital audio and a $350 DAC can drive jitter well below audibility, even with its switchable asynch mode turned off, what does a $10,000 DAC do? Does it convert more detail from digital to analog? Does it convert more accurately from digital to analog? If it does, isn't this going to show up in good FR measurements? Does it?

Tim

 

[jkeny]

OK...so here's a dumb question: If jitter is the bane of digital audio and a $350 DAC can drive jitter well below audibility, even with its switchable asynch mode turned off, what does a $10,000 DAC do? Does it convert more detail from digital to analog? Does it convert more accurately from digital to analog? If it does, isn't this going to show up in good FR measurements? Does it?

Tim

In order to answer that you might answer this first - have a look at the software resamplers at this site http://src.infinitewave.ca/
Look at the 1KHz Tone test result - hardly any of the graphs show sidebands > -120dB & yet there are audible differences between them as reported everywhere!
If you have an explanation for this then maybe your question will be easier to answer?

 

[DonH50]

Did they do any two-tone testing? Impulse response?

 

[jkeny]

Did they do any two-tone testing? Impulse response?

They do the following tests:
Swept Sine
1KHz Tone (-01.dB & -60dB)
Passband
Transition
Phase
Impulse

Yes, indeed a device (software in this case) needs to be better characterised with a battery of tests before anything can realistically be guessed about it's audibility based on measurements alone!

 

[DonH50]

No differences among them with any of those tests?

True 'dat.

 

[jkeny]

No differences among them with any of those tests?

True 'dat.

That is a question for Tim, I guess?

 

[RetiredAudioBuff]

What are people's view on ASRCs? I find that an ASRC benefits highish to medium jitter sources but invariably masks the benefits of low jitter sources.
I always am suspicious when a number of different inputs into a DAC all sound the same! It could be that the DAC is doing such a good job of jitter reduction that it makes all inputs behave at their best but in my experience, with DACs that have defeatable ASRCs, they sound better without ASRC when using low jitter sources. Even the ESS DACs, that have a supposedly very sophisticated ASRC, sound better when ASRC is turned off.

Any experiences to relate?

Hello. I'm interested in ASRC solutions (as a retirement hobby). I don't have much experience on appreciation of jitter removal capabilities of an ASRC to a HIFI audio signal. What is the minimal jitter rejection frequency fjitmin in the ESS DAC? I know that the deltaf convergence time of any ASRC is indirectly proportional to fjitmin. I may be getting off the subject but I am interested in why it seems most ASRC's use instantaneous analysis of the phase relation between I/O clocks to determine the next output sample. Why not analyze the deltaf obtainable by using small FIFO's containing the I/O samples? Then, update (on-the-fly) the coefficients of a delay sin(x)/x filter for generating the next output sample. This delay is related to the FIFO levels. The fjitmin could be drastically reduced (at the expense, of couse, of latency but still in the neighborhood of 1-2msec). Sorry if I changed the subject. Best regards!