Thank you very much for your information.
Do you mean that the AKD12 product in your web page has an ordering option to select ES9018 chip instead of standard ES9012 chip or a user must replace original ES9012 chip on the board with his own ES9018 chip at his risk?
After the DAC chip is successfully replaced, does the user need to bridge L and R outputs by himself?
no, you cannot use 9018 on the standard 9012 board, he is just saying that the controller board that makes this possible is compatible with 9018. acko has a 9018 8 channel dac on the books due shortly, but i might ask why if you are using it for 2 channel operation? the internal makeup of the 9012 is the same as the 9018 and you can already use the dac as you describe; just use the 9012, i have both dacs and i can tell you imo the 9012 is at least as accomplished as the 9018. my ackodac with 9012 sounds much better to these ears and not by a small amount, though i have spent more effort on the build in all aspects
Last edited:
Has somebody tried controlling a Buffalo II DAC with AKC12?
I guess it should work just fine so as it comes down to the setting of 9018 registers over I2C.
Implementing dual mono mode with all 8 channels in parallel
9018 requires another board version to combine outputs to 2CH (extra trackwork) I have done such boards for those who have already have 9018 chips and wanted to use them instead PN:AKD18S (not listed). 9012 otherwise.
9018 requires another board version to combine outputs to 2CH (extra trackwork) I have done such boards for those who have already have 9018 chips and wanted to use them instead PN:AKD18S (not listed). 9012 otherwise.
Yes, outputs are on opposite sides and is best combined off-board for mono
A Japanese friend of mine reported the combination in his blog page. He said he had no problem.
Hi, acko,
Thank you very much for your reply.
I understand that there is neither kit nor commercial product available that implements dual mono mode of ES9018 DAC chip with all 8 channels in parallel by default pattern wiring.
Bunpei
DPLL Bandwidth parameter "the lowest" for I2S
Does anyone succeed in applying "the lowest" DPLL Bandwidth parameter for I2S input with OSF/On, Jitter-eliminator/On?
One of SDTrans192 Rev. 3.0 users, sunacchi in Japan, reported his recent achievement in his blog page (In Japanese).
BaffaloII‚ÉArduino‚ð•t‚¯‚Ä‚Ý‚½: Ama Ama Audio Visual
His DACs are dual mono configured Buffalo IIs ( with Fidelix 96MHz oscillator) and controlled by Arduino.
Even for 352.8 kHz/24 plays, he said he succeeded in maintaining locked state for a long period(but not perfect). I think his special enhancements on power supplies of both SDTrans and Buffalo IIs resulted in "the lowest" setting.
Does anyone succeed in applying "the lowest" DPLL Bandwidth parameter for I2S input with OSF/On, Jitter-eliminator/On?
One of SDTrans192 Rev. 3.0 users, sunacchi in Japan, reported his recent achievement in his blog page (In Japanese).
BaffaloII‚ÉArduino‚ð•t‚¯‚Ä‚Ý‚½: Ama Ama Audio Visual
His DACs are dual mono configured Buffalo IIs ( with Fidelix 96MHz oscillator) and controlled by Arduino.
Even for 352.8 kHz/24 plays, he said he succeeded in maintaining locked state for a long period(but not perfect). I think his special enhancements on power supplies of both SDTrans and Buffalo IIs resulted in "the lowest" setting.
Bumpei, nice link. I think it is because of cleaner power, although the author does adjust the quantizer registers (I don't know if that has anything to do with it)
But my favorite part is when he says in another post:
"Recent scary, and debit cards at the end of each time something arrives, the bride's face is increasingly steep." -translated by Google...
But my favorite part is when he says in another post:
"Recent scary, and debit cards at the end of each time something arrives, the bride's face is increasingly steep." -translated by Google...
Does anyone succeed in applying "the lowest" DPLL Bandwidth parameter for I2S input with OSF/On, Jitter-eliminator/On?
One of SDTrans192 Rev. 3.0 users, sunacchi in Japan, reported his recent achievement in his blog page (In Japanese).
BaffaloII‚ÉArduino‚ð•t‚¯‚Ä‚Ý‚½: Ama Ama Audio Visual
His DACs are dual mono configured Buffalo IIs ( with Fidelix 96MHz oscillator) and controlled by Arduino.
Even for 352.8 kHz/24 plays, he said he succeeded in maintaining locked state for a long period(but not perfect). I think his special enhancements on power supplies of both SDTrans and Buffalo IIs resulted in "the lowest" setting.
What and what for he placed on top of solid caps in amp-cpm4 image?
sunacchi retracted his previous results and posted his correction.
He had found that his previous results had been collected on OSF/Off mode.
ŠF‚³‚ñ�A�\‚µ–ó‚*‚è‚Ü‚¹‚ñ‚Å‚µ‚½: Ama Ama Audio Visual(In Japanese)
With OSF/On mode his updated achievements are;
ES9018 DAC: Twisted Pear Audio, Buffalo II boards of dual mono mode with Fidelix 96 MHz oscillators
Transport: heavily tweaked Chiaki's SDTrans192 Rev. 3.0 board
PCM 44.1Khz：MEDIUM
PCM 88.2Khz：MEDIUM_H
PCM 96Khz：HIGH
PCM 192Khz：HIGH
PCM 352.8KHz：Use best DPLL Settings
Transport: heavily tweaked ElecrArt's USB Dual Audio board
DSD 2.8M MEDIUM_L
DSD 5.6M MEDIUM
Bunpei's latest results are;
ES9018 DAC: Twisted Pear Audio, Buffalo II single board with NDK 100 MHz, ultra low phase-noise OCXO, 9525D
Transport: "Copper foil & Polyphenylene Sulfide(PPS) Film Capacitor" added SDTrans192 Rev. 3.0 board
PCM 44.1 kHz：THE LOWEST
PCM 48 kHz：LOW
PCM 96 kHz：MEDIUM
PCM 176.4 kHz: HIGH
PCM 192 kHz：HIGH
PCM 352.8 kHz：THE HIGHEST
And this is the end of the DPLL mystery
I was much pleased with your appreciation. My study wad inspired with your series of valuable and intensive blog articles on the topic of DPLL Bandwidth parameter setting.
I still have two mysteries on the parameter setting.
1. Why DPLL Bandwidth parameter setting value is still effective even if I set;
"Bypass and stop JITTER REDUCTION"
Is the narrow meaning of "JITTER REDUCTION" not the same of "employing DPLL"?
2. What does "Use the best DPLL bandwidth settings" mean?
Some people say "the best DPLL bandwidth settings" is equivalent to a fixed "medium" or "medium-low" setting. If it is so, I guess it is of "Multiply the DPLL BANDWIDTH setting by 128".
DSD mode processing on ES9018
An ES9018-based DAC, CAPRICE by Fidelix is bringing up a mood of reappraisal of DSD sounds in Japan. The DAC offers an option of raw DSD signal input and I heard that at least two famous audio reviewers in Japan purchased CAPRICE with the option.
According to Functional Block Diagram in Product Brief document of ES9018, it seems for me that DSD signals are converted into PCM at the stage prior to oversampling in ES9018. This approach seems quite different from such DAC chips, TI DSD1702 or DSD1608 that has a dedicated DSD filtering signal path.
How do you feel about this point?
An ES9018-based DAC, CAPRICE by Fidelix is bringing up a mood of reappraisal of DSD sounds in Japan. The DAC offers an option of raw DSD signal input and I heard that at least two famous audio reviewers in Japan purchased CAPRICE with the option.
According to Functional Block Diagram in Product Brief document of ES9018, it seems for me that DSD signals are converted into PCM at the stage prior to oversampling in ES9018. This approach seems quite different from such DAC chips, TI DSD1702 or DSD1608 that has a dedicated DSD filtering signal path.
How do you feel about this point?
1- There is some info here: http://www.diyaudio.com/forums/digi...e-reference-dac-8-channel-50.html#post1490639 I think this only works if you provide your own master clock into the chip (replacing the oscillator)
2- Here is my guess: I think "best" means the next level after "highest" based on the fact that there are no hiccups even when the DAC is cold.
Chiaki succeeded in playing 384 kHz/32 bit high resolution sources using the combination of his SDTrans384 and ES9018 based DAC with the setting of DPLL bandwidth parameter = "the lowest" and OSF mode="ON" without any unlock events.
In order to achieve this, he redesigned logic circuits in FPGA where I2S signals were generated based on clocks given from external oscillators and PCM data read from SD card. Bunpei reproduced the experiment and obtained a very good sonic improvement.
Who can make a guess on his method?
In order to achieve this, he redesigned logic circuits in FPGA where I2S signals were generated based on clocks given from external oscillators and PCM data read from SD card. Bunpei reproduced the experiment and obtained a very good sonic improvement.
Who can make a guess on his method?
Bumpei,
What do you mean for us to guess at?
This is not surprising. I have been able to do the same via XMOS for quite a while now. I don't know why using FPGA would be any different.
I have also experimented with generating the bit clock and word clock by dividing the master clock. Which worked well, but requires two master clocks.
What do you mean for us to guess at?
This is not surprising. I have been able to do the same via XMOS for quite a while now. I don't know why using FPGA would be any different.
I have also experimented with generating the bit clock and word clock by dividing the master clock. Which worked well, but requires two master clocks.