ESS Sabre Reference DAC (8-channel)

[Bunpei]

... On my setup with DPLL Bandwidth set to "No Bandwidth" using spdif inputs the ES9018 completely losses lock, but regains a very steady lock when the DPLL BW is multiplied by 128. ...

I hope you understand my point. Those Japanese people are challenging to "No bandwidth" DPLL setting which is very difficult to achieve.

it is whird. Why does tackbon not generate BCLK via dividing MCLK?
Can it call "sync MCLK"?

I think you can ask it to him directly by posting your comment on Tackbon's blog page.

You are right, BIII doesn't support DPLL "No Bandwidth" setting.
What confuse me is why DPLL is up and running in sync mode?

To be exactly, there is no "sync mode" on ES9018 architecture. DPLL is always ON. However, it is actually "free wheeling" ( this is Russ'es nice wording ) when a synchronous master clock is injected.

 

[AAK]

Hi Bunpei,

I understand your point. I just wanted to point out that with an Spdif Input, 100Mhz asynchronous clock, and the DPLL BW set to "No Bandwidth", my DAC locks when the DPLL Multiplier is set to x128. No lock at all when set x1. Thought maybe this information can help your Japanese friends.

Any ideas why if there's "No Bandwidth" the ES9018 locks when the DPLL Multiplier is set to x128? I have some ideas, but not entirely sure. Thanks!

Best regards,

Al

 

[Bunpei]

Hi, Al,

I have realized that I need to explain our background enough for you.

You mentioned S/PDIF and DPLL multiplier x 128. In this case, the DPLL bandwidth condition is 64 (S/PDIF) x 128 times looser or more relaxed than that of 1(I2S) x 0 (No bandwidth).

The Japanese people do not want the easy locking. They are deliberately challenging the most difficult condition because they once perceived that the resultant sound had the best spacial focusing.

Bunpei

 

[Bunpei]

We discussed a possible interpretation of the magic period 95 or 96 seconds.

Under the condition;
fs=44.1 kHz, MCLK=11.2896 MHz, BCLK=2.8224 MHz, I2S, OSF=ON
DPLL counter value is 0x3FFFFFFF ( a quarter of 0xFFFFFFFF).
The counter counts BCLK.

0x3FFFFFFF / 44100 / 64 / 4 = approximately 95
( Oversampling ratio is 4 ? )

The DPLL counter might be reset when the counted value reaches to 0x3FFFFFFF and the resetting action may cause the unlock event.

 

[RayCtech]

We discussed a possible interpretation of the magic period 95 or 96 seconds.

Under the condition;
fs=44.1 kHz, MCLK=11.2896 MHz, BCLK=2.8224 MHz, I2S, OSF=ON
DPLL counter value is 0x3FFFFFFF ( a quarter of 0xFFFFFFFF).
The counter counts BCLK.

0x3FFFFFFF / 44100 / 64 / 4 = approximately 95
( Oversampling ratio is 4 ? )

The DPLL counter might be reset when the counted value reaches to 0x3FFFFFFF and the resetting action may cause the unlock event.

Strange interpretation...

The "DPLL counter" will always have a 32bit number that you can read regardless if the data are PCM from I2S input, PCM from SPDIF input or DSD.

If you read the "DPLL counter" repeatedly to a display you will see that the "DPLL counter" number will be relatively stable..

Thus you can calculate the sample rate, the bit frequency etc. and you can then monitor the clocking accuracy or the incoming clocking accuracy - all depending on how you program and how reliable your master clock is. If you know the incoming sample rate you can calculate the master clock frequency. So there are no magic periods related to the "DPLL counter" that causes what you call a "resetting action".

It does not matter if OSF =ON or =OFF => the difference in the result are exactly 64...
So my programming checks if OSF = ON or OFF and then divides by 64 or not to get the correct results..

 

[CeeVee]

Hi Mihai,

What's that IV you are using on post #2188 ?...looks to be quite different from your other one.

You know that's my focus right now ..

My setup is singing but I'm using temporarily a Legato 3.1 as IV...just for starters.

Great work.

 

[roender]

Hi Mihai,

What's that IV you are using on post #2188 ?...looks to be quite different from your other one.

You know that's my focus right now ..

My setup is singing but I'm using temporarily a Legato 3.1 as IV...just for starters.

Great work.

It isn't an I/V stage, just a buffer and low-pass filter for Sabre DAC in voltage output mode.

 

[CeeVee]

"It isn't an I/V stage, just a buffer and low-pass filter for Sabre DAC in voltage output mode."

...It's always in voltage mode ...


Ok, I'm finishing a PCB design for your IV...Ill post it in the proper thread when i find the right output cap for it, It fits the plug-in PCB...or can be omitted from PCB and connected directly to balanced outputs.

I've got nice music now from my SDTRANS so i can design more relaxed now.
Next step is to get rid of UFL connectors in I2S interface to BIII ( source of my debugging headaches ) and sync master clock to BIII as well using one of IAN's adapters.

 

[Bunpei]

Strange interpretation...

The strangeness is very natural as they are doing something extreme.

Your explanation is completely correct and might be very useful for those who are not familiar with ES9018 architecture as far as you look at its display-level functionality.

However, let's think about the internal mechanism behind the display-level.
In the DPLL_NUM register sets, they latch a normalized 32 bit integer value based on counting of BCLK pulses for a certain period. Behind the register sets, there must be a live counter that is always counting up and to be reset to zero periodically.

 

[RayCtech]

The strangeness is very natural as they are doing something extreme.

Your explanation is completely correct and might be very useful for those who are not familiar with ES9018 architecture as far as you look at its display-level functionality.

However, let's think about the internal mechanism behind the display-level.
In the DPLL_NUM register sets, they latch a normalized 32 bit integer value based on counting of BCLK pulses for a certain period. Behind the register sets, there must be a live counter that is always counting up and to be reset to zero periodically.

You better explain what this "extreme" is

My setup uses synchronous clocking and I can run with master clock = bit clock and up to 90/98MHz clocks - with jitter reduction turned off completely etc.. The DPLL_NUM register do not in any case act as a counter (it is not counting bit clocks from zero to a max value and then resets and starts again like your explanation) - it contains a value that are constant (may vary a little bit up and a little bit down depending on the source used) with the master clock, bit clock, word clock and the filters etc. that are active when playing.
Thus by checking what input (PCM, DSD or SPDIF (by reading registers)) and what filters (by reading registers) that are enabled it is just to divide the DPLL_NUM register value accordingly and get the result you want.

If synchronous clocking are used these calculations can be complicated due to it then can be several alternative clock frequencies in use. Both several different master clock and bit clock and word clock frequencies.

However it is possible to manually override (by register programming) the DPLL_LOCK and force the Jitter eliminator to re-lock to the signal.
From what little you have explained of the "extreme" use I would expect that there are an error in the programming code and the re-locks that happens every 95-96 seconds are caused by this.
Or it may be that your friends can avoid this by simply shut down the Jitter Eliminator that are not needed with synchronous clocking and high quality clocks and when synchronous re-clocking are performed on data, bit and word clocks..

 

[Bunpei]

We discussed a possible interpretation of the magic period 95 or 96 seconds.

Under the condition;
fs=44.1 kHz, MCLK=11.2896 MHz, BCLK=2.8224 MHz, I2S, OSF=ON
DPLL counter value is 0x3FFFFFFF ( a quarter of 0xFFFFFFFF).
The counter counts BCLK.

0x3FFFFFFF / 44100 / 64 / 4 = approximately 95
( Oversampling ratio is 4 ? )

The DPLL counter might be reset when the counted value reaches to 0x3FFFFFFF and the resetting action may cause the unlock event.

A better interpretation has hit me.

DPLL_NUM is a 32 bit unsigned integer value. There should be two 32 bit counters. The first counter counts MCLK pulses and the second counter counts BCLK x 4 pulses (on this case) . At the timing of the first counter reaches 2^32-1=0xFFFFFFFF, the counts on the second counter is latched to DPLL_NUM.
The interval of the first counter reaches to 0xFFFFFFFF is;
2^32 / 44100 / 256 / 4 = 95.1 seconds

 

[RayCtech]

A better interpretation has hit me.

DPLL_NUM is a 32 bit unsigned integer value. There should be two 32 bit counters. The first counter counts MCLK pulses and the second counter counts BCLK x 4 pulses (on this case) . At the timing of the first counter reaches 2^32-1=0xFFFFFFFF, the counts on the second counter is latched to DPLL_NUM.
The interval of the first counter reaches to 0xFFFFFFFF is;
2^32 / 44100 / 256 / 4 = 95.1 seconds

Are you adapting the internals of the DAC chip to fit with your 95 second error ?
If you check the data sheet there are at least one ingredient in your calculation you have overseen

 

[Shinja]

A better interpretation has hit me.

DPLL_NUM is a 32 bit unsigned integer value. There should be two 32 bit counters. The first counter counts MCLK pulses and the second counter counts BCLK x 4 pulses (on this case) . At the timing of the first counter reaches 2^32-1=0xFFFFFFFF, the counts on the second counter is latched to DPLL_NUM.
The interval of the first counter reaches to 0xFFFFFFFF is;
2^32 / 44100 / 256 / 4 = 95.1 seconds

Bunpei

It seems MCLK counter is overflowing rather than reach 0xffffffff, at the reset phenom.
the 2^32 count of MCLK seems have something meaning,
but is there any information of the update timing of dpll_num?
Is it your assumption?

I have read the ESS's patent US7436333, which seems to relate ES9018's ASRC.
there is a counter which is counting BCLK pulse but no MCLK counter.
It seems the number of the counter is the source of dpll_num.
It is consistent with your dpll num when the latter accumulator overflows every 16 cycle of MCLK.

 

[RayCtech]

It seems MCLK counter is overflowing rather than reach 0xffffffff, at the reset phenom.
the 2^32 count of MCLK seems have something meaning,
but is there any information of the update timing of dpll_num?
Is it your assumption?

I have read the ESS's patent US7436333, which seems to relate ES9018's ASRC.
there is a counter which is counting BCLK pulse but no MCLK counter.
It seems the number of the counter is the source of dpll_num.
It is consistent with your dpll num when the latter accumulator overflows every 16 cycle of MCLK.

Shinja,

As I have disabled the ASRC and the jitter removal circuit when playing PCM I have not seen the 95 second problem. Try this settings.

However when playing DSD128 with the register setup that are optimized for PCM (a little difference in register settings needed) I get a lock problem after 48 - 49 seconds. And the left and right channel loose lock with maybe a seconds interval in time (dual mono so separate chips for left and right).

I think the problem I see with DSD128 (with the synchronous clocking and 22M master clock rates) are the same problem you see with PCM simply due to DSD mode for some reason must have the ASRC enabled by register programming even if the ASRC are not supposed to be used in DSD mode...

The easy way to get rid of the DSD lock problem are to use 90/98M clocks and different register settings.

If this "Clock Mystery" of the ES9018 are consistent then you should loose lock at half the time in your setup if you plays 88.2k with the same master clock. Or at 190 seconds if you play 44.1k and doubles the master clock. Or 95 seconds with 11M, 190 seconds with 22M, 380 seconds with 45M and 760 seconds with 90.3168MHz master clocks.

I have checked this "lock / Clock Mystery" problem with ESS, but have not received any response...

When I first discovered this issue I made my own DSD DAC and verified that it was the ES9018 chip and nothing else that causes this.

However I think this "Clock Mystery" are a issue when the ES9018 are not used as intended and not according to the data sheets and thus are mostly a tweakers issue....

 

[RayCtech]

It seems MCLK counter is overflowing rather than reach 0xffffffff, at the reset phenom.
the 2^32 count of MCLK seems have something meaning,
but is there any information of the update timing of dpll_num?
Is it your assumption?

I have read the ESS's patent US7436333, which seems to relate ES9018's ASRC.
there is a counter which is counting BCLK pulse but no MCLK counter.
It seems the number of the counter is the source of dpll_num.
It is consistent with your dpll num when the latter accumulator overflows every 16 cycle of MCLK.

There are two setups that may avoid the "Clock Mystery" issue when playing in PCM mode.
1. With the oversampling filter and jitter removal enabled you use a 512FS master clock => 44.1k - 22.5792MHz.
2. With the oversampling filter disabled you use a 64FS master clock - the bit clock as master clock - 44.1k - 2.8224MHz.

I only did a quick calculation based on some previous tests that gave these indications. I will test both PCM and DSD one of the first days and verify. However if these calculations are correct - then DSD256 will be the highest "error" free DSD mode and DSD512 will be flawed.

Shinja, can you test the two setups and check if the "Clock Mystery / 95 second reset" issue are gone or just changes ?

 

[Bunpei]

Hi, Raymond and Shinja,

Thank you very much for your posts.
As I am a system engineer, I'd like to compile information in a structured manner as "glt" always does.

1. My question
Is there any reasonable interpretation for periodical unlock events of 95 second interval?

2. Conditions on which the periodical unlock event appears
A. I2S 32 bit input of PCM 44.1 kHz/16 bit sources
B. OSF=ON
C. DPLL Bandwidth = No Bandwidth
( I refered this "NO BANDWIDTH" setting as "extreme".)

You better explain what this "extreme" is

D. Jitter reduction = ON or OFF (this does not affect)
E. External synchronous MCLK input, 11.2896 Mz (4 x BCLK)

3. Observations
A. Four independent people experienced the similar periodical unlock events of regular interval approximately 95 seconds in their independent environments.
B. One person applied PCM 88.2 kHz/24 bit source with 22.5792 MHz (4 x BCLK). In this case, the period was approximately 47-48 seconds.

4. My guess
The period fits the time that a 32 bit integer counter reaches to a full count by counting 4 x MCLK. There is neither formal nor informal information on this. This is just my guess.

but is there any information of the update timing of dpll_num? Is it your assumption?

-------------------------------------------------------
My new comments;

1. DPLL functionality for an asynchronous sampling rate conversion and "Jitter Reduction" functionality should not be understood in a mixed-up manner .
- A DPLL can't be disabled while jitter reduction can be disabled
- A DPLL is used to determine a timing of DA conversion output (in a output sampling clock time domain) while jitter reduction is an interpolation of signal value (in a signal intensity domain)

2. DPLL Bandwidth parameter might be related to RCLK counting interval.
When you select the lower bandwidth parameter, the longer time period is used for the RCLK counting for getting an averaged value.
DPLL Bandwidth parameter defines a frequency of PLL adjustment action as well as a tolerance limit for counting value variability.

There are two setups that may avoid the "Clock Mystery" issue when playing in PCM mode.
1. With the oversampling filter and jitter removal enabled you use a 512FS master clock => 44.1k - 22.5792MHz.
2. With the oversampling filter disabled you use a 64FS master clock - the bit clock as master clock - 44.1k - 2.8224MHz.

"Sky" in Japan tells such an empirical finding that we tend to obtain a lock state easily at NO BANDWIDTH setting when we use MCLK of 4 x RCLK (= 256 fs).
People in Japan shows no interest on OSF=OFF setting.

 

[wktk_smile]

After reading RayCtech's answers related to dual mono es9008,

http://www.diyaudio.com/forums/digi...-reference-dac-8-channel-216.html#post3388411

If you can re-arrange the outputs easily you could also run the two channels in opposite phase and sum the re-arranged outputs - this way you get a balanced digital path and reduce both the power rail and gnd noises...

I decided to try similar experiments with dual mono es9018 + hifiduino + some quick, dirty code tweaks.

Ray's recommended setting surely affected the sonics and that's surprising, because previously I thought this doesn't affect the sonics so much.

I don't know it's technically better/worse, but I 'm sure at least it cause neither strange distortion nor audible noise, and
This sort of experiments are fun and worth trying for people who check this thread with much interest.

I appreciate RayCtech's sharing his findings and knowledge



Then, here I have a question.

Dustin reffered to the 7-bit quantizer mode in the early post of this thread.

http://www.diyaudio.com/forums/digi...re-reference-dac-8-channel-4.html#post1429418

Doing this, prevents the need to send the same data in all the inputs since now a certain DAC channel is routed into 2 DAC oututs. (man im already regretting this, ohwell, here goes) The DAC is normally a 6 bit quantizer, with the DACx being the summation of the 6 bits, and DAxB being the summation of the inverse of the SAME 6 bits. This is the best all round perfoamnce mode, and this is why the datasheet say reg15 needs to be set to 8'b00000000. Setting this regsiter to 8'b01010101, which by the way was the mode I thought would work best base on my prototype design, and thats why its the default configuarion, the DAC becomes a 7 bit quantizer (thus reducing out of band noise) and I simple divinded up the 7 bit number coming from the qunatizer into 2 6 bit numbers and inverted 1 of them. Then I send off these new 2 6 bit numbers which the differnce is mathematically identical to the origanal 7 bit number from the quantizer and shipped them off to the analog section.

7bit number can be divided into two 6-bits, and this 6-bit pair is dac1 and dac3 (or dac5 and dac7) at left side of the dac IC,
under "true differential mode".

under "pseudo differential mode", 6-bit pair is DACX and DACXb, and DACXb is inverted.


Then, under "pseudo differential mode", Can we consider paralelled DACX and "in-phased DACXb" - in other words, DACXb is the same polarity
with DACX - is identical to half (+ or - ) of the true differential 7bit?

If identical, I think we should be able to emulate "9-bit true differential" output in dual mono mode, with rearranging output as Raymond suggested.

 

[Shinja]

Hi

RayCtech,
Thank you for sharing your experimental result.
It is really helpful information.

Please teach me bit more.

The easy way to get rid of the DSD lock problem are to use 90/98M clocks and different register settings.

Due to some resister settings are ignored when playing DSD,
you changed DPLL bandwidth to except "no bandwidth" ,don't you ?

Actually, I do not own ES9018 yet, but ES9008 buffalo which is not completed even years passed...
So I am sorry I can't test your result.
Although I am planning to buy a board.

Bunpei,

You tryed jitter reduction = off but still have unlock problem?
If so it may disagree with RayCtech's result...

I thought DPLL and jitter reduction function are integrated because the US7436333 looks to have both function in one circuit;

- A DPLL is used to determine a timing of DA conversion output (in a output sampling clock time domain) while jitter reduction is an interpolation of signal value (in a signal intensity domain)

Patent US7436333 - Asynchronous sample rate converter - Google Patents
There is no discription about DPLL bandwidth or filtering something, so I don't have confidence to my understanding.

 

[wktk_smile]

Some visualization with output arrangements I had experimented.

I had been using ESS default output scheme (and input remapping is necessary as I use Buffalo II dac) in mono mode for a long time.
Like this.

Left side (of the dac IC)　　　　　　　　　Right side

dac 1,3,5,7　　　　(+)----------------(+) dac 2,4,6,8
dac 1b,3b,5b,7b　(-)-----------------(-) dac 2b,4b,6b,8b



And Here's the output arrangement I have tried.

dac 1,3,5,7　　　　(+)　　　　　　　　　(-) dac 2,4,6,8
　　　　　　　　　　　|　　　　　　　　　　|
dac 1b,3b,5b,7b　(+)　　　　　　　　　　(-) dac 2b,4b,6b,8b

 

[Bunpei]

... RayCtech,
...
Due to some register settings are ignored when playing DSD,
you changed DPLL bandwidth to except "no bandwidth" ,don't you ?

... Bunpei,
...
You tryed jitter reduction = off but still have unlock problem?
If so it may disagree with RayCtech's result...

I thought DPLL and jitter reduction function are integrated because the US7436333 looks to have both function in one circuit;

Patent US7436333 - Asynchronous sample rate converter - Google Patents
There is no discription about DPLL bandwidth or filtering something, so I don't have confidence to my understanding.

Hi, Shinja!

Please remember that Raymond has never said in his posts that he tried "No Bandwidth" setting in his environment.

Not in my experiment, but in Sky's experiment, he said that "Jitter Reduction" =ON or OFF had nothing to do with the occurences of 95 second unlock events.

I appreciated your information on US7436333. The patent was new to me. I just read US7330138 before where no description on DPLL was shown.
The US7436333 describes a DPLL mechanism. However, you can't think it is directly applied in ES9018 architecture. For example, in the patent, the DPLL is described in the context for creating 64*44.1 kHz digital pulses locked to 44.1 kHz input instead of using an analog PLL. In the case of I2S or DSD input for ES9018, the BCLK is already available.