Measurements: "ESS Hump" revisited (Khadas Tone Board V1.3)

[shevalier]

That defeats the whole idea of killing differential mode glitches

partially.
IRL
- for DACs with not very symmetrical outputs, like PCM179x, this capacitance strongly balances them and reduces THD by 2-3 times
(but some DAC demonstrate no effect, where we loading current output to ground by resistor or capacitor for filtering/damping
but some DAC have strong ultrasonic noise, and we should filtered it before i/v..... compromise is.)
- it part of the low pass filter for i/v
- it part of the RC snubber that prevents oscillations/overshooting at the input of i/v.

when simulating i/v, you need to put not an ideal current source with infinite resistance, but something more realistic. For example, a current source on a field transistor and a pair of protective diodes.

 

[Grooved]

Well, I have found additional information.....

I was using 24bit, 44100 in Windows Advances property for Gustard for a while. Yesterday I temporarily switched to 16bit for blind testings, but switched back to 24bit today because I wanted to match my KTB settings. With that 24 bit setting, Gustard hi hat sounded really soft. I tried switched to 16bit 44100 just now, and I got stronger and sharper hi hat from Gustard, like KTB.
KTB setting in Advanced property have always been set at 24bit, 44100 (no option to switch to 16bit), but it sounds strong and sharp, not like Gustard in 24 bit. So, likely driver related differences between Gustard and KTB???

Hi @Pdxwayne ,

did you try with something like ASIO Bridge ? (assuming you have ASIO driver for both Gustard and KTB)
It works like "Software WDM output -> ASIO Bridge -> ASIO driver of audio device", so kind of the opposite of ASIO4ALL ("Software ASIO output -> ASIO4ALL -> WDM drivers of audio device")

At least, Chrome will send audio the same way to ASIO Bridge, and only the ASIO drivers will make a change when you flip from one device to the other.
Link : https://vb-audio.com/Cable/index.htm#DownloadASIOBridge (donationware, so you can try and send money later only if it's usefull to you)
I measured it and it looks OK up to 24/192 (which is not the case of their other software "VB-Cable")

 

[noi1996]

When a cross capacitor (220pF) is used with the OPA1612, the simulation shows a peak at 15-20MHz for the capacitor alone.
The cross capacitor alone tends to be a bit unstable even with LME49720.
I think 220pF is appropriate, but these opamps seems to require a resistor of 33-68 ohm in series.

Also, I have not verified it enough, but I feel that putting ferrite beads in series with 470pF+10R is also effective above 50MHz in the circuit of post #99.
For example, TDK MAF1608GAD201LTAH0 or MAF1608GAD471LTAH0, which are claimed to have low distortion for audio use.

 

[KSTR]

When a cross capacitor (220pF) is used with the OPA1612, the simulation shows a peak at 15-20MHz for the capacitor alone.
The cross capacitor alone tends to be a bit unstable even with LME49720.
I think 220pF is appropriate, but these opamps seems to require a resistor of 33-68 ohm in series.

Also, I have not verified it enough, but I feel that putting ferrite beads in series with 470pF+10R is also effective above 50MHz in the circuit of post #99.
For example, TDK MAF1608GAD201LTAH0 or MAF1608GAD471LTAH0, which are claimed to have low distortion for audio use.

Let's not forget the cross-C is hack, and dirty one, for the OpAmp used on that board. Plus it follows the guideline for a least effort hack ;-)
In a regular PCB you'd just replace a SO-8-encased OpAmp and deal with the feedback

Any decent OpAmp does not need this (even 33078 was fine in the D10B) and if one were to add this kind of deglitching one would do it properly without compromising OpAmp stability from capacitive loading and lower Aol*ß phase margin leading to unneccesary gain peaking.

As for a series R with a feedback C for general stability (were my original comment was aimed at), it is not needed for most OpAmps except a few, AD797 being the most prominent. In an I/V with significant shunt capacitance at the input it actually can be a sketchy trade-off.

 

[shevalier]

putting ferrite beads

ferrite has a high level of distortion depending on the signal current
This may be a coreless inductance, but its high quality factor will have to be compensated by a 10-100 ohm parallel resistor.
Thus, the resistor is still needed, and the inductance is superfluous.

About filtering, ( or why i/v should be filtering)
1. reconstruction filter (nyquist) 1/2 lsb or sinad. for a 20-24 bit DAC, this is 10 (12? I don’t remember) order, which is practically not realizable.

