Following-up on my previous post, I soldered a Crystek 100MHz clock and had a new set of Trident replacement boards made for my upgraded Buffalo III.
The new boards are direct replacements for the Tridents, supplying 2 x 3.3V for AVCC_L & AVCC_R, 3.3V for the oscillator, 3.3V for the AVDD and 1.2V for DVDD.
Upon powering up the board with the new clock and power supplies, I noticed a problem. Whenever I tried to play material with sampling rate over 44.1KHz, the sound became garbled.
In my test rig I had also used the same power supplies with no problem, so I guessed that the problem had to be the new oscillator. But the new oscillator appeared to be working just fine.
To further complicate things, when I turned off oversampling and the DPLL filter the sound improved (but still sounded bad because I was doing no oversampling).
After some probing and prodding, I realized that my 1.2V supply was sagging below 0.9V when the sampling rates went above 44.1KHz. That should not be happening, since I had set the current limit on my LT3042 regulators to about 125mA with the data sheet specifying the 9028’s 1.2V supply current consumption to 82mA. But it appeared that my 9028 was pulling in a lot more current.
So I disabled current limiting and tried it again. This time everything was working just fine, with no sagging, but my LT was getting hot. Real hot. Like 80 degrees C hot when playing 352.8KHz material. So I did a couple of things. First I desoldered the 1.2V power supply and inserted my DMM in series in order to measure the actual current draw. I got these results:
So up to 200mA! No wonder my LT3042 was having a hard time.. I was working it very close to its thermal limits.
I decided to mount it vertically and to add a heat sink to the back of the PCB.
With this arrangement I was getting about 62 degrees C with 44.1KHz material and up to about 75 degrees with 352.8KHz. This is tolerable for 44.1KHz playback but not cool (pun intended 😛 ) for high sampling rates. Since 200mA is pretty much the LT3042’s upper current limit, I’ll have to design a new power supply, either with two paralleled LTs or some other LDO. The bigger problem is the heat dissipation. I will have to make the PCB as big as possible in order to have a lot of room for heat sinking.
But why does this chip’s actual power consumption differ so much from the published specs? As always, the devil is in the details. The stated 82mA is for a sampling rate of 48KHz and a clock frequency of 40MHz. I’m using a 100MHz oscillator so power consumption ought to go up, but I never expected it to increase so much. I wonder what will happen if I input a 768KHz signal.
A few years back I was hit by Murphy and I was hit hard.
It was the time when you had to be very patient and even somewhat lucky if you wanted to buy a Buffalo DAC. You had to wait for the boards to go on sale and then be quicker than the other (equally “DAC hungry”) DIYers for the privilege of owning one.
I had just gone through all of that trouble and had managed to acquire a brand new Buffalo III board. I remember it like it was yesterday, even though it’s already been more than 5 years. I had it connected to my bench top power supply and was just doing a dry-run, I hadn’t even built the IVY-III yet, looking to see that everything was working as it should, when all of a sudden the lights on the Tridents all went very bright for half a second and then the magic smoke escaped. My power supply’s regulator IC had chosen the worst possible time to kick the bucket. Cost of repairing the power supply: ~1€. Cost of getting a new B3: ~400€ plus another 2 months of waiting.
An autopsy of the damaged board confirmed my suspicions: Almost every active component on the board was gone. Besides the Tridents and the AVCC module, the ES9018S and the Crystek clock were toast. The only components that survived were the ones behind the 3.3V regulator, which proved to be resilient enough to withstand the ~35 volts that were fed to it. So the cost of repair would be prohibitive, especially considering that I couldn’t find anyone that would sell a single ES9018S chip. So the bad board went into a cardboard box and lay there for close to 5 years.
Fast forward to 2016. ESS announces the successors to the ES9018S, the ES9028Pro & ES9038Pro chips.
These chips have a brand new digital core, much improved from the ES9018. There are new digital filters, a new DPLL system, new THD compensation features, a new gain compensation function, etc.
The ES9028Pro is supposed to be an ES9018S with an updated digital core, while the ES9038Pro is supposed to be an ES9028Pro with 4 times the output stages, resulting in an extreme output current capability. This very high current would be the reason why its DNR and THD+N performance would be off-the-charts. But it also meant that all of the existing I/V stages that were designed for the ES9018 would not work for the ES9038Pro. As of this writing, neither Twisted Pear Audio or Acko have on offering proper I/V analog stages.
I made this little table to give you a better idea of the differences between the old and new chips:
ES9018S vs. ES9028Pro vs. ES9038Pro
DNR (dB) 8-ch current mode
DNR (dB) 8-ch voltage mode
DNR (dB) stereo
DNR (dB) mono
THD (dB) current mode
THD (dB) voltage mode
Differential voltage out (AVCC = 3.3V)
Differential current out (AVCC = 3.3V)
Max PCM (w/oversampling)
Max PCM (bypassing OSF)
Max DSD (native)
Max DSD (DoP)
Digital filters (PCM)
Programmable THD compensation
Master or Slave mode support
1.2V (VDD) power consumption
AVCC power consumption
* up to 13
** most likely an error in the datasheet
This info comes from the official brochures that are available on-line, with some additional info from the NDA-protected “full” datasheets. ESS, if you are reading this (and you probably are), there really is no point in trying to keep these datasheets secret. If someone like me (with my non-existant connections) can find them, so can your competitors. Plus I can’t really say that I found any content in your datasheets that would warrant such extreme measures. But I digress.
So, upon inspection of the datasheets the first thing one notices is that both new chips are pin to pin compatible with the ES9018S. That was just too convenient for me and my bad Buffalo board. Good job ESS, I really appreciated that. 🙂 🙂
On the software side, things were very different to the ES9018S. The number of registers had more than doubled (48 registers in the ES9018 versus 115 in the ES9028/38) plus their arrangement was totally different, so I would need to do a total rewrite of the code to support it. Good. More fun to be had. 😀
So now a lightbulb had lit up in my head. I didn’t have much to lose – I already had the board, I could hook up temporary power supplies and a temporary clock so all I had to buy was the actual chip. Considering that I would like to be able to use my existing analog stage, I chose to go with the ES9028Pro. I got on Ebay and ordered a couple (a friend had also decided to bite the proverbial bullet and do the same “mod” to his Buffalo).
Next up was power requirements. The required voltages are the same but the required current has doubled or even tripled, depending on which chip we are talking about. That could be a problem for the AVCC module and Tridents of the Buffalo 3. I needed to do some reading-up on the AVCC & Trident modules. It turns out that the Trident modules are capable of supplying up to 100mA of power (with the proper CCS resistors) so in theory they could be made to work. But my (burnt) Tridents were v1.1, meaning that they were not exactly famous for their robust-ness. Asking them to work near their thermal limits would be looking for trouble. Plus, while researching the Tridents I learned of their latest version, the Trident SR. These now use ultra low noise LDOs (ADM715x) and are rumoured to sound even better than their older shunt types. These days my ultra low noise LDO of choice is the LT3042 so I drew up a set of PCBs that would be a drop-in replacement for the Tridents & AVCC and made an order to a well-known Far East board house.
While waiting for the chips to arrive I had put together some Arduino code that would initialize the chip and provide some basic functionality. It was nothing special – serial port only – but it would get the job done.
After a few days the ES9028Pro chips came and there was no way I was going to wait another month for the new Tridents.
Off came the damaged components..
..to be replaced by fresh capacitors and the brand new ES9028Pro.
For the time being I chose to not solder on a new Crystek since I could not be 100% sure that the board would work.
Instead, I soldered on a two pin header to which I connected an Si570 programmable oscillator that I had lying around.
Power was to be delivered by the on-board die-hard 3.3V LDO with a little help from a small PCB holding a LT3042 taking care of the 1.2V.
I hooked everything up, connected my Arduino, powered the thing on and loaded an I2C scanner on my Arduino. I did a scan and found a single I2C address. That was not good. I should have found two (one for the on board port expander and one for the ES9028). I double checked my connections, my power, made sure that my Si570 was outputting a proper clock, but still nothing. It was time to go back to the datasheet.
My eye fell on the section pertaining to the Reset pin. It stated that it was an active-low pin and that a system reset could be performed either by pulling the pin low or by a software command. The Buffalo III design called for this pin to be pulled low by default so I hadn’t paid any real attention to it. It turned out that I should have. I soldered a 2 pin header and put a jumper on it. The board immediately came alive and was detected by my I2C scanner. 😀 So, the Reset pin should be pulled up.
With that out of the way, I connected my test I2S source (a Chinese clone of an Amanero – not as good as an original Amanero but OK for testing and pretty expendable). The DAC locked with no problem into all sampling rates up to 352K and DSD128 (I didn’t bother to try to go higher) and started playing music!
Now I’m waiting for the new replacement Tridents & AVCC module PCBs to arrive so that I can do a proper test vs. my Buffalo III.
I also need to do a version of my TFT HiFiDuino code for the 9028/9038. Stay tuned.
It took me a little longer than usual (the board had been sitting around in my workshop for almost a year and a half), but it’s finally up. A page for a very good quality and very versatile Arduino controlled s/pdif receiver.
These days I’m co-developing an AK4490 based DAC. The aim is to end up with a no-compromise dual mono design, one that would perform at the very least on par with my Buffalo III.
Of course, to do that one has to run the 4490s in software mode.
As a matter of fact, it is generally preferred to run a 4490 in software versus hardware mode, for several reasons.
To begin with, in software mode the 4490 supports DSD decoding. It goes as far as to support a “Volume Bypass” feature which bypasses most of the processing done on the DSD signal (a.k.a. “the ΔΣ modulator”), resulting in more pure sound. But of course we do lose the ability to do volume control in software.
Software mode also allows us to try out all of the supported SQ features, like the different “Sound Setting” modes.
At last but not least, we get digital hardware volume control.
This is the prototype that we designed, getting I2S input from an Amanero and being controlled by my custom STM32 controller (more on that in the near future).
I searched the Net for any ready-made code that would control the 4490, but I couldn’t find anything worthwhile, so I began virtually from scratch.
So, my Arduino code (a.k.a. “aKduino”) enables:
Controlling an AK4490 through the I2C bus.
Automatic switching between PCM and DSD. It does rely on getting a “DSD type signal” from our USB-to-I2S interface of choice. The 4490 by itself is not capable of determining whether its input is PCM or DSD.
Setting the volume (in 9 steps.. just to confirm that volume control does indeed work).
Selecting “Volume Bypass” for direct DSD processing.
Selecting the internal DSD filter’s cutoff frequency (50KHz or 150KHz).
Selecting one of the 4 available PCM filters.
Enabling or disabling the Super Slow filter.
Selecting one of the 3 available “Sound Quality” settings.
Displaying all of the registers’ settings (for troubleshooting purposes).
Nothing (for now)
Basic Hardware Requirements:
Any Arduino (*)
(*) I should note here that the AK4490’s datasheet states that all of its I/O pins are expecting 3.3V logic levels but there has been a large number of reported cases of 5V Arduinos working without problems. I’m too much of a coward to try that myself so I used level converters for my initial testing and eventually a custom STM32 board that uses 3.3V logic but you may want to try your luck with 5V logic levels. Just don’t blame me if your 4490 gets damaged in the process.
Back in August an interesting thread was started on diyaudio.com.
It described a FIFO buffer and reclocker, aimed at SBCs and more specifically the RPi.
Its name was Kali.
The FIFO board would be able to “fix up” the RPi’s problematic I2S output so as to improve the sound quality of the used DAC.
As the discussion progressed, more interesting details came to light.
Kali was basically an FPGA design with on-board RAM, high quality clocks and flip-flops. It would buffer the DATA stream in RAM (about 0.7 seconds of audio) and it would then reclock it using flip-flops outside of the FPGA. The clocks used for the reclocking would be high quality NDK units sporting extremely low phase noise.
It would be powered by a 5V/3A power supply and would supply filtered power to the RPi (or not, selectable by a jumper) as well to the DAC that would sit on top of Kali.
It would have a claimed 3ps of jitter, which is an impressive feat for any I2S source.
It would provide a high quality MCLK output from a U.FL jack underneath the board.
The board’s general availability was scheduled for the end of August, and its price would be in the neighbourhood of $70.
At around mid August cdsgames offered to give away a number of units to diyaudio members for testing. I took him up on his offer and he was kind enough to send me one (along with a Piano 2.1 DAC board, but that’s for another post).
Fast forward to mid-September, when I received a package from India. In it was Kali and Piano 2.1 (more about that in another post).
On the left side of the board we can see the DC IN jacks (barrel and pin header), plus a couple of inductors that help with filtering the power lines. On the top left there is a jumper that controls whether Kali will supply power to the RPi or not. The Kali lists as minimum requirement a 5V/3A power supply. However, Kali itself will consume only about 100mA. The rest of the power is intended for the RPi and the DAC board. Note that Kali is designed so that it powers the RPi and not the other way around.
To the right we have the two NDK clocks, one for each one of the two “families” of sampling rates.
The Kali comes in two versions. One with clocks at 22/24MHz, capable of supporting sampling rates up to 192KHz, and one with 44/48MHz clocks, going up to 384KHz.
Note that there are two footprints available for the clocks so that a curious (and somewhat experienced) DIYer can also try out clocks with different footprints, like for example Crystek units. If you choose to go that way, keep in mind that you will also need to change 2 capacitors from 0.01uF to 0.1uF.
At the top of the board we have the usual 2×20 header that reproduces the RPi’s GPIO pins. There is one notable exception – Kali does not supply 3.3V at the relevant pin, so if your DAC needs to take 3.3V from that pin it will not work (more on that later).
Note that even though Kali has a JTAG header, the manufacturer currently does not support firmware upgrades. That’s understandable.. JTAG is not for consumer use and the manufacturer has to protect his IP..
At the lower end of the board we have an array of LEDs indicating the sampling rate of the incoming signal, along with the status of the buffer (Empty / Full / Lock) and the selected oscillator.
At the bottom of the board there is a U.FL socket that outputs Kali’s MCLK.
So, we have an RPi, we have Kali, now what we need is a DAC. Kali will put a few restrictions on your DAC choices. Your DAC will have to run as “slave” to the RPi, that is it will have to take its BCLK from the RPi and not the other way around. Examples of such DACs include for example virtually all of the DACs based on ES9023 chips. DACs that are designed to run as masters (in order to battle the RPi’s legendary jitter problem), such as the Hifiberry Dac+ Pro & Digi+ will not work, at least not without some extra work.
Plus, like I mentioned earlier, Kali does not supply 3.3V on its top 40-pin header, so if your DAC requires that voltage you’ll need to find a way to supply it externally.
Straying a bit from the DAC HATs, Kali will have no problem feeding pretty much any DAC that accepts standard I2S, like for example a TPA Buffalo DAC.
As a matter of fact, in my system Kali did a remarkable job of improving my RPi’s I2S output. The difference was obvious immediately. My RPi went from being a “net streamer quality” source to giving my Amanero a run for its money. Remarkable.
I am not talking about differences in bass or treble or tonality. It is like Kali manages to extract more music content from the data files. It revealed details that were there but were not audible. The music became more “real”. Imagine going from SD TV to HDTV. And that with the same 44.1K/16bit source material.
This improvement is not apparent only on expensive gear either. My first tests were done on my workbench with my RPi feeding an $8 9023-based DAC and listening through my headphones.
Even with this setup, Kali made a significant improvement to the sound. The $8 DAC went from sounding like an $8 DAC to performing at least decently. It was an obvious improvement.
So I can not imagine a scenario in which the Kali will not make an audible improvement to the sound.
Note that the first batch of Kalis (the ones that were sent to reviewers and a small number of units that were actually sold) had a bug that caused 16bit audio to have its channels reversed (and some more weird stuff happening with their I2S output resulting in somewhat degraded sound quality), but according to allo.com all effected units have been exchanged with fixed ones plus the ones that are shipping now to customers come with a fixed version of the firmware.
Even if for some reason you come by an affected unit, all you have to do is tell your RPi to output 32bit audio. That will fix everything.
I’d like to thank Ioan (cdsgames at diyaudio.com) for sending me the remarkable Kali. It will for sure become a permanent part of my audio chain.