Thanks for clearing that up Barrows, I have not got a es901x of my own, yet. Only know what I do from reading the datasheet and what has been said on these forums.
For Fs of 44.1/48kHz with the 22.593/24.576MHz oscillators should still be 'fast enough'. Right? It is admittedly not ideal. But for the purposes of just getting synch mode to work, it should be sufficient. To get it to work optimally, I agree faster clocks are likely needed.
As a generally comment, directed at no one in this thread, just an observation - I think with these ES901x DACs it is important to distinguish between:
1. sync mode functioning;
2. getting the best possible clocks for sync mode and;
3. OSF bypass.
Each is a separate issue, so while all are generally considered at the same time they should be each addressed individually.
Pepe, with the knowledge we now have it is obvious to me that the only thing Lucian needs to consider is the faster clocks for the WaveIO, the rest is configured on the DAC side and not reliant on his design choices.
Drew, OSF-bypass can be configured I believe to defeat that. I think Ian has done some experiments with that, would be worth a search in his thread(s). I think qusp has tried it at some point also and from what he's said, when you lose signal lock you can get some pretty nasty transients. Since he uses an entirely DC coupled analogue stage he was keen to resolve some other issues before experimenting further with that. I think normally with OSF-bypass you would be adding your own oversampling in a preceding stage, which depending on your source device may or may-not be optimal, especially considering the MCLK frequency you require.
Cheers,
Chris
For Fs of 44.1/48kHz with the 22.593/24.576MHz oscillators should still be 'fast enough'. Right? It is admittedly not ideal. But for the purposes of just getting synch mode to work, it should be sufficient. To get it to work optimally, I agree faster clocks are likely needed.
As a generally comment, directed at no one in this thread, just an observation - I think with these ES901x DACs it is important to distinguish between:
1. sync mode functioning;
2. getting the best possible clocks for sync mode and;
3. OSF bypass.
Each is a separate issue, so while all are generally considered at the same time they should be each addressed individually.
Pepe, with the knowledge we now have it is obvious to me that the only thing Lucian needs to consider is the faster clocks for the WaveIO, the rest is configured on the DAC side and not reliant on his design choices.
Drew, OSF-bypass can be configured I believe to defeat that. I think Ian has done some experiments with that, would be worth a search in his thread(s). I think qusp has tried it at some point also and from what he's said, when you lose signal lock you can get some pretty nasty transients. Since he uses an entirely DC coupled analogue stage he was keen to resolve some other issues before experimenting further with that. I think normally with OSF-bypass you would be adding your own oversampling in a preceding stage, which depending on your source device may or may-not be optimal, especially considering the MCLK frequency you require.
Cheers,
Chris
Last edited:
Well, as Barrow states above: if 22.x and 24.x will work for 192 khz then I'll try to use 45.x and 46.x oscillators for the final retiming stage (Flip-flops). The down side is that the MCLK from these oscillators will be divided with 2 by one of the Flip-Flops from the final retiming stage so, in the end, there will only be 22.x and 24.x signals available to user...
If I want to do it "properly" I guess I'll have to start looking for 180.6336 Mhz and 196.608 Mhz oscillators. I wonder if these such things exists...
Noted, thank you! Well, maybe a list could make our life easier as the mailing approach has almost blocked my DIYaudio account. So here it is:
1. hirez69
2. analog_sa
3. m.massimo
4. ozlegend
5. luisbock
6. vitalica
7. palmito
8. gabanyayaya
9. danny_66
It's simply a list, no hidden chargers, but also no promises! For anyone willing to add to it: please feel free to do so!
Kind regards,
L
Last edited:
I would hesitate to say that 22.593/24.576 is fast enough. its theoretically fast enough for 44.1khz with normal operation, barrows has forgotten about, or is neglecting the oversampling filter. I really dont see the point of OSF bypass with ESS unless you are running a superior external oversampling filter, which would mean the clock is fed in at 8x F/S anyway, just running an ESS NOS.... no comprende, if you want to bypass all that stuff, get another dac, particularly if you are not making perfect connections.
it doesnt have to be OSF bypass to get the 'transients' which seems far too mild a word for what I experienced in sync mode. which is either caused by running low 22.573 clock speed (remember the ESS dev board never ran or recommended anything lower than 40MHz and is not just a dac, there may be internal functions that simply will not function correctly at lower speeds) or caused by the ackodac onboard clock still being in place and disabled, rather than actually being removed. Another possible culprit, for those that are familiar with ESS operation and glt's blog, the dac often experiences some unlock events, particularly when warming up, or when there is a sudden transient or back EMF on the power supply rails. This plus sync mode is a bad combination.
see I use the ESS digital volume too, so glitches are DC coupled and full volume, not good. it happens because the onboard clock has a mute pin, if the dac loses signal lock it will pull the XO mute pin as well as muting its own outputs.
this is all rather harmless if it goes to plan, just a momentary pause and the lock LED blinks off and on again, but when running sync mode with an external clock, the dac has no 2 way communication with the clock, any ability (normally) to mute the clock, nor prior knowledge that something is wrong until it has gone FULLY pearshaped. if anyone has ever heard this noise, or perhaps heard it when a digital TV set top box or something like that drops the sample live and chokes on the corrupted and looped segment in memory until you yank the power? let me tell you, this plus headphones or a digital crossover? .....
so basically, be warned, everything must be in order before running sync mode
oh yeah I forgot.....be warned, everything must be in order before running sync mode
it doesnt have to be OSF bypass to get the 'transients' which seems far too mild a word for what I experienced in sync mode. which is either caused by running low 22.573 clock speed (remember the ESS dev board never ran or recommended anything lower than 40MHz and is not just a dac, there may be internal functions that simply will not function correctly at lower speeds) or caused by the ackodac onboard clock still being in place and disabled, rather than actually being removed. Another possible culprit, for those that are familiar with ESS operation and glt's blog, the dac often experiences some unlock events, particularly when warming up, or when there is a sudden transient or back EMF on the power supply rails. This plus sync mode is a bad combination.
see I use the ESS digital volume too, so glitches are DC coupled and full volume, not good. it happens because the onboard clock has a mute pin, if the dac loses signal lock it will pull the XO mute pin as well as muting its own outputs.
this is all rather harmless if it goes to plan, just a momentary pause and the lock LED blinks off and on again, but when running sync mode with an external clock, the dac has no 2 way communication with the clock, any ability (normally) to mute the clock, nor prior knowledge that something is wrong until it has gone FULLY pearshaped. if anyone has ever heard this noise, or perhaps heard it when a digital TV set top box or something like that drops the sample live and chokes on the corrupted and looped segment in memory until you yank the power? let me tell you, this plus headphones or a digital crossover? .....
so basically, be warned, everything must be in order before running sync mode
oh yeah I forgot.....be warned, everything must be in order before running sync mode
Last edited:
Thank you guys for all that good comments and food for thought, I learn more than one good thing a day with you guys .... I am a bit scared at the moment with the sync mode though .... 
Having said that, I also sign up for the daughter board Lucian !
1. hirez69
2. analog_sa
3. m.massimo
4. ozlegend
5. luisbock
6. vitalica
7. palmito
8. gabanyayaya
9. danny_66
10. shoom
11. kp93300
12. lindamar
Cheers,
Pepe
Having said that, I also sign up for the daughter board Lucian !
1. hirez69
2. analog_sa
3. m.massimo
4. ozlegend
5. luisbock
6. vitalica
7. palmito
8. gabanyayaya
9. danny_66
10. shoom
11. kp93300
12. lindamar
Cheers,
Pepe
Lorien
May be I too simplified my question and get equivalent answer. Sorry.
Let me clear it up: what I need is I2S bus with MCLK 192fs, that makes 36.864MHz for 48/96/192kHz thread and 33.8688MHz for 44.1/88.2/176.4 thread. As far as I understand, it can be made with 36.864MHz and 33.8688MHz generators instead of 24.576MHz/22.5792Mhz used in Your board. Is such replacement possible theoretically? Can XMOS chip work with such frequencies? And if it can be possible theoretically, can it be made practically?
I do not know how famous it is but thank you for your kind words
1. The simple answer is: no
May be I too simplified my question and get equivalent answer. Sorry.
Let me clear it up: what I need is I2S bus with MCLK 192fs, that makes 36.864MHz for 48/96/192kHz thread and 33.8688MHz for 44.1/88.2/176.4 thread. As far as I understand, it can be made with 36.864MHz and 33.8688MHz generators instead of 24.576MHz/22.5792Mhz used in Your board. Is such replacement possible theoretically? Can XMOS chip work with such frequencies? And if it can be possible theoretically, can it be made practically?
Last edited by a moderator:
Gents,
I concur, learn something every time I'm here.
barrows, hochopeper and qusp, thanks for the explanations re the OSF etc, I'm used to a TDA1541 dac so this is a play toy and that is the reference. Haven't actually turned it in anger yet, time is my least common commodity, which makes my current hobby info and parts collection......
Thanks again fellas,
Drew.
I concur, learn something every time I'm here.
barrows, hochopeper and qusp, thanks for the explanations re the OSF etc, I'm used to a TDA1541 dac so this is a play toy and that is the reference. Haven't actually turned it in anger yet, time is my least common commodity, which makes my current hobby info and parts collection......
Thanks again fellas,
Drew.
bare in mind this is with fifo and a crystek clock too, so its not a question of jitter. We get those same unlock events in async mode too, it just presents itself as a blink and pause. ive also had it with spdif and direct to the dac. it seems to be unrelated to incoming jitter, but more some sort of glitch with the DPLL feedback, which is still on at all times, just in sync mode it effectively hasnt got anything to do.
I get less when altering the DPLL bandwidth to medium, but it doesnt disappear entirely, it still seems to take maybe 30mins to 1hr to 'warm up'. if there is some way to maintain the full functionality of the clock and all its pins when running sync external clock, then we might/should be able to keep it so we just get that blink/mute, but until then I think its all fubared already by the time the dac knows. i've had the unlocks on my buffalo II as well so its not specific to the ackodac.
I get less when altering the DPLL bandwidth to medium, but it doesnt disappear entirely, it still seems to take maybe 30mins to 1hr to 'warm up'. if there is some way to maintain the full functionality of the clock and all its pins when running sync external clock, then we might/should be able to keep it so we just get that blink/mute, but until then I think its all fubared already by the time the dac knows. i've had the unlocks on my buffalo II as well so its not specific to the ackodac.
I would like to know if in the future DSD is implemented if the daughter board will work with it or only with I2S
1. hirez69
2. analog_sa
3. m.massimo
4. ozlegend
5. luisbock
6. vitalica
7. palmito
8. gabanyayaya
9. danny_66
10. shoom
11. kp93300
12. lindamar
13. merlin el mago
Could you please give me a cost estimation.
1. hirez69
2. analog_sa
3. m.massimo
4. ozlegend
5. luisbock
6. vitalica
7. palmito
8. gabanyayaya
9. danny_66
10. shoom
11. kp93300
12. lindamar
13. merlin el mago
Could you please give me a cost estimation.
Well...
you may be right, but: I am running a Buffalo II in sync mode (with the onboard Crystek removed), using the 9018 volume control, from an XMOS based interface, with 22.xxx and 24.xxx oscillators. It defintely works at all rates up to 24/192, I was scared to try with 352.8/384 (I have the software for the interface to work at those rates). I get no problems with losing lock, clicks, pops, or any unusual behaviour at all, ever, at any rate up to 24/192. I am running Crystek CCHD series clocks on the interface, and considered modding it to use the 2x faster CCHDs (I have code for that as well), but have decided to wait for TPA/Russ to introduce his USB interface. I do not see why you think clock speeds above 45 MHz would be called for, as the ESS data sheet clearly says >192 fs, so 192*192 so >36.864 MHz should be totally adequate for rates up to 192. Russ has stated he is planning on using 4x normal clocks rates (~90 MHz) for his interface, as he wishes to support sync mode for sample rates to 352.8/384: this may be nice for those who like to apply OSFs in the server/computer.
Lorien: If you want to provide good performance with ESS 9018 users, running sync clocking, and for rates up to 192, I think you are going to need to provide masterclock at 45.xxx and 49.xxx to be compliant with the ESS data sheet numbers. Mine is "working" at lower masterclcok rates, but I suspect that performance of the OSF is not ideal.
you may be right, but: I am running a Buffalo II in sync mode (with the onboard Crystek removed), using the 9018 volume control, from an XMOS based interface, with 22.xxx and 24.xxx oscillators. It defintely works at all rates up to 24/192, I was scared to try with 352.8/384 (I have the software for the interface to work at those rates). I get no problems with losing lock, clicks, pops, or any unusual behaviour at all, ever, at any rate up to 24/192. I am running Crystek CCHD series clocks on the interface, and considered modding it to use the 2x faster CCHDs (I have code for that as well), but have decided to wait for TPA/Russ to introduce his USB interface. I do not see why you think clock speeds above 45 MHz would be called for, as the ESS data sheet clearly says >192 fs, so 192*192 so >36.864 MHz should be totally adequate for rates up to 192. Russ has stated he is planning on using 4x normal clocks rates (~90 MHz) for his interface, as he wishes to support sync mode for sample rates to 352.8/384: this may be nice for those who like to apply OSFs in the server/computer.
Lorien: If you want to provide good performance with ESS 9018 users, running sync clocking, and for rates up to 192, I think you are going to need to provide masterclock at 45.xxx and 49.xxx to be compliant with the ESS data sheet numbers. Mine is "working" at lower masterclcok rates, but I suspect that performance of the OSF is not ideal.
my bad, barrows, Lorien has misquoted you? see below, or maybe you tried these at 128x FS and they 'worked'? but its not the correct setup and thats what I was commenting on. not sure why you are focusing on the 192x FS, there isnt much by way of a decent clock at those speeds, its hard enough finding them at 256x FS at audio frequencies. they exist at 36.x, but very rare.
I know its in the datasheet* (kinda vaguely, see below), but the realistic minimum is 256. I dont get any clicks or pops, just the very well documented silent unlocks during warmup, as well as a completely new level of noise occasionally if running sync mode. its only happened like 3 times, out of the blue and the last time was enough to make me want to nail down the source before ever doing it again given the way my gear is set up.
* I dont know where this 192x FS thing comes in tbh, even though I have indeed seen it in the DS, because the ASRC (which is on even if using sync mode without OSF bypass) is MCLK/64 and in OS bypass it expects 8x oversampled input and with OS enabled it performs 8 x OS, making MCLK 256x FS called for, whether you bypass or not, it will work with lower multiples maybe, but it goes against all other recommendations and specifications.
also notice it calls for >192x FS, so read literally it asks for greater than 192x, not equal to or greater, greater. so its an odd spec.
bare in mind I never use the automatic DPLL 'best' setting they use on buffalo, I set the registers manually and when running sync mode with fifo and uber low jitter Mclk, i'm shooting for lowest, as it should be. I get fewer unlocks (not all result in the glitch, just fraction of a second silence) when I relax the DPLL settings, but it never goes away completely, but after warm up its pretty solid.
the problem is thoroughly documented here and there are many many reports here on the forum. my guess is you are using the default buffalo start up setting, am I correct? if not yours would seem to be almost an isolated case. bare in mind at the time of writing glt wasnt aware that spdif 'lowest' is a more relaxed DPLL setting than lowest on pcm
so seems for mclk we are on the same page, 45.xx/49.xx for 176.4/192 or 90.316/98.304 for 352.8/384.
now I do want to explore this further to run down the source of the problem, but as with glt and bunpei ive found even with what is essentially perfect i2s (in my case from the fifo) with direct w.fl/u.fl connection to the dac and battery power on the fifo Mclk; its still there with lowest DPLL.
the only variables left are too low speed mclk till I get fifo back from FW upgrade, or the fact the output stage/buffer/caps etc of the onboard clock in parallel with the external MCK from fifo is screwing with the shape of the clock. or simply that ESS was being 'optimistic' with having the lowest DPLL setting at all.
I know its in the datasheet* (kinda vaguely, see below), but the realistic minimum is 256. I dont get any clicks or pops, just the very well documented silent unlocks during warmup, as well as a completely new level of noise occasionally if running sync mode. its only happened like 3 times, out of the blue and the last time was enough to make me want to nail down the source before ever doing it again given the way my gear is set up.
* I dont know where this 192x FS thing comes in tbh, even though I have indeed seen it in the DS, because the ASRC (which is on even if using sync mode without OSF bypass) is MCLK/64 and in OS bypass it expects 8x oversampled input and with OS enabled it performs 8 x OS, making MCLK 256x FS called for, whether you bypass or not, it will work with lower multiples maybe, but it goes against all other recommendations and specifications.
also notice it calls for >192x FS, so read literally it asks for greater than 192x, not equal to or greater, greater. so its an odd spec.
bare in mind I never use the automatic DPLL 'best' setting they use on buffalo, I set the registers manually and when running sync mode with fifo and uber low jitter Mclk, i'm shooting for lowest, as it should be. I get fewer unlocks (not all result in the glitch, just fraction of a second silence) when I relax the DPLL settings, but it never goes away completely, but after warm up its pretty solid.
the problem is thoroughly documented here and there are many many reports here on the forum. my guess is you are using the default buffalo start up setting, am I correct? if not yours would seem to be almost an isolated case. bare in mind at the time of writing glt wasnt aware that spdif 'lowest' is a more relaxed DPLL setting than lowest on pcm
so seems for mclk we are on the same page, 45.xx/49.xx for 176.4/192 or 90.316/98.304 for 352.8/384.
now I do want to explore this further to run down the source of the problem, but as with glt and bunpei ive found even with what is essentially perfect i2s (in my case from the fifo) with direct w.fl/u.fl connection to the dac and battery power on the fifo Mclk; its still there with lowest DPLL.
the only variables left are too low speed mclk till I get fifo back from FW upgrade, or the fact the output stage/buffer/caps etc of the onboard clock in parallel with the external MCK from fifo is screwing with the shape of the clock. or simply that ESS was being 'optimistic' with having the lowest DPLL setting at all.
Lorien said:Well, as Barrow states above: if 22.x and 24.x will work for 192 khz then I'll try to use 45.x and 46.x oscillators for the final retiming stage (Flip-flops). The down side is that the MCLK from these oscillators will be divided with 2 by one of the Flip-Flops from the final retiming stage so, in the end, there will only be 22.x and 24.x signals available to user...
If I want to do it "properly" I guess I'll have to start looking for 180.6336 Mhz and 196.608 Mhz oscillators. I wonder if these such things exists...
enough on that though, i'll let people do their own experiments, but it needed to be said.
Even with top shelf i2s sources with very well built and implemented ESS dacs, both DIY and commercial this is a longstanding documented problem, so is definitely not the norm to not have the problem, the result could kill your tweeters or headphones, so tread carefully is all i'm saying
Even with top shelf i2s sources with very well built and implemented ESS dacs, both DIY and commercial this is a longstanding documented problem, so is definitely not the norm to not have the problem, the result could kill your tweeters or headphones, so tread carefully is all i'm saying
well...
qusp: I know about the problem to which you refer, but isn't this problem strictly for those people using a non-synchronous masterclock? At least, that is my understanding.
BTW, Dustin has stated, for the record, that the ASRC (not OSF) and DPLL are disabled automatically when one provides a synchronous masterclock feed (for those who may not understand this, he is referring to a masterclock synchronous with the bit clock: as when one provides the masterclock and bit clock from the I2S feed of the Wave IO, or other similar interface). I can confirm that the DPLL settings do nothing (that is, one can run the most narrow settings, with the highest sample rate files) when running synchronously, whereas, when I was running a Buffalo with the onboard masterclock, at either 80 MHz or 100 MHz, the DPLL settings did have to be tuned to achieve a lock to higher sample rates.
As best as I understand it, when running synchronously, the DPLL does "nothing" and the the ESS just lets any jitter through, so one is relying strictly on the the performance of the USB interface and its oscillators as far as jitter is concerned.
As for the clock rates, the ESS DS says >192 fs, as we both noted. For sample rates up to 192 kHz then, per the DS, one would want to have masterclock rates >192*192, or >36.864 MHz, hence my advice to Lorien that 45.xxx and 49.xxx masterclock output from the Wave IO should be totally adequate for those who want to run the ESS 9018 synchronously up to 192 kHz rates. And, those oscillators are available from Crystek as CCHD series parts.
I know it is advised to provide faster clock if one is running asynchronously, but in my experience this is not necessary if one is running the DAC synchronously, hence, I even have total success running much slower clocks. Running synchronously, the ESS 9018 always locks perfectly in my set up, I cannot recall even a single dropped sample, ever (pop/click); I doubt that I am just lucky, as I play quite a bit of 24/176.4 and 24/192 music.
qusp: I know about the problem to which you refer, but isn't this problem strictly for those people using a non-synchronous masterclock? At least, that is my understanding.
BTW, Dustin has stated, for the record, that the ASRC (not OSF) and DPLL are disabled automatically when one provides a synchronous masterclock feed (for those who may not understand this, he is referring to a masterclock synchronous with the bit clock: as when one provides the masterclock and bit clock from the I2S feed of the Wave IO, or other similar interface). I can confirm that the DPLL settings do nothing (that is, one can run the most narrow settings, with the highest sample rate files) when running synchronously, whereas, when I was running a Buffalo with the onboard masterclock, at either 80 MHz or 100 MHz, the DPLL settings did have to be tuned to achieve a lock to higher sample rates.
As best as I understand it, when running synchronously, the DPLL does "nothing" and the the ESS just lets any jitter through, so one is relying strictly on the the performance of the USB interface and its oscillators as far as jitter is concerned.
As for the clock rates, the ESS DS says >192 fs, as we both noted. For sample rates up to 192 kHz then, per the DS, one would want to have masterclock rates >192*192, or >36.864 MHz, hence my advice to Lorien that 45.xxx and 49.xxx masterclock output from the Wave IO should be totally adequate for those who want to run the ESS 9018 synchronously up to 192 kHz rates. And, those oscillators are available from Crystek as CCHD series parts.
I know it is advised to provide faster clock if one is running asynchronously, but in my experience this is not necessary if one is running the DAC synchronously, hence, I even have total success running much slower clocks. Running synchronously, the ESS 9018 always locks perfectly in my set up, I cannot recall even a single dropped sample, ever (pop/click); I doubt that I am just lucky, as I play quite a bit of 24/176.4 and 24/192 music.
no he hasnt stated they are disabled, he has stated, just as I did, that they are effectively disabled, as they are basically idle because they have so little to do, but they are not off. there is a distinction there, there is no way to switch it off, you can only supply it with a set of conditions that means it should be doing nothing.
no in practical real world application it would seem it isnt when trying for lowest DPLL BW settings with less than ideal clock speeds/layout etc, even when supplying what is effectively a perfect and synchronous <0.5ps or better master clock connected with impedance controlled u.fl. something, in my otherwise fully functional build causes this in sync mode, or has caused and I dont know what specifically caused it, very frustrating.
nobody else has reported the loud glitches I've had specifically and ive had the same sound from my buff II and ackodac, different sources, different scenarios, different builds, so thats why i'm still ruling out the last few variables, they may not even be related to the async mode unlocks, ive just deduced they are. it may be something unrelated like a transient on ground from the fridge or something.
the DPLL is still active in some manner, its a setting made independently in the registers. have you manually set lowest, or are you still on best? I understand it 'best' may even be a dynamic setting, that automatically selects the lowest it can get a stable lock with the sample rate in use.
the default for BII, ackodac and likely BIII (aka 'best') is medium or medium-low from memory. thats the default register setting (so its what you are using if you havent set otherwise) whether you have synchronous clock or not, what matters is how synchronous BCK and MCK are, if the cable lengths are different the DPLL will still do some minimal work. I'm splitting hairs I know, but I made this distinction and chose my words carefully.
Ian is having better success now with the more recent setups (I can only run 22.579/24.576 CCHD957 on my fifo till the FW is updated, I have the last beta release board, maybe thats a factor too) so this gives me some hope, the Si570 board will help here, i'm not willing to buy the NDKs at current pricing. I already have the cchd957 in 45.xx/49.xx too, but without the FW update the fifo will not do 1024x FS for 44.1. i'll grab the si570 board as son as its available.
also looking at ackos new master clock board, looks nice, but $$$
did you remove, or just disable your clock? theres still a few things to rule out, but the warning still holds, if running sync mode from an external clock a significant hiccup on power supply can create very scary noises, so scary that I just havent been willing to test further till I have the solutions at hand.
i've had more success with titan USB in the past and i'll test out the combo384 amanero in sync mode without fifo in the next few days too.