Reference DAC Module - Discrete R-2R Sign Magnitude 24 bit 384 Khz - Page 57 - diyAudio
Go Back   Home > Forums > Commercial Sector > Vendor Forums > Vendor's Bazaar
Home Forums Rules Articles diyAudio Store Gallery Wiki Blogs Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

Vendor's Bazaar Commercial Vendors large & small hawking their wares

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 28th November 2014, 01:21 AM   #561
acko is offline acko  Australia
diyAudio Member
 
Join Date: Jan 2008
Location: Sydney, Australia
Default Soren's DAC

Quote:
Originally Posted by potstip View Post
I know that but Currently (until Soren can allow to take external clock) S03 board is useless for R-2R DAC (Confirmed by ACKO). So i thing without S03 we lost the advantage to use BBB.
Quote:
Originally Posted by nautibuoy View Post
I disagree, though I'm not sure what you actually asked Acko. You can use the SO3 perfectly well between a Beaglebone and the R2R DAC, you just can't run it in full sync mode. You just use the SO3 to reclock the Beaglebone to ensure you keep native sampling rates, then feed the I2S from the SO3 to the R2R. Admittedly some functions on the SO3 are superfluous because the R2R isolates and reclocks but I don't think they will do any harm.
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
__________________
AckoDAC Project

Last edited by acko; 28th November 2014 at 01:35 AM.
  Reply With Quote
Old 28th November 2014, 01:49 AM   #562
emyeuoi is offline emyeuoi  Italy
diyAudio Member
 
emyeuoi's Avatar
 
Join Date: Oct 2010
Location: South Korea
Acko,

Great analysis... THANKS!

I am in waiting list for this DAC and you post make me more confident, if needed, about the quality of soeren design.

Regards,
Enrico
  Reply With Quote
Old 28th November 2014, 03:19 AM   #563
diyAudio Member
 
Join Date: Jul 2010
Default 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.
  Reply With Quote
Old 28th November 2014, 03:25 AM   #564
diyAudio Member
 
Join Date: Feb 2009
Location: Brisbane, Australia
Quote:
Originally Posted by acko View Post
DSD support will be most welcome. Ian has stopped short of this so if you can take this further that would be great.
I think Ian had insufficient memory to implement the DSD FIFO on the hardware he had designed.
  Reply With Quote
Old 28th November 2014, 08:03 AM   #565
acko is offline acko  Australia
diyAudio Member
 
Join Date: Jan 2008
Location: Sydney, Australia
Quote:
Originally Posted by barrows View Post
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.
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?
__________________
AckoDAC Project

Last edited by acko; 28th November 2014 at 08:12 AM.
  Reply With Quote
Old 28th November 2014, 10:33 AM   #566
soekris is offline soekris  Denmark
diyAudio Member
 
Join Date: Jun 2009
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%20docu...docs/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....
__________________
Søren
  Reply With Quote
Old 28th November 2014, 10:57 AM   #567
diyAudio Member
 
andrea_mori's Avatar
 
Join Date: Jan 2005
Location: Italy
Quote:
Originally Posted by soekris View Post
The Si514 oscillator used is very low jitter ....
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.....
  Reply With Quote
Old 28th November 2014, 11:42 AM   #568
esgigt is offline esgigt  Netherlands
diyAudio Member
 
Join Date: Dec 2013
Quote:
Originally Posted by andrea_mori View Post
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..
  Reply With Quote
Old 28th November 2014, 11:48 AM   #569
HpW is offline HpW  Switzerland
diyAudio Member
 
Join Date: Mar 2002
Location: Switzerland (Bern)
Quote:
Originally Posted by soekris View Post
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.
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
__________________
Download FFT Analyzer & Generator at www.hpw-works.com
  Reply With Quote
Old 28th November 2014, 01:16 PM   #570
Banned
 
Join Date: Dec 2013
Quote:
Originally Posted by soekris View Post
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%20docu...docs/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....
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.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
e18 DAC - 8 channels at 32bit /384 kHz exa065 exaDevices 30 29th June 2012 05:11 PM
384 Khz DAC? SunRa Digital Source 8 1st October 2009 11:14 PM
24 bit/192 kHz via USB? gentlevoice Everything Else 3 22nd December 2008 06:24 AM
sign magnitude DAC Bernhard Digital Source 0 30th January 2007 01:40 PM
24 bit / 192 kHz Tube DAC questions Overlord Digital Source 4 29th April 2003 05:14 PM


New To Site? Need Help?

All times are GMT. The time now is 08:40 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
Copyright ©1999-2017 diyAudio

Content Relevant URLs by vBSEO 3.3.2
Wiki