Soren's DAC
Soren,
I hope you do not mind my posting some explanation to clarify. I do not have all the details of your implementation but piecing together all that you have indicated so far this is what I think your front end processing is doing. (Correct me if I am wrong):
Basically a FIFO buffer- Reclocker similar to IanCanada's implementation.
Firstly, input I2S stream gets dumped into a deep FIFO and thereby decimating all the timing associating with the data (and so any incoming jitter or other latencies).
Next, new data is regenerated with respect to a reference audio clock and I would think this will be 22.5792MHz/24.576MHz to cover both 44.1k and 48k based frequencies. This could be what the Si514 is doing
So practically all benefits and concepts associated with Ian's FIFO are applicable to your implementation. You have just gone a step ahead to integrate this unique R-2R DAC on board as well. Just as well as it makes sense to package a complete FIFO-DAC system.
So with regards to the above queries, it would be pointless to connect the S03 to Soren's DAC just like you would not do so with Ian's board as both are standalone and complete system. By action of the FIFOs they completely decouple the signal flow from the source (transport) and does not need to interact with the transport clock but provide Full Sync operation of the DAC.
The implications are very interesting:
You can connect any I2S transport to Soren's DAC simply without worrying about quality of source clock or signals as the clock on the DAC and the FPGA processing determine the final outcome. Of course the isolation helps to block all the nasties from source side.
I am making a bold statement here:
Regardless of the type of transport used (as long as bit perfect types - native Fs with dual clocks) they will all sound the same on Soren DAC (similar to Ian's). So Amanero, BBB-Botic, M2tech, EDEL NMR, WaveIO etc will all sound the same as a result of the FIFO-reclocking action. So if you have any one of the above that will be good enough!
If Spdif is required, just cobble together a simple Spdif-I2S converter and you will get similar performances as direct I2S. Spdif is bit-perfect but inherently jittery- not to worry, this gets cleaned out by the FIFO-re-clocker.
The ultimate performance of the digital side will depend on the quality of the reference clock on board Soren's DAC. So if external audio clock input is provided then we can take advantage of better clock oscillators. Again to clarify this will be standalone clock module that interacts with the FPGA only. It does not need to interact with the transport clock like in the case of S03 setup
DSD support will be most welcome. Ian has stopped short of this so if you can take this further that would be great.
My two cents
Soren,
I hope you do not mind my posting some explanation to clarify. I do not have all the details of your implementation but piecing together all that you have indicated so far this is what I think your front end processing is doing. (Correct me if I am wrong):
Basically a FIFO buffer- Reclocker similar to IanCanada's implementation.
Firstly, input I2S stream gets dumped into a deep FIFO and thereby decimating all the timing associating with the data (and so any incoming jitter or other latencies).
Next, new data is regenerated with respect to a reference audio clock and I would think this will be 22.5792MHz/24.576MHz to cover both 44.1k and 48k based frequencies. This could be what the Si514 is doing
So practically all benefits and concepts associated with Ian's FIFO are applicable to your implementation. You have just gone a step ahead to integrate this unique R-2R DAC on board as well. Just as well as it makes sense to package a complete FIFO-DAC system.
So with regards to the above queries, it would be pointless to connect the S03 to Soren's DAC just like you would not do so with Ian's board as both are standalone and complete system. By action of the FIFOs they completely decouple the signal flow from the source (transport) and does not need to interact with the transport clock but provide Full Sync operation of the DAC.
The implications are very interesting:
You can connect any I2S transport to Soren's DAC simply without worrying about quality of source clock or signals as the clock on the DAC and the FPGA processing determine the final outcome. Of course the isolation helps to block all the nasties from source side.
I am making a bold statement here:
Regardless of the type of transport used (as long as bit perfect types - native Fs with dual clocks) they will all sound the same on Soren DAC (similar to Ian's). So Amanero, BBB-Botic, M2tech, EDEL NMR, WaveIO etc will all sound the same as a result of the FIFO-reclocking action. So if you have any one of the above that will be good enough!
If Spdif is required, just cobble together a simple Spdif-I2S converter and you will get similar performances as direct I2S. Spdif is bit-perfect but inherently jittery- not to worry, this gets cleaned out by the FIFO-re-clocker.
The ultimate performance of the digital side will depend on the quality of the reference clock on board Soren's DAC. So if external audio clock input is provided then we can take advantage of better clock oscillators. Again to clarify this will be standalone clock module that interacts with the FPGA only. It does not need to interact with the transport clock like in the case of S03 setup
DSD support will be most welcome. Ian has stopped short of this so if you can take this further that would be great.
My two cents
Last edited:
But...
I do not think Soren's re-clock circuit works as Acko has described. From my understanding, Soren's approach does adjust the onboard clock to sync with incoming data rates, to some extent. At least that is how he (Soren) described it, so, some kind of PLL approach, apparently, and not a fully asynchronous re-clocking circuit based on fixed onboard clock frequency/frequencies.
I would much prefer a fully asynchronous re-clocking with a large enough buffer, and a fixed low phase noise oscillators instead of a moving digitally adjusted clock.
I do not think Soren's re-clock circuit works as Acko has described. From my understanding, Soren's approach does adjust the onboard clock to sync with incoming data rates, to some extent. At least that is how he (Soren) described it, so, some kind of PLL approach, apparently, and not a fully asynchronous re-clocking circuit based on fixed onboard clock frequency/frequencies.
I would much prefer a fully asynchronous re-clocking with a large enough buffer, and a fixed low phase noise oscillators instead of a moving digitally adjusted clock.
I think Ian had insufficient memory to implement the DSD FIFO on the hardware he had designed.
Yes, I remember seeing this - thanks!
Please check if I get the concept right with the sequence:
1. FIFO has 2 clock inputs. Data is clocked into the FIFO by action of the I2S
bit_clock (BCK). This requires no intervention by the CPU.
2. CPU reads the trace data by clocking out at some nominal rate on the output side of the FIFO. Checks the data header for actual sample rate and bit depth. While this is happening there will some delay and FIFO takes up the slack to accommodate more data that is streaming in.
3. CPU adjusts the FIFO out clock freq to sync with the data rate. Logically this means the clock frequency must match that of the bit clock so it is going to be some fixed value (so that FIFO does not overflow or empties out-elastic memory).
The steps described above is what I think is common for a typical transport.
How does then Soren's FIFO action differ from the above?
Last edited:
The details of my clocking/FIFO:
Ian's FIFO use a fixed clock, and therefore use a large buffer to take up the difference between incoming and outgoing clock. That add a large delay, which doesn't matter for simple audio applications but are undesirable in a number of applications, like home theater or live music.
I use a much shorter FIFO, selectable down to 1 mS, and instead adjust the outgoing clock to match the incoming clock frequency as needed, being I2S or SPDIF. The Si514 oscillator used is very low jitter and digitally programmable with a resolution of 0.026 ppb (parts per billion, not million...). It also have the feature that reprogramming inside +-1000 ppm is glitchless, ie the clock adjust very nicely to small changes.
See Si514 datasheets for details:
http://www.silabs.com/support documents/technicaldocs/si514.pdf
The idea is that after initial measure and programming of clock frequency, any further changes are very small and wouldn't be noticed at all.
There have been several discussions about Si514 performance so lets not repeat that....
Ian's FIFO use a fixed clock, and therefore use a large buffer to take up the difference between incoming and outgoing clock. That add a large delay, which doesn't matter for simple audio applications but are undesirable in a number of applications, like home theater or live music.
I use a much shorter FIFO, selectable down to 1 mS, and instead adjust the outgoing clock to match the incoming clock frequency as needed, being I2S or SPDIF. The Si514 oscillator used is very low jitter and digitally programmable with a resolution of 0.026 ppb (parts per billion, not million...). It also have the feature that reprogramming inside +-1000 ppm is glitchless, ie the clock adjust very nicely to small changes.
See Si514 datasheets for details:
http://www.silabs.com/support documents/technicaldocs/si514.pdf
The idea is that after initial measure and programming of clock frequency, any further changes are very small and wouldn't be noticed at all.
There have been several discussions about Si514 performance so lets not repeat that....
Si514 is not very low jitter, see page 7 of the datasheet, the integration bandwidth used to test jitter is non compliant with audio digital to analog conversion (12kHz to 20MHz).
And -86dBc@100Hz from the carrier is not low phase noise, that confirms the device is not very low jitter.
Jitter and phase noise are exactly the same thing, jitter in time domain and phase noise in frequency domain. There is an exact math relationship between them.
Using PLL in audio device deserves a separate discussion.....
Andrea,
Can you expand on that, please?
I understand that the phase noise between 0Hz and 20Khz is very relevant in audio applications, but on the other hand I also see the numbers for Period jitter (RMS and pk-pk) which are in the range from 1.3ps to 11ps (max. values)...
Is this period jitter (how do I have to understand that term?) the number Soekris refers to?
Thanks in advance..
The real question comes in to my mind, as I did in the old days a CPU driven DACXVCO to control the freq. differences:
How you deal with buffer over/under runs? Simple skip or repeat the missing sample? While this hear able not in a low freq. signal but for certain in a higher signal (this comes from my real listening tests). Keep in mind that the source master clock (CD or USB) are also not stable and will vary on time due temperature rise.
This click/pop issue will also not accepted in live performance..
my 2 cents
Hp
The Xilinx Spartan-6 FPGA in the FTG256 package have system jitter in the range of 200ps and possibly up to 1000ps or more depending on the synthesised code, internal routing and if there are any processes that adds modulated noise to the PSU rails. This jitter adds to any clock jitter and are forwarded to the 595 shift registers that implements the DAC.
A simulation can maybe go as low as 200ps for the FPGA core, but due to the bonding wires, pads and pcb traces and the skew the practical total "jitter" may end up in the ns range.
Jitter is the integration of the phase noise, so it depends on the integration bandwidth used to do the test. Since any decent oscillator shows a phase noise better than -140dBc at 1kHz from the carrier, the upper limit of the bandwidth is not relevant. But the pain starts when you fall down close to the carrier, where the phase noise increases considerably. So the lower frequency of the integration bandwidth chosen for the test affects strongly the jitter measured. Translated: the upper limit does not affects the jitter test, while the lower limit affects it. If you choose 12kHz for the lower limit, the jitter will be much better than if you choose 10Hz or 1Hz as the lower limit.
If you look at Crystek CCHD-957 datasheet you see they used an integration bandwidth starting at 10Hz from the carrier, that's correct for audio application.
While the lower limit used from SiLabs is suitable for telephonic application or so, not for audio.
There are several spreadsheet on the internet that helps to convert phase noise in jitter.
That's a little too pessimistic.... You might be thinking about clock skew or pll jitter, not the jitter for the internal clock routing....
There will be jitter inside the FPGA and to the LVC595's, but I don't see any reason why it should be different from internal jitter in any other DAC chip....
Assuming that the total accumulated jitter only are dependent on a low jitter clock was the point I wanted to address.
With the Spartan-6 CPG196 package that have the lowest jitter and skew the lowest simulated system jitter for the internal clock routing I am able to get are 141ps.
However that is overly optimistic as it is only represents a small percentage of the real jitter on the output pads.
With that said the total jitter from a optimized Spartan-6 design are most possibly not higher than what a galvanic I2S isolator creates, and even a discrete D-FF re-clock chip may add significant jitter.
The quietio setting and setting of the output current drive of the output pads may improve the jitter on the DAC output, and also using all of the un-assigned pads as virtual GND and virtual VCC may improve jitter, noise and skew.
Excuse me for back-tracking the thread a little but I would like to check I’m not misunderstanding something…
Acko, I don’t disagree with the points you have made about the FIFO/reclocker inherent in the Soekris R2R DAC delivering consistent results through the DAC and it was the same functions on your SO3 board that I was suggesting would therefore be superfluous if used with the Soekris R2R DAC, however, my suggestion for using your SO3 in front of the Soekris DAC was specifically in the context of using a Beaglebone Black (BBB) as the transport.
My understanding is that, because of the limitations of the BBB’s onboard clock it will resample all 44.1KHz family data to a 48KHz related rates – this may be audible – and, if the BBB is connected directly to the R2R DAC inputs the DAC will process the data at 48KHz, i.e. it will process the previously compromised data ‘as is’.
I was suggesting the use of an SO3 between the BBB and R2R DAC only as a means of keeping the native sample rates of the data processed through the BBB (in conjunction with the miero driver obviously) - are you saying this is wrong?
Thanks
Ray
Hmmm
I think this discussion of internal jitter in a Spartan 6 probably deserves it's own thread, but it is relevant here as well. Static, if what you are suggesting is accurate, how come commercial DACs fully realized via a Spartan 6 actually measure with jitter levels well below what you are suggesting is the theoretical limitation of the FPGA chip? Consider Chord for instance. Perhaps the solution would be to re-clock directly before the D/A conversion via a flip-flop from a direct masterclock feed? But what about DACs where the actual D/A process is internal to the FPGA?
I think this discussion of internal jitter in a Spartan 6 probably deserves it's own thread, but it is relevant here as well. Static, if what you are suggesting is accurate, how come commercial DACs fully realized via a Spartan 6 actually measure with jitter levels well below what you are suggesting is the theoretical limitation of the FPGA chip? Consider Chord for instance. Perhaps the solution would be to re-clock directly before the D/A conversion via a flip-flop from a direct masterclock feed? But what about DACs where the actual D/A process is internal to the FPGA?
Well that's why I suggested (some pages back) that a simple, high quality flip-flop be inserted right after the FPGA. Such would then leave no doubt about what the final jitter into the R2R network would be. If he needs room, then just move all those FPGA PS pin bypass caps to the bottom side of the board--closely encircling the FPGA where they can do some good--they are too far away now to much anyway.
