This is why when running sync clock without the "pure sync" firmware it is often best to open up the DPLL - so that it basically does nothing but freewheel. With a jittery async source this would be bad - because it would let the jitter through - with a clean source already synced to the master clock it has no ill effects.
Goto, I do not really agree with regarding running sync clocking with the ESS DACs: if the masterclock and bit clock arrive at the DAC in sync, then the DPLL does nothing: that is, the DPLL is active, but it does not have to do anything, and makes no changes. Now if the masterclcok and bit clock arrive at the DAC slightly out of sync, then the DPLL will make a slight adjustment. But this mode is entirely different from running a 100 MHz masterclock which has no relation to the bit clock at all, then the DPLL is fully active all the time.
I hear significant differences in both 9018 and 9038 chips running with a synchronous clock vs async as well.
But: back to the issues at hand. So frustrating here that with async DAC operation Amanero firmware 1099c runs well with native DSD 256 on linux, and sync DAC mode does not lock at all. Masterclock lines are checked and fine, so I am at a loss at to what could be the problem. OE firmware on the Amanero ran fine in sync mode as well, of course limited to DSD 128 via DoP, as it does not work for native DSD on linux.
Again the question: is anyone successful at running Amanero/Cronus, with Amanero firmware v: 1099c, Slave for CPLD, in sync mode (masterclock from Cronus to DAC) and 45.1584 masterclock? Or does anyone have any ideas why this might not work?
I hear significant differences in both 9018 and 9038 chips running with a synchronous clock vs async as well.
But: back to the issues at hand. So frustrating here that with async DAC operation Amanero firmware 1099c runs well with native DSD 256 on linux, and sync DAC mode does not lock at all. Masterclock lines are checked and fine, so I am at a loss at to what could be the problem. OE firmware on the Amanero ran fine in sync mode as well, of course limited to DSD 128 via DoP, as it does not work for native DSD on linux.
Again the question: is anyone successful at running Amanero/Cronus, with Amanero firmware v: 1099c, Slave for CPLD, in sync mode (masterclock from Cronus to DAC) and 45.1584 masterclock? Or does anyone have any ideas why this might not work?
Hi...
Brian, I went ahead and mounted both XOs on the Cronus to make sure the single clock approach was not causing any issues. I figured this was a simple thing to do to eliminate variables.
Brian, I went ahead and mounted both XOs on the Cronus to make sure the single clock approach was not causing any issues. I figured this was a simple thing to do to eliminate variables.
Update...
OK, as a check, I switched out the 45.1584 (Crystek/Rhea) with 22.5792 I had around, and then set the divided to 1:1. Voila, Sync mode working (also with just single clock and a u.fl jumping the two clock positions).
With this clock rate I only get to DSD 128, and PCM 24/96 so I guess I need to try a new 45.1584 XO...
Before I go this route, of getting the new clock and thinking that is the problem, is there anything which could be damaged on the Cronus board to explain this problem? I would think the divider has to be OK, as the Amanero has operated fine all the time, perhaps the mux? Maybe the clock signal was clean enough for Amanero to operate but not for the 9038 to lock on it.
Still seems weird, But my guess is the next step is trying a new 45.1584 XO.
OK, as a check, I switched out the 45.1584 (Crystek/Rhea) with 22.5792 I had around, and then set the divided to 1:1. Voila, Sync mode working (also with just single clock and a u.fl jumping the two clock positions).
With this clock rate I only get to DSD 128, and PCM 24/96 so I guess I need to try a new 45.1584 XO...
Before I go this route, of getting the new clock and thinking that is the problem, is there anything which could be damaged on the Cronus board to explain this problem? I would think the divider has to be OK, as the Amanero has operated fine all the time, perhaps the mux? Maybe the clock signal was clean enough for Amanero to operate but not for the 9038 to lock on it.
Still seems weird, But my guess is the next step is trying a new 45.1584 XO.
I think this is a good choice. I've been checking the feasibility of the syncmode (Puresync by Russ) firmware for sharing the clocks on the remote Cronus connected to either Herms-BBB or Hermes-Amanero using Teleporter. The MCLK at the receiver end of TP is directly connected to the clock input of the DAC (a 9028 pro in this case). The results were quite successful. There was no problems in playing DSD512 from the remote Hermes-BBB (via HQ player) as expected.
What was more remarkable was that the Hermes-Amanero with 22/24 clocks on the Cronus could play DSD256 (DoP) through both of HQ player and Audirvana Plus running on My Macbook with this syncmode beta firmware despite remotely connected via the Teleporter. One more thing. This condition becomes easily lost when SW1:1 is set to normal (on). I think this benefit is owing to 128fs but will not talk about it here
. BTW, the firmware of Amanero is 2004be. Also you don't need to be persistent with using uFL cables. My experiments were all done with wire cables.Get the beta firmware before renewal of the clocks.
Hi twluke,
There is nothing surprising there.
In puresync (128fs) mode (puresync firmware) it would be expected to work.
Remember the DoP decoding is happening at the amanero. The Hermes/Cronus/DAC are only seeing DSD.
So for DSD256 you only need:
((2.8224Mhz * 4) / 64) * 128 = 22.5792Mhz
Remember in 128fs mode the mck only need be evenly divisible by 128fs - so: MCK % 128fs = 0 = valid master clock.
DSD played in PureSync mode will also work exactly the same (measured) for DSD64 and DSD128 using that same 22.5792Mhz clock. To reach DSD512 you will need the 45 Mhz clock and PureSync. For DSD1024 - you need 90Mhz and PureSync (as well as a source that can actually do it).
Cheers
Russ
There is nothing surprising there.
In puresync (128fs) mode (puresync firmware) it would be expected to work.
Remember the DoP decoding is happening at the amanero. The Hermes/Cronus/DAC are only seeing DSD.
So for DSD256 you only need:
((2.8224Mhz * 4) / 64) * 128 = 22.5792Mhz
Remember in 128fs mode the mck only need be evenly divisible by 128fs - so: MCK % 128fs = 0 = valid master clock.
DSD played in PureSync mode will also work exactly the same (measured) for DSD64 and DSD128 using that same 22.5792Mhz clock. To reach DSD512 you will need the 45 Mhz clock and PureSync. For DSD1024 - you need 90Mhz and PureSync (as well as a source that can actually do it).
Cheers
Russ
Last edited:
Update-Hermes/Amanero, DSD 256, sync clocking
OK: Replaced the Cronus, mounted an NDK 2520 SDA 45.1584 MHz XO (lower phase noise spec than Crystek 957/575), jumped the second clock position via u.fl, running master clock from Cronus.
Hurray, success! DSD 256 now plays (oversampled via Audirvana Plus or ROON) flawlessly with sync clocking (not sync SW though, yet) and a single oscillator set up.
BTW, I feel the sound is even more relaxed than with the Crystek clocks, perhaps the NDK SDA series really is producing lower jitter, sure sounds GREAT!
Thanks Russ/Brian for all your work, loving the 9038/Mercury combo in this set up.
BTW, could i know the PN for the clock divider on the Cronus v 1.2? I want to try and restore it to proper operation for other projects (I suspect there are issues).
OK: Replaced the Cronus, mounted an NDK 2520 SDA 45.1584 MHz XO (lower phase noise spec than Crystek 957/575), jumped the second clock position via u.fl, running master clock from Cronus.
Hurray, success! DSD 256 now plays (oversampled via Audirvana Plus or ROON) flawlessly with sync clocking (not sync SW though, yet) and a single oscillator set up.
BTW, I feel the sound is even more relaxed than with the Crystek clocks, perhaps the NDK SDA series really is producing lower jitter, sure sounds GREAT!
Thanks Russ/Brian for all your work, loving the 9038/Mercury combo in this set up.
BTW, could i know the PN for the clock divider on the Cronus v 1.2? I want to try and restore it to proper operation for other projects (I suspect there are issues).
That's great news!
It does sound like you had a bad part somewhere - it could have been one of a few.
Either clock type would work well in this circuit for this application - we make Rhea modules so people can use clocks like those from NDK etc if they like - so I am glad you are doing so! The Crystek clocks are still superb and a solid choice - but I would never discourage trying others. Rhea is very flexible exactly for that purpose.
I surmise by your descriptions that either you had a clock going south - or as you seem to indicate either the Divider, Buffer, MUX, or the FF itself could have been damaged. You could verify this with a scope.
These things have happened to me in the past too. I killed a FF and a clock in testing myself (I suspect by shorting or ESD). In prototyping I have toasted many parts
The divider is an ICS542.
Cheers!
Russ
It does sound like you had a bad part somewhere - it could have been one of a few.
Either clock type would work well in this circuit for this application - we make Rhea modules so people can use clocks like those from NDK etc if they like - so I am glad you are doing so! The Crystek clocks are still superb and a solid choice - but I would never discourage trying others. Rhea is very flexible exactly for that purpose.
I surmise by your descriptions that either you had a clock going south - or as you seem to indicate either the Divider, Buffer, MUX, or the FF itself could have been damaged. You could verify this with a scope.
These things have happened to me in the past too.
I killed a FF and a clock in testing myself (I suspect by shorting or ESD). In prototyping I have toasted many parts The divider is an ICS542.
Cheers!
Russ
Last edited:
Reha modules and Tentclocks
Hi,
did anyone try the Tentclocks from Guido Tent from the netherlands.
Are thoose (TentlabsShop) compatible with reha module
BR
Branko
Hi,
did anyone try the Tentclocks from Guido Tent from the netherlands.
Are thoose (TentlabsShop) compatible with reha module
BR
Branko
Quick question. I am experimenting with BBB+Hermes+Cronus. I recently picked up a used built setup with 22.5/24.5 clocks but I also have a brand new setup that I got 2 weeks ago from TP, which I had ordered with 44/45 clocks. If I install the 44/45 clocks in place of the existing 22.5/24.5 clocks do I need to make any changes on the Cronus or is it swap out one set and swap in the other?
Any documentation on how everything should be hooked up?
Any documentation on how everything should be hooked up?
Just completed the same change and agree that the NDK clocks do seem to offer an overall improvement. Soldering those tiny devices is quite a challenge - kudos to TPA for making the Rhea board so versatile to fit these!
The Hermes Amanero is a fantastic bit of kit. The only niggle I have is that the Amanero / Hermes has to boot up prior to being connected to ones USB source, otherwise it won't normally connect.
Thinking this over, if the USB 5v line from the source to the Amanero (on the Amanero board?) could be interrupted during the DAC / Hermes power up, then connected, this would presumably eliminate the problem.
Since my system used a Arduino as a control I was thinking that a relay that is actuated by Arduino to switch the power on a few seconds after the Hermes may provide the solution, has anyone tried such a system? - Not sure how difficult it would be to cut the 5v line after the USB input on the Amanero.
Cheers
Thinking this over, if the USB 5v line from the source to the Amanero (on the Amanero board?) could be interrupted during the DAC / Hermes power up, then connected, this would presumably eliminate the problem.
Since my system used a Arduino as a control I was thinking that a relay that is actuated by Arduino to switch the power on a few seconds after the Hermes may provide the solution, has anyone tried such a system? - Not sure how difficult it would be to cut the 5v line after the USB input on the Amanero.
Cheers
I posted over in the Cronus but this may be more relevant here.
I have the Cronus mounted with 45/49 clocks.
With CPLD=`Slave_for_1080` and CPU=`firmware_1096c` (and updated config bits) I don't get a lock and foobar is stuck.
If I revert back to` CPLD_for_1080` then I get a lock and music plays fine. I'm assuming in this case Cronus isn't doing anything?
What could be the issue?
I have the Cronus mounted with 45/49 clocks.
With CPLD=`Slave_for_1080` and CPU=`firmware_1096c` (and updated config bits) I don't get a lock and foobar is stuck.
If I revert back to` CPLD_for_1080` then I get a lock and music plays fine. I'm assuming in this case Cronus isn't doing anything?
What could be the issue?
Last edited: