The options offered by the onboard firmware and switches are listed here. In order to completely bypass the DPLL you need I2C. In order to enable external I2C control you must do 2 things: a) remove the firmware ROM, and b) on power-up you must pull the DAC's reset pin low until all supply voltages are stable, and then to operate you pull the reset pin high. None of the memory in the chip is retained when it is powered off. There are simple reset programs for Arduino at GitHub, and I have been using a BBB or an RPi for this job. The I2C should be isolated. This method is the price of admission to the inner workings of the ESS Pro chips, regardless of the board that the chip is mounted on. You could add an I2C isolator chip on a small adaptor board at the I2C header on the Buffalo because the header includes clean 3.3v. The same is true for the header that includes the reset pin. An alternative would be to reprogram the onboard firmware. For me, it is simpler to use a more interactive controller like an RPi or a BBB. I would gladly supply you with code to run on any Debian OS. Once programmed and finalized, custom reset would be a completely automatic part of power-on.
Yes. The Placid 2.1 would be a good choice. If you decide to integrate a controller like an RPI or Arduino, etc., then a Centaur is a good choice to give it clean and reliable power. An RPi 3 or 4 can use a surprising amount of the Centaur's output. I recommend against any switching supplies in a SOTA environment. Yes, 9v transformer, and separate transformers and supplies for the DAC vs any I2C controller.
Regarding the I2C controller, I recommend keeping the I2C connection short. I have tried both 'in the box' and 'outside the box' locations, and shorter I2C connections are simpler. 'Outside the box' connections should be shielded. Edit: Just for safety, I also shield 'in the box' I2C lines but that is from an abundance of caution.
Again, the alternative of reprogramming the onboard firmware is much simpler but I am simply not qualified to do it myself.
Best, Frank
Last edited:
Hi Frank,
reading the following post
Introducing the Buffalo III-SE-Pro 9028/9038
I thought the pure sync mode was already included in the new firmware.
Isn't so?
Thank you for the tips about the power supply, then I can go with the Placid since I don't need to supply any source. The source will be my FIFO buffer with external oscillators.
Andrea
reading the following post
Introducing the Buffalo III-SE-Pro 9028/9038
I thought the pure sync mode was already included in the new firmware.
Isn't so?
Thank you for the tips about the power supply, then I can go with the Placid since I don't need to supply any source. The source will be my FIFO buffer with external oscillators.
Andrea
Anyone can help understanding if the true sync mode has been implemented in the latest firmware?
And if so, is it active at startup or is there something to do to get it active?
If not so, I would like to update the firmware to get the true sync enabled when DPLL bandwidth is set to 0 by the 4bit DPLL Bandwidth switch (switch 2 5-8).
Then I thought to modify the Buffalo.c source code as:
R10_MASTER_MODE_SYNC r10;
r10.byte = R10_DEFAULT;
if (dpll == 0) r10.fs128_mode = 1;
i2cSendByte(DAC_ADDRESS, 10, r10.byte);
R12_JE_DPLL_BW r12;
uint8_t dpll = sw2.dpll;
// we don't ever want the DPLL to be off
// DPLL off enables 128fs_mode (true sync)
// if (dpll == 0) dpll = 5;
Does this will work?
How can I recompile the firmware and upload it to the microcontroller?
Thank you for your help.
Andrea
And if so, is it active at startup or is there something to do to get it active?
If not so, I would like to update the firmware to get the true sync enabled when DPLL bandwidth is set to 0 by the 4bit DPLL Bandwidth switch (switch 2 5-8).
Then I thought to modify the Buffalo.c source code as:
R10_MASTER_MODE_SYNC r10;
r10.byte = R10_DEFAULT;
if (dpll == 0) r10.fs128_mode = 1;
i2cSendByte(DAC_ADDRESS, 10, r10.byte);
R12_JE_DPLL_BW r12;
uint8_t dpll = sw2.dpll;
// we don't ever want the DPLL to be off
// DPLL off enables 128fs_mode (true sync)
// if (dpll == 0) dpll = 5;
Does this will work?
How can I recompile the firmware and upload it to the microcontroller?
Thank you for your help.
Andrea
Last edited:
Hello Andrea, true/pure sync (no DPLL) firmware is not a new official firmware version, but a beta version that Russ released some time ago to test 128fs mode.
You can find firmware link in post #506 and instructions scattered along the following posts. Pure sync mode is active at start, if you properly position n. 1 dip switch in first group, as explained in post 506.
To program the ATTiny85 chip needed you can use a simple programmer, like the one linked in post #516. Total expense for the mod (including programmer) is just a few euros.
Even if totally noob about chip programming and I2C, i tried and succeded replacing normal firmware with pure sync one. Sound is slightly better IMHO, but incredible improvements are not to be expected as normal sync mode is already very good in this dac. Async mode is good but in a lower league than sync mode IMHO, when a decent master clock/reclock/FIFO setup is used. As Frank said, in any sync mode onboard oscillator has to be disabled by removing its trident (or different) power supply and a master clock has to be provided.
I had a problem with 128fs mode, about annoying pops in case of files frequency changing. Some other user had it too, many didn't. So i switched back to normal sync firmware.
My personal additional suggestion is to take care to implement a first order LP filter at around 32/33 khz, somewhere on output (obviously after I/V and possibly first O/S preamplification), as for any sabre dac. But this is only an "unofficial" tip...
Given your musical tastes, a tubes or high permeability/nanocrystalline core transformers I/V output stage should be considered, too.
Last edited:
Thanks for the tips, I will try to load the unofficial firmware with pure sync mode.
My goal is just to run the Buffalo fed by my FIFO buffer and external oscillators.
Since these oscillators are very low phase noise devices (in the region of the best oscillators on the market) I would avoid the DPLL running, so I think the pure sync mode is the best way to get the best timing performance.
As the I/V converter I'll use transformers, maybe followed by a tube buffer.
I recommend the Centaur over the Placid for the Pro38 so there is plenty of current overhead available.
chips
The 9028 uses the ESS 9028 Pro DAC chip, and the 9038 uses the ESS top of the line 9038 DAC chip.
The 9038 chip achieves better SNR with its higher current output, IF one has an I/V stage which can take advantage of that higher current as the Mercury I/V stage can. For transformer I/V I would expect with the right transformer the 9038 would have an advantage.
The 9028 uses the ESS 9028 Pro DAC chip, and the 9038 uses the ESS top of the line 9038 DAC chip.
The 9038 chip achieves better SNR with its higher current output, IF one has an I/V stage which can take advantage of that higher current as the Mercury I/V stage can. For transformer I/V I would expect with the right transformer the 9038 would have an advantage.
How much is the current output from the 9038?
I have a pair of Sowter 1590 (MC step-up) to be used in the I/V.
The ratio is 1:30 but I can play with the output resistors to change the reflected impedance seen from the DAC.
This is an interesting approach and I will be curious about your final configuration and conclusions. I have a few questions.
1. How did you parallel the chips? A purpose-made circuit board, or other surface mount arrangement?
2. Did your circuit include a guard zone for the SET pin (#7)? If so, which board layers?
3. Whoa, 6 chips? That's up to 3 amps, so were they feeding other circuits than just the B3?
I tried a more conservative application of one LT3045 on my most recent project. It supplied the VDD_XO through a relay so that I could remotely switch between synch and asynch DAC operation. At first I set it at 3.3v and used a small passive filter at the B3's VDD_XO input. Not so successful - probably too much wire between the regulator and the B3. I then raised the LT3045 output to about 4.5v and sent that into the VDD_XO trident. In this configuration the SPDIF sources that use the 100MHz onboad clock are sounding very nice. But those are fairly jittery sources so I wouldn't over-sell the experiment and assume that all sources - especially synchronous ones - would benefit as well.
If I'm not mistaken, the LT3045 in an optimal layout should offer about half of the noise of a Trident. I don't have any idea about the PSRR of Trident output. But I would think that with adequate capacitance and enough 3045s for current overhead, the LT3045 could improve the B3Pro performance. But as pages 14 and 15 of the analog devices datasheet suggest, the devil would be in the details.
Please keep us informed if you try the LT3045 for AVCC!
Cheers,
Frank
MPA audio offers boards that have already mounted the LT3045 chips in parallel. I will try with "double" regulation into the tridents and directly feeding AVCC.
I'm wondering if anyone in here can give me some pointers? I have set up a dual mono with 38's and Mercurys. I'm using an spdf input,coaxial, I have a lock but no sound. (Except some squeaks at power off). I have checked voltages, including tridents, and they look good, I have a lock on both boards, but no sound. (I found a link to some firmware for a dual mono setup on github, which gives the lock on both channels as the supplied version only gave a lock on the master. Incidentally that is silent too.)
I had some IVY board so I swapped out a Mercury and tried that...silence. So I think that this may be the analog out on the BIII. I have switch 1 board 1 set to on, but have tried both positions.
I'm not using a volume control so I've just connected the 3.3v pin to PB4. Ive also connected GND, SDA and SCL on both boards. Resets also connected, GPIO pin 1 each board. Also GPIO pin 11 and 12 connected on slave DAC.
All swithces set to ON.
I have some Attiny 85's and can flash with hex files if anyone suggests some firmware.
I'm just not sure where to look next.
Cheers all. I love trawling through this sight for ispiration.
I had some IVY board so I swapped out a Mercury and tried that...silence. So I think that this may be the analog out on the BIII. I have switch 1 board 1 set to on, but have tried both positions.
I'm not using a volume control so I've just connected the 3.3v pin to PB4. Ive also connected GND, SDA and SCL on both boards. Resets also connected, GPIO pin 1 each board. Also GPIO pin 11 and 12 connected on slave DAC.
All swithces set to ON.
I have some Attiny 85's and can flash with hex files if anyone suggests some firmware.
I'm just not sure where to look next.
Cheers all. I love trawling through this sight for ispiration.
Will/Have you tested the 5.6MHz clocks for this?
I only discovered the other day that the 9038 (and possibly other ESS DACs) could work with 5.6MHz clocks for redbook. The PCM179X DACs also allow it, not aware of any other DS DACs that can.
Not yet tried, I should receive the boards next days.
In pure sync mode I believe it works at 128fs, so with 5.6448 MHz crystal it should play redbooks.
Perhaps look here: Buffalo III SE (Stereo Edition) Pro
If there is a firmware chip in place then you must not connect the reset pin - let it float. If you plan to use I2C for control instead of onboard firmware then you need to manage the reset function in addition to having SDA, SCL, and GND connected to a (preferably isolated) viable controller BUT you will need different addresses for each of the two boards. The two means of control - firmware vs. I2C - are typically mutually exclusive.
Any follow up impressions on your 9038 DAC?
I got a cheap 9038 based Topping D10S the other day and in stock form it was a really striking example of how objectively bad/incorrect (heavily compressed and unrealistic dynamics) a DAC can sound despite very good measurements
The Topping D10S does indeed test out well.
Topping D10s USB DAC and Bridge Review | Audio Science Review (ASR) Forum
However,
1. Comparing the ES9038Pro to the ES9038Q2M is not apples-to-apples because the latter has only 2 channels while the Pro has 8, which are averaged to create stereo output. https://www.mouser.com/datasheet/2/1082/ES9038Q2M_Datasheet_v1_3-1923484.pdf
2. This is a prime example of the fundamental importance of *how* the DAC IC is implemented - the power quality, the operation mode (current vs. voltage output), the design and linearity of the balanced to SE conversion and output, and perhaps even the benefits of input data reclocking.
As you point out, the objective is nice sound, not nice graphs!
Sorry, didnt mean to imply that the Buffalo was comparable. I bought as D10s as a modding platform and possibly to use with andrea's FIFO+clocks in future, If the impressions of Buffalo were positive then it would give some idea if it's worth pursuing it with D10s.
Definitely some large improvements needed in the power supply of D10S,
Since the op amp I/V wouldn't be loaded as much its possible it has some benefits for SQ of I/V stage with only 2 channels.
Definitely some large improvements needed in the power supply of D10S,
Since the op amp I/V wouldn't be loaded as much its possible it has some benefits for SQ of I/V stage with only 2 channels.