Thanks peufeu for your willing to confirm this aspect. Also enough predictable that the I2C interface need a clock to work properly.
This supposition/confirmation it shows well that in between the Oppo products based on ES9018, I use to experiment with, the last one HA-1, is more evolute, using I2C interface to control the power sequences and the system. The BD players do not have such functionality...
This supposition/confirmation it shows well that in between the Oppo products based on ES9018, I use to experiment with, the last one HA-1, is more evolute, using I2C interface to control the power sequences and the system. The BD players do not have such functionality...
Recently I have (for the first time for me...) connected together the ES9018 outputs in 4+4 configuration (stereo). So, the outputs dacB and dac from one side of the chip, for a stereo channel, and on another side accordingly, for the second stereo channel.
I have used the chip`s datasheet for this task. Quite surprised to experience that the right stereo channel was completely silent, even though I could see the HF DAC characteristic noise on both both stereo channels, but audio signal out only from left stereo channel.
I found out finally that the DAC outputs DAC2/DAC2B, have to be connected in opposite position than the datasheet shows. Switching in between these outputs connected together to the rest on right chip`s side, everything was working well.
Is this a known (issue)? I`m a little bit confused about if it have to be like this...If is so, then it may be something wrong with the datasheet of ES9018... It may be something wrong with my DAC chip (production fault)?
I was supposing that the Right/Left sides of the chip it have to be symmetrical when about outputs designation, at least as the datasheet it shows...
Somebody please with some clarifications?
I have used the chip`s datasheet for this task. Quite surprised to experience that the right stereo channel was completely silent, even though I could see the HF DAC characteristic noise on both both stereo channels, but audio signal out only from left stereo channel.
I found out finally that the DAC outputs DAC2/DAC2B, have to be connected in opposite position than the datasheet shows. Switching in between these outputs connected together to the rest on right chip`s side, everything was working well.
Is this a known (issue)? I`m a little bit confused about if it have to be like this...If is so, then it may be something wrong with the datasheet of ES9018... It may be something wrong with my DAC chip (production fault)?
I was supposing that the Right/Left sides of the chip it have to be symmetrical when about outputs designation, at least as the datasheet it shows...
Somebody please with some clarifications?
My primary interest in seeking a high sound quality on ES9018 is regarding a clocking scheme.
The best combinations & conditions for me so far are;
1. Providing a synchronous master clock by low phase noise OCXOs with frequencies, 45.1584/49.1520MHz.
2. Setting "DPLL Bandwidth" as "No Bandwidth"
However, this is only applicable to PCM 176.4 kHz/DSD256. Even for such sources, I suffer a periodic unlock event of 24 second intervals.
My current challenge is to eliminate the periodic unlock events.
I appreciate any advices on this point.
The best combinations & conditions for me so far are;
1. Providing a synchronous master clock by low phase noise OCXOs with frequencies, 45.1584/49.1520MHz.
2. Setting "DPLL Bandwidth" as "No Bandwidth"
However, this is only applicable to PCM 176.4 kHz/DSD256. Even for such sources, I suffer a periodic unlock event of 24 second intervals.
My current challenge is to eliminate the periodic unlock events.
I appreciate any advices on this point.
Hi Bunpei,
My findings are the same as yours. I must confess that I didn't try "No Bandwidth" setting but I'll do it asap.
Regarding your problem, do you have a setup with inverted MCLK?
Regards,
Mihai
Hello Bunpie,
Sorry for the stupid question, does the above problem occur with a synchrounous USB input.
Regards
Arthur
Hi, Arthur!
The unlock event is nothing to with "synchronous/asynchronous" audio data transfer over USB path.
Bunpei
Hi, Mihai!
Not me but one of my friends tried an inverted MCLK and he found no positive effect on the problem.
Bunpei
In synchronous mode I don't get any unlocks at 44.1k. I'll test 88.2 and 176.4
Since my board has only one clock I use asynchronous mode for 48k based rates. I get unlocks at 192k after sample rate change, then after a while it works nicely. I guess the DPLL needs some time to adapt to the new sample rate. Since the 192k based rates bitclock is generated by the microcontroller's PLL, which is not too clean, I haven't researched the problem to much... I'll check this when I make the final board which will have two proper clocks.
What exactly is inverted mclk mode ?
Since my board has only one clock I use asynchronous mode for 48k based rates. I get unlocks at 192k after sample rate change, then after a while it works nicely. I guess the DPLL needs some time to adapt to the new sample rate. Since the 192k based rates bitclock is generated by the microcontroller's PLL, which is not too clean, I haven't researched the problem to much... I'll check this when I make the final board which will have two proper clocks.
What exactly is inverted mclk mode ?
May I ask you that you have set "DPLL Bandwidth=No Bandwidth"?
Please refer the application note published by ESS Tech.
http://www.esstech.com/PDF/Application_Note_Component_Selection_and_PCB_Layout.pdf
Yes, also with "enable jitter reduction" deactivated, makes no difference, no unlocks.
> Please refer the application note published by ESS Tech.
It doesn't say a lot... does this mean the input I2S should switch state on the falling edge of MCLK ?
Do you have a BIII DAC or other implementation of Sabre DAC? how do you control internal DAC registers?
As far as I know, BIII with standard firmware doesn't support "No Bandwidth" DPLL setting
Regarding the last question, you are right, the I2S signal should change on the falling edge of the MCLK clock
Last edited:
My prototype.
I open web interface and click on button. This web interface is served by a python script which sends commands via USB to the Cortex-M4 which handles the usb audio stuff. It issues I2C commands to the DAC.
Hmmmmmh, I can't try that yet, because my prototype has only one clock (45.158M) and it is connected only to the ES9018 and the ES9102. So I use the ES9102 in master mode and it generates BCK,LRCK, and the microcontroller is slaved to that. For 48k multiples I use the ugly microcontroller PLL (and ESS in asynchronous mode). So it exercises all modes. In the proper version I will have two clocks forwarded to the uC for proper I2S generation, and support synchronous and asynchronous modes for all frequencies. I am doing the routing now, and it is a bitch.
OK ! I didn't know about DPLL Mode Control overriding the settings.
So, in synchronous mode, 44100 :
I set "DPLL Mode Control" to "Allow all settings".
"Multiply the DPLL BANDWIDTH setting by 128" (R25) is disabled.
Now "No bandwidth" produces unlock and the sound stops. The other settings work.
Wether "Enable Jitter Reduction (R10)" is enabled or disabled makes no difference (still no lock) ; playing with dpll_lock_rst (Force DPLL relock) (R17) has no effect.
So... well, I guess it should not be set to "no bandwidth" then. It is a bit strange that this setting produces unlocks when the DPLL is disabled via "Enable Jitter Reduction (R10)"...
So, in synchronous mode, 44100 :
I set "DPLL Mode Control" to "Allow all settings".
"Multiply the DPLL BANDWIDTH setting by 128" (R25) is disabled.
Now "No bandwidth" produces unlock and the sound stops. The other settings work.
Wether "Enable Jitter Reduction (R10)" is enabled or disabled makes no difference (still no lock) ; playing with dpll_lock_rst (Force DPLL relock) (R17) has no effect.
So... well, I guess it should not be set to "no bandwidth" then. It is a bit strange that this setting produces unlocks when the DPLL is disabled via "Enable Jitter Reduction (R10)"...