128 * Fs gear clock
Hi Russ,
I was reading through your previous posts; I believe, current version of sync firmware is mentioned in post 663/page 61 of this thread.
How does this Firmware respond if one feeds in multiples of 128 * Fs; e.g. 256 * Fs, 512 * Fs?
Thanks
Hey guys - I have not had much time to play with pure-sync until this weekend. I am working on it today and have a few observations:
Importantly - we must set a clock gearing ratio to play DSD (and to get optimal PCM). The gear ratio will entirely depend on the frequency of your master clock. The key is you need to gear the clock to 128FS. This has some implications for hermes/cronus.
The key here is we need to use some port expander positions to indicate what gearing to use. This could be automated from certain sources like the amanero - but not (currently - at least ideally) via hermes/cronus because you would lose isolation. So the best short term solution would be to set the gearing manually (via the DIP/Panel switches or controller) and then stick to a single sample rate - possibly resample all content at the player.
Open to suggestions
Hi Russ,
I was reading through your previous posts; I believe, current version of sync firmware is mentioned in post 663/page 61 of this thread.
How does this Firmware respond if one feeds in multiples of 128 * Fs; e.g. 256 * Fs, 512 * Fs?
Thanks
How about providing a daughter board to generate MCLK from BCLK using a multiplier from such an ICS? If this is possible, the MCLK becomes only dependent on the source frequency and it can be always set to fulfill 128fs for pure sync mode. This will not break isolation.-snip-
The key here is we need to use some port expander positions to indicate what gearing to use. This could be automated from certain sources like the amanero - but not (currently - at least ideally) via hermes/cronus because you would lose isolation. So the best short term solution would be to set the gearing manually (via the DIP/Panel switches or controller) and then stick to a single sample rate - possibly resample all content at the player.
Open to suggestions
Regards,
Hey guys - I have not had much time to play with pure-sync until this weekend. I am working on it today and have a few observations:
Importantly - we must set a clock gearing ratio to play DSD (and to get optimal PCM). The gear ratio will entirely depend on the frequency of your master clock. The key is you need to gear the clock to 128FS. This has some implications for hermes/cronus.
The key here is we need to use some port expander positions to indicate what gearing to use. This could be automated from certain sources like the amanero - but not (currently - at least ideally) via hermes/cronus because you would lose isolation. So the best short term solution would be to set the gearing manually (via the DIP/Panel switches or controller) and then stick to a single sample rate - possibly resample all content at the player.
Open to suggestions
So, in order to get the absolute best results for Red Book audio we will need to use an MCLK of 5.644,8 MHz?
If based on the math of 128fs, that will be correct.
Since the introduction of the pure sync firmware in April, I've been enjoying this pure sync mode on my 9038pro and 9028pro DACs (the latter in dual-mono pure sync) from TPA and can say that one particular rate of MCLK fulfilling 128fs can cover the source of 64fs for ordinary use: meaning that a 11.2MHz MCLK may cover the source requiring 5.6MHz MCLK for pure sync but you will soon find the SQ is not the same and slightly compromised.
The current firmware for WithDisplay allows to change the clock gear to the half rate using the basic function of ES9038/9028 but I would say that you can not avoid some degradation of the SQ with this setting, as long as based on my personal experience.
Regards,
At least, as long as the current beta firmware enabling gearing function by Russ is concerned, my answer would be yes, though it may be probably dependent on the configuration (I have no data sheet now).
Regards,
Russ: My approach is already to re-sample everything to DSD 256 in the software player, so this solution is perfect for me. I am using Hermes/Amanero/Cronus with a single 45.1584 XO (with a jumper cable the other clock position). I really like feeding the ESS DSD 256 and feel no need to be compatible with other rates at this point.
Hey guys - I have not had much time to play with pure-sync until this weekend. I am working on it today and have a few observations:
Importantly - we must set a clock gearing ratio to play DSD (and to get optimal PCM). The gear ratio will entirely depend on the frequency of your master clock. The key is you need to gear the clock to 128FS. This has some implications for hermes/cronus.
The key here is we need to use some port expander positions to indicate what gearing to use. This could be automated from certain sources like the amanero - but not (currently - at least ideally) via hermes/cronus because you would lose isolation. So the best short term solution would be to set the gearing manually (via the DIP/Panel switches or controller) and then stick to a single sample rate - possibly resample all content at the player.
Open to suggestions
Simpler is better so I'd vote for the DIP switch solution. Like barrows, I'm resampling everything to DSD256 with the current beta firmware except native DSD files. I can resample those as well if necessary. Really like the sound with the current sync firmware. Thanks for the effort on this.
This discussion is very interesting but unfortunately I seem to have some significant knowledge gaps on this topic and is getting confusing.
For purely Redbook material, which would be the "best" configuration for Chronus/Hermes/Amanero -> 9038 ?
I'm using the default Amanero firmware, with the 45/49 pair.
For purely Redbook material, which would be the "best" configuration for Chronus/Hermes/Amanero -> 9038 ?
I'm using the default Amanero firmware, with the 45/49 pair.
+ 1.
We're in 2019 (in practice), i think source oversampling to 192/384 Khz and/or conversion to DSD256/DSD512 should be the technologies to aim for, considering we're talking about a hiend DAC.
For an extraordinary support for Redbook frequencies, manual switches are more than enough IMHO...
Importantly - we must set a clock gearing ratio to play DSD (and to get optimal PCM). The gear ratio will entirely depend on the frequency of your master clock. The key is you need to gear the clock to 128FS. This has some implications for hermes/cronus.
The key here is we need to use some port expander positions to indicate what gearing to use. This could be automated from certain sources like the amanero - but not (currently - at least ideally) via hermes/cronus because you would lose isolation. So the best short term solution would be to set the gearing manually (via the DIP/Panel switches or controller) and then stick to a single sample rate - possibly resample all content at the player.
Open to suggestions
Re-reading all the posts;
If one already commits to a single sample rate, my understanding is current beta version of PureSync (from July’18) is already fit for purpose (based on comments from twluke)
One just needs to select that sample rate wisely so that it is 128 * Fs multiplier with Clock; e.g.
- 176/192 kHz/DSD256 and 22/24 Mhz clocks or
- DSD 512 and 44/49 Mhz clocks etc.
And in this way, one can also remove any need for Clock Gearing as the setup will work on 128 * Fs in any case.
In short, as long as someone wants to stick to a certain sample rate, the functionality to run in PureSync mode is already there with July firmware (with smart selection of the sample rate or Clock freq.)
Is it a fair understanding? Or am I oversimplifying anything? As so far, I have thought the big challenge is with the different sample rates; e.g. streaming from Qobuz and in addition to RedBook/44.1 kHz, you also have 96 kHz and 192 kHz etc.
Last edited:
My humble view is; it would be great to have the flexibility so that people can choose what works best for them.
In my case, I am trying to simplify and just carry the original digital data to the DAC in a bitperfect manner and let the ESS DAC to do all the upsampling (we should keep in mind that, default 8x oversampling filter of ESS chips is already in place for PCM) and have no interest to pre-upsample (if that word exists)
I know that “More oversampling is better” train of thought has an appeal for some but I would love the rest of us not to be forgotten
My humble view is; it would be great to have the flexibility so that people can choose what works best for them.
In my case, I am trying to simplify and just carry the original digital data to the DAC in a bitperfect manner and let the ESS DAC to do all the upsampling (we should keep in mind that, default 8x oversampling filter of ESS chips is already in place for PCM) and have no interest to pre-upsample (if that word exists)
I know that “More oversampling is better” train of thought has an appeal for some but I would love the rest of us not to be forgotten
In our proposal, dip switch gearing is present. Flexibility is still there...
9038 upsampling is very good, but listen to dsd256/512 upsampled music by hqp (with the right algorythm) and you'll hear the difference anyway.
Hi Brian, I'm not sure how crazy this idea can be. It seems everyone became silent...
Well, my understanding may be wrong but if it means a kind of chance offering more flexible user-control of the DAC chip, providing a basic shell script to control DAC via I2C like miero's daccfg_es9018 will be quite convenient for the users of BBB-Hermes like me.
Regards,
Hi Brian, I'm not sure how crazy this idea can be. It seems everyone became silent...
Well, my understanding may be wrong but if it means a kind of chance offering more flexible user-control of the DAC chip, providing a basic shell script to control DAC via I2C like miero's daccfg_es9018 will be quite convenient for the users of BBB-Hermes like me.
Regards,
Greetings twluke,
I have been working on I2C control software running in Python. My code for 9028/38 is nearly complete, though I've been very busy with my job so no progress recently. One aspect that will vary among users is the nature of their preferred control interface. My software uses a Python 'asyncore' module, which responds to text commands sent through either TCP or UDP inputs. Writing scripts to send text via TCP or UDP from the BBB is easy, once you decide what hardware will launch any particular script. I use my iPhone and iPad. If there is interest, I will get back to work on this and get it up on github ASAP. The example code won't be 100% applicable to all systems, but will be fairly easy to cut into shape for reliable I2C communication on-the-fly.
Best,
Frank
Hi Frank, thank you for kindly introducing your works in progress for I2C control of 9028/9038. It is very interesting and I might want to try it, if possible (currently on my iPod Touch or perhaps on an android phone).
However, I've been usually communicating with the BBB via a terminal app running on my MacBook Pro and the shell script written by miero was sufficient for me to control a 9018 DAC via I2C because there was no need to change the setting so frequently. So I'm not sure if I actually need such a sophisticated interface.
Anyway it will be quite attractive if I can change the DAC status without onboard firmware, say, from async to pure sync mode or disable/enable SPDIF on the fly (apart from physical change of the cable connection).
Regards,
You could actually control from iPod, android, and the MacBook if you use the mobile app 'NetIO'! I am using it for iOS and there is an android implementation (though I have no experience with that). Documentation is not great, but I've managed some interface problems by trial-and-error and now the needed syntax is working. I use I2C exclusively to control volume, to mute, to control the inputs to the system and select the DAC filters. Individual control of bass, midrange, and treble DAC volume is a nice way to balance poorly mastered music without suffering the decay of running equalization filters.
If you are happy with a terminal interface then the job becomes very simple. I have tried bash scripts but they were not always as reliable for my needs as python. You can trigger the python scripts from bash to do a bit less typing, if you like.
It is simple to control a TPA Otto or 4:1 Mux using the BBB. I use Otto to switch between two different SPDIF sources running into the BBB for crossover processing. But you can control those switches just as easily wherever they fit into the system.
If you wish to experiment with this, I'm happy to help. Code is already working. We just need to throw away various lines related to my personal needs. I'm not a programmer - I just learn what is needed and try. Bash and Python are easier for those of us who just 'hack'!