ESS Sabre Reference DAC (8-channel)

Certainly the Buffallo II makes design choices that will effect what registers you will want to change. But there is nothing onerous about that at all. In fact we made careful decisions after lot of consultation with Dustin and others.

That said if there is demand we may go ahead with a multi channel multi input PCB. It really just depends on if it is useful enough to enough people to make it viable.
 
As I wrote in the TPA thread I did a test of the effect of the default mapping of the inputs and the mapping used by the Buffalo II as a result of some discussions with Russ (all posts was deleted).

I wrote a test code with both mapping variants for SPDIF on data6 and I2S.
As I can change all register settings from the IR remote these four code fragments was made to be sure no other register settings interfered.

The result was partly unexpected as the Buffalo style input mapping introduced the unlock problem when playing I2S at 352.8k using normal filter, slow slope, OSF enabled and 7bit quantizer.
Only four unlocks during one melody, but that was the first unlocks for the last year. It might have been coincidental, but I changed nothing else than loading new code.

One of the questions was if the input mapping have effect on how the quantizer/true/pseudo modes reacts to changing the phase/polarity.
I have checked this before and I got the same result now.
7bit quantizer mode are the easiest to check as there will be no audio when the phase/polarity are inverted when the Buffalo input mapping are used - this affects both I2S and SPDIF.
Also all FIR / IIR / OSF modes was affected of the input mapping.

With the default input mapping the phase/polarity can be inverted in all quantizer/true/pseudo/FIR/IIR/OSF modes.

If this is tested on a Buffalo II only half of the DACs will be used with I2S with the default input mapping - all DAC will be used by SPDIF with both input mappings..
 
Last edited:
On Bufallo II you can do all quantizer setting, but all except 6 will require pseudo differential. This is perfectly normal. Polarity changes are also easy, they just require a little thinking. I am sure you can figure it out. I did it for dual mono support.

The fact is you just have to know how the inputs are connected (which I just shared) and work from there. Pretty simple really. Use the DAC as designed and you will be just fine.

I am not going to take any more of my time to correct you.
 
On Bufallo II you can do all quantizer setting, but all except 6 will require pseudo differential. This is perfectly normal. Polarity changes are also easy, they just require a little thinking. I am sure you can figure it out. I did it for dual mono support.

The fact is you just have to know how the inputs are connected (which I just shared) and work from there. Pretty simple really. Use the DAC as designed and you will be just fine.

I am not going to take any more of my time to correct you.

There is no need for you to correct my findings.
The "thinking" to sort out the alternate settings for polarity changes with the Buffalo style input mappings was not the issue - the issue was the conditional code needed to support this on the fly from the IR remote together with the ability to change all the other settings independently.
When the default input mapping works perfect and identical with all other settings - why waste time on the issue - Buffalo will not be supported, but that have never been the intention...

I am but curious to your comments regarding the 7 and 8bit modes.
I will check my code again and verify all register settings regarding the true/pseudo modes...
 
RayCtech, I need to be clear, the dac I posted is not my design, this is the teflon version ackodac AKD12P, I may have 4 of the only 6 made in my possession, the only ones sold to the public so far and had some small measure of input into design choices, but not their implementation.

also perhaps off topic as this is a ES9012 design, although there is a 9018 multichannel version in the works
 
I reprogrammed the DAC to match the BuffII input wiring and indeed sounds real good.

But the locking problem is still there, and in my set up, it goes (mostly) away with DPLL BW=medium-low

In addition, the locking problem is much worse if the DAC is cold (right after power on). After power on, the problem diminishes until it reaches a steady state.

One peculiar result is the frequency reported by the DPLL register:

With 44.1 material

SPDIF input, DPLL register reports 44,105 Hz
I2S input, DPLL register reports 44,079 Hz

I had measured the bitclock of the I2S output to be 2,822,470 Hz; at 64fs that is 44,101 Hz

Is the DPLL using the wrong frequency to lock and thus the lock problem? (just a question since I know nothing about DPLLs)

the discussion above on quantizer is over my head. (The Sabre32 data sheet says nothing about setting quantizer values). Does quantizer setting has any bearing on the lock problem?
 
Last edited:
DPLL Bandwidth setting for DSD

Recently in Japan, some diy people has been trying a DSD input for ES9018 based DACs, for example, Buffalo II, Fidelix CAPRICE. Their DSD sources are USB Audio interface board developed by ElectArt or diy-tapped commercial SACD players.
Two of them reported that no better DPLL bandwidth setting is available than "medium-low". I guess qualities of their sources are not so bad.

They also reported that they tested a dual "all mono mode" configuration of ES9018 for DSD and got better results than those of the usual "stereo mode".

Anyway, ES9018 based DACs are rapidly gaining good reputations here.
 
With the Sabre32 DAC I can run the minimum DPLL bandwidth with 192k/24bit on SPDIF and 352.8k/32bit on I2S.

This requires an update:

My code for Sabre32 register control have been revised several times lately and as I already have reported I experienced the UNLOCK problem intermittently shortly after loading new code.

I have now completely rewritten the code for Sabre32 register control and can verify that I now also have the UNLOCK problem constantly :(

The possibly good news are that I found the root to the cause to why the old code only experienced the UNLOCK problem intermittently when loaded and then the UNLOCK problem went away...

The UNLOCK problem stopped when a illegal/not supported register setting stored in the EEPROM was loaded into the Sabre32.
I am now investigating what this settings actually affects and to possibly find the cause to why it stopped the UNLOCK problem...

When the new code was rewritten I included support for all possible register settings. Due to this I have also included support for Buffalo input mappings and this is now a selection on the IR remote. I have also included a status display dump to the LCD where all register settings are shown.
 
Hi RayCtech,

Thanks for sharing. I guess I can now "take a break" from poking the registers :)
I also tried all possible configurations and pretty much have ran out of things to try. The best I can do is medium-low after the DAC "warms up"; but even with that setting I would randomly get unlocks after a few/many songs.

Hi glt,

I have programmed a test routine to check out all the remaining register value combinations.
There are 18 different register bits settings I need to check out...
 
DPLL UNLOCK issue

The different settings are checked out and other than the disabling of the OSF as Bunpei mentioned earlier I found two possible settings that "cures" the UNLOCK issue.

They both "cures" the UNLOCK issue and when AB compared I cannot hear any big enough difference to rate them against each other.
A - 352.8k/24bit I2S with variant 1, B - 352.8k/24bit I2S with variant 2.
I also compared both I2S variants with - SPDIF 176.4k/24bit and there was not much difference there either.

With respect to Russ comments with regards to undocumented settings and as he previously also have stated he is unable to run the buffalo in 7 and 8 bit True mode even if the modes are supported make me wondering..., and even if these settings to "cure" the UNLOCK issue should not be any secret or big issue I will leave it up to Dustin to comment or reveal the correct solution as he only knows the facts...
 
Last edited:
Ray, You are quite wrong. I never meant to say you could not make it work in 7 or 8 bit true differential. I was really saying you should not. :) We are talking getting the results you want not just what will *work*. You can set 7 and 8 bit true differential and the DAC will work, but the effects are not desirable (very easy to hear and see with a spectrum analyzer) at all. Also, I did not come to these conclusions today. I have been playing with these registers for quite a long time, and it was Dustin himself who recommended using pseudo differential (in the case of buf-II) when not using 6-bit mode. So when you read "require" read it as "require for best results".
 
Last edited:
On Bufallo II you can do all quantizer setting, but all except 6 will require pseudo differential. This is perfectly normal. Polarity changes are also easy, they just require a little thinking. I am sure you can figure it out. I did it for dual mono support.

The fact is you just have to know how the inputs are connected (which I just shared) and work from there. Pretty simple really. Use the DAC as designed and you will be just fine.

I am not going to take any more of my time to correct you.

Russ, I read this posting as it was written :)
I can hardly understand it differently now as require obsoletes other options, but I can tell you that the True modes also works excellent

When you states the following:

very easy to hear and see with a spectrum analyzer

I expect that what you listen to and measures are the Buffalo II with your IVY and powersupplies and the Crystek 80MHz clock??

What I hear are quite different, but it is also with only one common factor - the Sabre32 chip...
 
Last edited:
What I hear are quite different, but it is also with only one common factor - the Sabre32 chip...

Absolutely. It very easy to get those modes to sound fine with the ES9018, but you simply need different input routing choices.

All in all based on the best data available from Dustin and the datasheet I stick with 6bit true differential in firmware, as it simply both measures and sounds the best to *me*. :cool:

I certainly don't have anything against people who prefer something else, but we got the best measurements and listening results that way.

Use whatever you prefer by all means.

Also, I have been listening to the saber DACs in more ways than I can count. All sorts of clocks and output stages.
 
Last edited:
Update to the DPLL UNLOCK issue

I investigated this "problem" and found two possible solutions....

As it happens we all have introduced this "problem" by using other than the ESS recommended default DPLL settings ;-)

When I just now checked the datasheet I "discovered" that one of the solutions to cure the "DPLL" was to use the ESS recommended "default" settings for the DPLL LOL!!!!

I have now verified that this have been the cause my Sabre32 have worked perfectly all the time..
I had not bothered to "tweak" the DPLL settings due to when I tested this a year or more ago I found no improvements.....
As a result the DPLL settings was overridden with the default settings stored in the EEPROM...
 
Last edited:
Do you mean "best DPLL setting" in reg25?
Still doesn't explain why spdif would work with lowest dpll setting (and "allow all settings" in reg 25)

I investigated this "problem" and found two possible solutions....

As it happens we all have introduced this "problem" by using other than the ESS recommended default DPLL settings ;-)

When I just now checked the datasheet I "discovered" that one of the solutions to cure the "DPLL" was to use the ESS recommended "default" settings for the DPLL LOL!!!!

I have now verified that this have been the cause my Sabre32 have worked perfectly all the time..
I had not bothered to "tweak" the DPLL settings due to when I tested this a year or more ago I found no improvements.....
As a result the DPLL settings was overridden with the default settings stored in the EEPROM...
 
Last edited: