ESS9018 - try new, try more... - Page 2 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 13th September 2011, 05:44 PM   #11
diyAudio Member
 
Russ White's Avatar
 
Join Date: Jan 2005
Location: Nashville, TN, USA
Send a message via Yahoo to Russ White
Let me make sure I was clear, I actually meant that the DPLL is not still active. It is precisely inactive. This is not just a theory I confirmed it with Dustin.
__________________
Less pulp more juice Twisted Pear Audio.
  Reply With Quote
Old 13th September 2011, 06:20 PM   #12
Coris is offline Coris  Norway
diyAudio Member
 
Join Date: May 2009
Location: Norway
Quote:
Originally Posted by barrows View Post
As an aside, but on the same topic, have you tried synchronous clocking? This is going to be my next experiment with the Buffalo II. I have an async USB interface which can provide the masterclock. My plan is to upgrade the oscillators on the USB interface to Crystek CCHD-957s when they become available, and at that point, try synchronous clocking the ESS 9018 from the MC feed over I2S. I am just curious to see what the DAC will sound like without the ASRC, and "virtually" disabling the DPLL.
In my past experience, I have preferred other DACs (TI 1798, Wolfson 8741) without any ASRC, provided that the data feed is low jitter to start with.
Hi Barrows
For answer your question: no. Not yet... It is a field of experiments this too, but in the same time I agree with the idea that is not quite easy task a synchronous clock distribution with low jitter and phase noise. At these high clock frequencies it is a big challenge to keep it clean enough for all the stages involved... But anyway, without trying, no steps forward.
  Reply With Quote
Old 16th September 2011, 11:49 PM   #13
Bunpei is online now Bunpei  Japan
diyAudio Member
 
Join Date: Aug 2008
Quote:
Originally Posted by barrows View Post
As an aside, but on the same topic, have you tried synchronous clocking? This is going to be my next experiment with the Buffalo II. I have an async USB interface which can provide the masterclock. My plan is to upgrade the oscillators on the USB interface to Crystek CCHD-957s when they become available, and at that point, try synchronous clocking the ESS 9018 from the MC feed over I2S. I am just curious to see what the DAC will sound like without the ASRC, and "virtually" disabling the DPLL.
In my past experience, I have preferred other DACs (TI 1798, Wolfson 8741) without any ASRC, provided that the data feed is low jitter to start with.
Dear Coris and barrows,

I assume Coris have removed the original on-board Crystek Oscillator from his BIII DAC board. I'd like to recommend both of you try a synchronous Master Clocking scheme rather than Coris's asynchronous over-clocking approach if you have a good I2S sources.
In my case, I used to adopt 96 or 100 MHz oscillators so that I could play 352.8 kHz/24 bit PCM (DXD) sound sources on an oversampling mode before. After experiencing a superior result of synchronous master clocking and NOS approach for DXD play, now I prefer such lower master clock frequencies as 22.5792 MHz and 24.576 MHz. Even for DXD, the low frequency master clock is effective on NOS mode.

Bunpei
  Reply With Quote
Old 17th September 2011, 12:53 AM   #14
diyAudio Member
 
Russ White's Avatar
 
Join Date: Jan 2005
Location: Nashville, TN, USA
Send a message via Yahoo to Russ White
Bunpei,

He was actually not using a BIII yet.

but I am inclined to agree that a synchronous approach is far more likely to yield high fidelity than simply providing the fastest possible clock.

Cheers!
Russ
__________________
Less pulp more juice Twisted Pear Audio.
  Reply With Quote
Old 17th September 2011, 08:37 AM   #15
Coris is offline Coris  Norway
diyAudio Member
 
Join Date: May 2009
Location: Norway
Quote:
Originally Posted by Bunpei View Post
Dear Coris and barrows,

I assume Coris have removed the original on-board Crystek Oscillator from his BIII DAC board. I'd like to recommend both of you try a synchronous Master Clocking scheme rather than Coris's asynchronous over-clocking approach if you have a good I2S sources.
In my case, I used to adopt 96 or 100 MHz oscillators so that I could play 352.8 kHz/24 bit PCM (DXD) sound sources on an oversampling mode before. After experiencing a superior result of synchronous master clocking and NOS approach for DXD play, now I prefer such lower master clock frequencies as 22.5792 MHz and 24.576 MHz. Even for DXD, the low frequency master clock is effective on NOS mode.

Bunpei
Hi Bunpei

Your approach is interesting. I think I will give it a try (I don`t know when, because is so much to do it...).

For be better understood, I will explain here a little more:
Initially, before get my Buffalo I`ve decided that I will use an oven controlled oscillator (100Mhz) and remove it that original Crystek which come with Buffalo 3. So I bought a such much more precise oscillator for this purpose. In meanwhile I started those experiments with a higher clock frequencies, based first on that fact that I couldn't find at the moment another 100Mhz oscillator to upgrade my Oppo BDP95. So I used that ESS9018 platform in my experiments, waiting for the ordered Buffalo 3. When I got it, I just removed the oscillator at once following the above described idea.
Anyway I will give it a try to Baffalo with the oven controlled clock (100Mhz), and I will try some other solution too. It is more convenient to use Buffalo kit for this purposes, than use a quite bad designed and very big (40/16cm) PCB (Oppo), where is difficult to measure something... Buffalo DAC still be my first priority, but the BDP95 have to function well too... At last this player it has a very good transport, accessible DSD, SATA interface, good picture (after upgrade...), and so on... Only problem with this player is that the dedicated audio stage and it`s power supply looks like have been designed by some first years students...

Using higher (over-clocking) frequencies to clock ESS9018, come in conflict with the chip producer stated parameters. It is risky from chip functional point of view, and not enough analysed at this moment. So, I will not state that this is the best and recommended way to use this ESS9018 DAC. But in the same time it works. The perceptual improvement is a fact, and not a placebo as TPA try to suggest. By the way, I can say the same that for TPA stuff their placebo is well based on right using of the DAC datasheet, orthodox measurements, and so on... Not to forget the commercial/business interests involved in this "placebo" too...
And more something else: there is a fact that ESS9018 accept very high clock frequencies. I just think that is not only by chance that ESS9018 was made in this way. Around this chip was before enough secrecy in revealing it`s functional details. I`m personally quite sceptic that the designer him self have came out with all about this chip, even though much infos was delivered to the TPA. ESS intend to came out with few as possible informations about the product, but in the same time they have to sell it too. So, they only used TPA and this forum as a marketing and advertise platform for their new (at that time) DAC chip. This is not a critic directed against somebody, but just an observation which leaded at last to my conclusion that not all the infos about this chip are out there yet... But anyway...

I`ve tried in my experiments on this BDP95 platform first with an 106 Mhz standard oscillator (50ppm), then the Buffalos 100 Mhz Crystek, then 125Mhz, 133,3 Mhz. I have to say that I`ve registered an perceptual improvement from 106 Mhz to 100 Mhz Crystek. In Crystek favour. Then an improvement from 100 Mhz Crystek to 125 and 133,3 Mhz (those lasts also standard oscillators 20/50ppm). The improvement is quite evident in detailed sound stage, dynamics, and lower end of the audio spectre (bass). For example, in using 133,3 Mhz, an symphony orchestra (CD 44,1 sample recording) just punch in in the lower end of the spectre as it does in real concert environment... One just feel the sound pressure as it does in real... Actually, the real meaning for I`ve came out here with this experiments is to try find a reasonable explanation to those facts...

I still do think that a higher clock frequency lead to more resolution in the resulting analogue signal/finally sound, but as Bunpei state, it could be very possible that opposite works too. So, it still only to give it try, and not only reject everything else because is not in conformity with the producer datasheet...

Last edited by Coris; 17th September 2011 at 09:04 AM.
  Reply With Quote
Old 17th September 2011, 01:53 PM   #16
diyAudio Member
 
Join Date: Jul 2010
Default Thanks...

Russ and Bunpei. I am going to try synchronous clocking, but it may be a little while before I am ready to do so. I want to make sure I have really great clocks on my sourece first, otherwise this will not be a fair evaluation.
It is nice to see that the B-III board is already designed to easily accept an external masterclock feed as well.
  Reply With Quote
Old 18th September 2011, 09:08 AM   #17
qusp is offline qusp  Australia
diyAudio Member
 
qusp's Avatar
 
Join Date: Oct 2009
Location: Brisbane, Australia
@ barrows, not as easily as the ackodac, but still yes easier than before. there is already a master syncronous clock module for the ackodac as of a couple of weeks ago. connects by 6ghz micro bnc

sorry Coris, i have to wonder at this terminology you have invented 'perceptual facts' its a contradiction in terms, you cannot have a factual perception, perception is by definition subjective
  Reply With Quote
Old 18th September 2011, 11:59 AM   #18
Coris is offline Coris  Norway
diyAudio Member
 
Join Date: May 2009
Location: Norway
Quote:
Originally Posted by qusp View Post
@ barrows, not as easily as the ackodac, but still yes easier than before. there is already a master syncronous clock module for the ackodac as of a couple of weeks ago. connects by 6ghz micro bnc

sorry Coris, i have to wonder at this terminology you have invented 'perceptual facts' its a contradiction in terms, you cannot have a factual perception, perception is by definition subjective
Sorry, but I have to say that English is not my every day language. So it is very possible that sometimes what I want to say/write, not all the time can be very accurate as I intend to say/write.

Anyway my used "terminology" in previous post is not exactly an (my) invention... If it is, then maybe I have to think to patent it...

If you touch something hot, you notice that is hot. It is a very real fact about that thing is hot. Your (human) perception about that thing is hot is (by definition...) a perceptual fact... Appreciating the temperature of that hot thing with the finger it could be very well (perceptual) subjective. The temperature appreciated with your finger is not a fact!. That because it was invented the thermometer... Perceptual facts are facts at last... As you see that outside is day light and is not dark night, is a perceptual fact too... If you see a picture, it is a perceptual fact that that picture exist. If you like what you see in the picture, or not is something else and it is very sure that this is your subjective perception and not a fact...
I think that you (almost) have to (wander to) agree at last with this facts... Your choice anyway...

Last edited by Coris; 18th September 2011 at 12:05 PM.
  Reply With Quote
Old 26th September 2011, 03:47 PM   #19
Bunpei is online now Bunpei  Japan
diyAudio Member
 
Join Date: Aug 2008
Quote:
Originally Posted by Coris View Post
I still do think that a higher clock frequency lead to more resolution in the resulting analogue signal/finally sound,
Thank you very much for your long explanation.

However, I could not catch which input formats do you always target nor what sampling frequencies, neither.
I think a reasonable clocking approach may depend on those prerequisites.
If you can't ignore S/PDIF input, you can't adopt the low frequency "synchronous master clocking" approach that I told.
If you think the use of over-sampling filter at the play of high sampling frequency sources is essential, your approach is one possible solution.

I'd like to propose one method to prove the effectiveness of your approach. Why don't you read DPLL counter values from ES9018 register at your best clock setting and compare them to those obtained in usual 80 or 100 MHz master clock configuration?
If the counter value shows relatively less fluctuations, the the result might mean your approach is effective enough.

By the way, under the synchronous master clocking, my partner, Chiaki showed that "No bandwidth" for DPLL bandwidth parameter was possible even for the play of 384 kHz/32 bit PCM sources with OSF=ON condition.

Last edited by Bunpei; 26th September 2011 at 03:56 PM.
  Reply With Quote
Old 27th September 2011, 10:24 PM   #20
Coris is offline Coris  Norway
diyAudio Member
 
Join Date: May 2009
Location: Norway
Quote:
Originally Posted by Bunpei View Post
Thank you very much for your long explanation.

However, I could not catch which input formats do you always target nor what sampling frequencies, neither.
I think a reasonable clocking approach may depend on those prerequisites.
If you can't ignore S/PDIF input, you can't adopt the low frequency "synchronous master clocking" approach that I told.
If you think the use of over-sampling filter at the play of high sampling frequency sources is essential, your approach is one possible solution.

I'd like to propose one method to prove the effectiveness of your approach. Why don't you read DPLL counter values from ES9018 register at your best clock setting and compare them to those obtained in usual 80 or 100 MHz master clock configuration?
If the counter value shows relatively less fluctuations, the the result might mean your approach is effective enough.

By the way, under the synchronous master clocking, my partner, Chiaki showed that "No bandwidth" for DPLL bandwidth parameter was possible even for the play of 384 kHz/32 bit PCM sources with OSF=ON condition.

Hi
Thanks for the replay. The input formats are the usual ones at this time. PCM and DSD. I use files in FLAC and PCM/DSD from CDs (44/16 and SACD). This is happen on my Oppo player BDP95. I just start now to put together the Buffalo 3 I`ve got it in the last time...
My experiments are made on the BDP95 platform. The samplings frequencies are 192/24-32 bit...

Thanks for your suggestion about the method to control the effectiveness of over-clocking. It is a very good idea. I will do it for sure. BTW, I think are many ways to read the DPLL counter values from ES9018 register. What is in your opinion a simplest/effective/fastest one?
I have to say that now my ES9018 have an 125Mhz clock. And is working very well (perceptual point of view). With 133.3 Mhz I had some noises in the silence moments of the recordings. I`m waiting for a 128Mhz clock for test with it. I have in mind to test with lower clock frequencies (your approach).

Now I have a question for you and others: have somebody tried to bypass/decoupling ES9018 with 1000F (ceramic/tantalum) on the AVCC pins (L/R)?

I will not say how it sounds... Maybe somebody else will get curious to try it, and will come here with comments about this experience...

Last edited by Coris; 27th September 2011 at 10:32 PM.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off



New To Site? Need Help?

All times are GMT. The time now is 02:14 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2