Sorry, I am at a loss, I want to try external clock, but how do I omit VDD_XO? Which one is it? Can someone clarify please?
Alex
Ok, thanks miero. So if I want an external clock from my source, I connect the clock to EXT_MCK and remove VDD_XO, am I correct? My plan is use RP3 B+ with a Kali Reclocker and use its MClk into the dac EXT_MCK. Will this work? or am I missing something.
Alex
Ale,
I'm not Miero (Hi DUDE!), but that should work ok. I've done that exact same thing with an ES9018K2M-based RPi DAC card and expect to be doing it with an ES9028Q2M-based card this week.
In the next few weeks I plan to try Sync Mode with my Buff-IIIPro DACs from an Ian FIFO Dual Clock board.
Russ / Brian, do you have any ETA on officially releasing firmware to support full Sync mode? OR better to buy a programmer and some chips and have at it?
Greg in Mississippi
I'm not Miero (Hi DUDE!), but that should work ok. I've done that exact same thing with an ES9018K2M-based RPi DAC card and expect to be doing it with an ES9028Q2M-based card this week.
In the next few weeks I plan to try Sync Mode with my Buff-IIIPro DACs from an Ian FIFO Dual Clock board.
Russ / Brian, do you have any ETA on officially releasing firmware to support full Sync mode? OR better to buy a programmer and some chips and have at it?
Greg in Mississippi
yep...
I would be interested in sync mode pre-programmed chips myself... too busy to figure out programming and no Windoz machine here usually, although i did finally get my Amanero working with 1099c for native DSD 256 on linux.
I would be interested in sync mode pre-programmed chips myself... too busy to figure out programming and no Windoz machine here usually, although i did finally get my Amanero working with 1099c for native DSD 256 on linux.
Happy 4th Of July. Since the topic of sync mode firmware has come up, I wanted to report an issue I have with the current beta release. Everything works well and sounds great with the exception of DS64 and 128. These both play back with a lot of unstructured noise. It's subjectively half as noisy at 128 as it is at 64 and the noise is completely gone with DSD256 and no issues up to DSD512x48. All PCM rates are fine up to 384. I've tried multiple configurations of SW1 and SW2 and three different firmware chips with no change in this behavior. Perhaps I'm missing something since no one else seems to have this problem?
This would be natural if you are using 45/49 (or perhaps 22/24) clocks for syncmode. This beta firmware (Puresync by Russ) is based on the definition of MCLK as 128fs, a particular function provided by ESS9028/9038 chips in which no DPLL is required, as Russ stated previously.
So, for DSD64 (assuming that the source is deriving from a 44.1k family), the MCLK should be 128 x 44.1 =5.6MHz and for DSD128 it should be 11.2MHz. If the MCLK is inconsistent with these values, it will result in producing noise. You might want to see my previous post.
Regards,
This morning I checked the SQ of DSD64 and DSD128 by changing the setting of HQ player and confirmed that a background noise similar to white or pink noise is emerging in each case when heard from B3SE9038pro in 128s syncmode using 45/49 clocks on the Cronus. A similar noisy sound was also audible in MPD playing DSD64 on BBB in the same setting, though the SQ of DSD128 appeared acceptable.
The result is quite consistent with what pawlus has claimed. So the multiply does matter. It is difficult to understand what this 128fs in Sabre DACs is actually doing without data sheet but some sources including a screaming one, are saying that the MCLK in syncmode is defined by the mutiply of 128 x fs (1, 2). Also the second source says that the DAC has a function of frequency divider when the real clock frequency does not meet this requirement. In this meaning the ratio may also matter.
* The source 2 is written in Japanese, requiring an app for translation.
As I usually listen to music in DSD512, the results above are not a serious issue but I'd like to make it clear that my result suggests that there is a possibility of noise formation when the actual MCLK does not match the required 128fs in syncmode.
BTW, it will be quite helpful if Russ can disclose his system including music player and PC (including OS) used for his successful, noiseless DSD64 play in 45/49 clock syncmode.
The 9028/9038 support a "MCLK = XIN divided by 2 or 4 or 8" mode, set by firmware. That might take care of the 128fs thing (if it is indeed a problem.. I haven't done any relevant testing).
But in order to select the correct divider, you will need to know what sort of DSD you are feeding the DAC.
But in order to select the correct divider, you will need to know what sort of DSD you are feeding the DAC.
Interesting guys. I can confirm that I am experiencing the same symptoms with DSD 64 and 128 with the dual mono syncmode firmware (see post here). I am using SOTM-200 streamer and outputting to HQPlayer. Due to a limitation with my current USB card (SONORE USB Interface) I am only able to upsample to DSD64 or DSD 128 as a maximum using DoP.
PCM plays fine up to 384k.
PCM plays fine up to 384k.
Thank you for this info but I just wonder whether or not this function is implemented into the current beta firmware. At least I could not find a part related to this function in the source files...
I am not seeing that at all - I get zero noise or hash from any of PCM 44.1khz to 384khz or DSD64,128,256.
I am not re-sampling. I am playing DSD/PCM files directly from my Cronus/Hermes-BBB
I have also had no "hash" issues with DSD64/128 via Amanero streamed directly on my mac.
If it were about the exact clock frequency being 128fs - you would see the same issue with PCM.
I am not re-sampling. I am playing DSD/PCM files directly from my Cronus/Hermes-BBB
I have also had no "hash" issues with DSD64/128 via Amanero streamed directly on my mac.
If it were about the exact clock frequency being 128fs - you would see the same issue with PCM.