2. anti-noise filter (when Cirrus Logic was still a Сrystal semiconductor ) - out-of-band noise is lower than distortion.
~5-6 order

3. Modern point of view - "2 order good enough"

2nd order in i/v and 2~3nd order LPF is good engineering compromise for modern DAC with low out of band noise.

PS
For a rigorous calculation, all the same, out-of-band noise must be measured with an oscilloscope with FFT directly from the DAC for PCM&DSD mode (for current DACs - on a resistor of 1-10 ohms to the ground), and then only calculate the I / V and LPF.

Good luck.

 

[CedarX]

I saw in the recent DX5 review that Topping has released a new FW to address the ESS hump on that DAC. Granted it’s not the same chip as the KTB—dual ES9068. But if the hump is I/V related, how a FW udate can fix it? Is the hump coming from a combination of factors?

 

[Herbert]

Probably a combination with I/V being the crucial part.

 

[KSTR]

I saw in the recent DX5 review that Topping has released a new FW to address the ESS hump on that DAC. Granted it’s not the same chip as the KTB—dual ES9068. But if the hump is I/V related, how a FW udate can fix it? Is the hump coming from a combination of factors?

ESS chips tend to have a myriad of "fine-tinung" setup registers which are not very well documented what they do to performance and how they interact.
It is very likely that a setup for a specific implementation can be found that is better than sticking to the hardware default values for these settings.
The distortion compensation registers, for H2 and H3 compensation, are the obvious ones that come to mind, and ESS actually advises to use them to trim performance. But other parameters may also play a role there. Big black box.

The only way to find out what Topping did with the DX5 firmware is an a A/B compare of the setting they progam into the chip, using an I2C sniffer / data analyzer (the register settings are transmitting using this industry-standard hardware protocol).

We have to be aware that the "fine-grain" in the higher order distortion spectra for ESS DAC (in PCM mode) is never really nice but when one can reduce them by, say 10dB, then they might land well below the electronic noise floor and thus do not affect in the IMD vs level plot -- no hump anymore. It basically depends on this noise floor if a hump appears, the lower the base-line the more likely the hump becomes visible. In a dual 9068 DAC the noise floor is rather low and thus it is harder to remove the visible hump.

 

[CedarX]

Thanks for the perspective on these poorly documented ESS registers (a recurring complaint apparently) and their potential effect on the hump.
BTW, fascinating thread and hats off to all the contributors! Seeing that even Topping could struggle with the hump—even if it’s largely academic—shows how difficult this topic is!

 

[wacomme]

Did the ESS hump in the DX5 get "fixed" with a firmware update? Has anyone tested the improvement?

 

[staticV3]

Apparently a new firmware gives you three options for IMD performance.
WolfX-700 measured them as such:

Source

 

[wacomme]

Apparently a new firmware gives you three options for IMD performance.
WolfX-700 measured them as such:
View attachment 207926
Source

It seems that the hump improvement is minimal from what I can decipher.

 

[BR52]

Hi @KSTR, great work! Thank you for bringing some light in the dark of the ESS-Hump.
Unfortunately, I saw this thread very late (yesterday). My Audiophonics Evo_Sabre balanced DAC showed the hump in amirm's measurement as well.
This one has 2 x ES9038Q2M and 4 x 5534 (soic)! 2 outputs in parallel feeding one 5534 i/Vs. I changed the 5534 to Opa 1611
and shorted out the 20 Ohm resistors. I observed a similar behavior you described in this thread.
My measurement capabilities are unfortunately momentary, a little limited because my ADC is too noisy.
Anyhow, I could measure an improvement over the original version. One of the biggest penalties in this design is the direct paralleling of the 2 current outputs, so transient energy the i/V stage has to handle is twice.
agin great work thanks
BR52

​

​

 

[okok]

everyone can grab datasheets from the famous ess right, they release them in public, like trump seized by feds

 

[capslock]

I wasn't aware the hump shows up in THD measurements of ESS DACs. This very interesting thread on ESS vs AKM ADCs prompted me to search:

ESS hump strikes back

What is wrong with ES9311Q?! Too high LF noise for the intended purpose (DACs & ADCs). And the most unreliable IC I have ever worked with. I don't mind the cost but the couple of hours I spent on PCB layout to accommodate these.

www.diyaudio.com