There isn't any pragmatism, simply the FIFO of the DAM does not work properly and then the DAC becomes source dependent, that's the reason why you feel the need to install another FIFO buffer before the DAM.
Already said, the purpose of a FIFO buffer is just to isolate the DAC from the source because the source and the DAC operate in different time domains.
A properly designed FIFO buffer provides the wanted isolation, so the timing of the DAC is affected by the clock of the FIFO only.
Not from the jitter of the RPI, the source does no longer matter.
You can use whatever source you want.
Is that clear?
Do you agree?
About the oscillators I have published the measurements that's the only technical documents I can provide, while others claim <1ps without providing any measurement.
About the influence of the close in phase noise of the oscillator on the sound quality I'm sorry but I cannot provide a physical equation.
The same as me and no one can provides mathematical equations to explain why a 2% THD DHT amplifier sounds better than another one with 0.000000% THD.
Just try the way and get your own opinion.
About Pat I was a friend of him, I met him in his labs in 2018, and I well know his opinion.
But if you have read the whole thread around 3-4 years ago I wrote that I would have designed a 11.2896 MHz oscillator with a phase noise of at least -120 dBc at 10 Hz from the carrier.
I did bet one dollar with Jocko on this challenge.
I won the challenge, my 11.2896 MHz oscillator is -145 dBc phase noise at 10 Hz from the carrier, 25 dB better than i did predict.
Attachments
A properly designed FIFO sources its domain and masterclock from DAC crystal, so DAC can't be affected by the clock of the FIFO.
Are you really graduated?
It looks like you have not read carefully, I have already tried and the divider performs equal or something better than the state of the art base oscillator (not the crappy Crystek).
You should measure instead of claim unsupported statements.
This reminds me of some designers.
If you like the Crystek I'm glad for you, stay with it and live happy.
But I have to remind that this is not a thread about oscillators, please write your comment on the dedicated thread, you are welcome
The Well Tempered Master Clock - Building a low phase noise/jitter crystal oscillator
And I have to remind that I paid 350 EUR for a DIY product so I'm free to tweak it as I prefere and to write my modest opinion on the design choices.
Lastly for the DAM enthusiastic followers there is the dedicated thread, maybe this thread is more appropriate for those who are not so pleased of the DAM performance and are looking for a way to improve it.
You are confusing the purpose of this thread.
I'm trying to improve the performance of the DAM because IMHO the front end of the DAC is not properly designed.
So much so that someone install another FIFO buffer before the DAM.
What does it means?
It does mean that someone is not so pleased of the isolation provided by the FIFO of the DAM.
So?
The conclusion is enough obvious: the source and the DAC don't operate in different time domains (the FIFO buffer should provide just this benefit).
IMHO this means that the FIFO of the DAM was not properly designed.
But if you have alternative explanations I'm happy to hear your reasons.
On the other side if you are totally satisfied of the DAM performance, of course this thread is not for you.
You already got the GRAAL.
You are confused again.
There is no master clock at the DAC side of the DAM.
The master clock (the Silabs) resides on the front end of the DAC.
It feeds the FPGA and the micro, then the FPGA feeds the shift/latch registers (the latch is the most crucial signal since it provides the timing to the DAC switches).
Don't worry, I will publish the DAC part schematic of the DAM soon (although I'm busy replying to all the post).
And since the front end of the DAM tracks the source then the digital to analog conversion is affected from the jitter of the clock, from the jitter of the PLL and also from the jitter of the FPGA.
Indeed in our FIFO Lite we don't feed the LRCK of the DAC from the FPGA, it comes directly from the master clock via copper, while the other dirty signals like DATA and BCK are provided by the FPGA but with full optical isolation.
Last edited:
... fyi: models after the 1021 are re-clocked after the FPGA.
"And since the front end of the DAM tracks the source then the DAC is affected from the jitter" - well I would not call it jitter what is passed through. Jitter is something less than a 10th of a clock cycle. What happens here I believe is that the constant alterations of Si frequency is what is effecting the sound. Thats something else on a whole other scale than jitter - right? A more stable and clean incoming clock would reduce the intensity of these changes of Si frequency and thus, SQ would improve. The time constant of the digital PLL is said to be several seconds (30? but I doubt it seeing the i2c traces) and thats a bit longer than jitter 😉 But, I have never seen a statement of how deep the memory buffer is in the DAM. But if it is at least 1 sample or say 2, it is not jitter that is *passed through*.
//
"And since the front end of the DAM tracks the source then the DAC is affected from the jitter" - well I would not call it jitter what is passed through. Jitter is something less than a 10th of a clock cycle. What happens here I believe is that the constant alterations of Si frequency is what is effecting the sound. Thats something else on a whole other scale than jitter - right? A more stable and clean incoming clock would reduce the intensity of these changes of Si frequency and thus, SQ would improve. The time constant of the digital PLL is said to be several seconds (30? but I doubt it seeing the i2c traces) and thats a bit longer than jitter 😉 But, I have never seen a statement of how deep the memory buffer is in the DAM. But if it is at least 1 sample or say 2, it is not jitter that is *passed through*.
//
Sorry but it's not so.
The synchronization is executed inside the FPGA.
Please, take a look at the DAM diagram of the DAM I have published, the LRCK comes directly from the FPGA (yellow lines).
The Silabs provide the clock to the FPGA and then the FPGA provides the latch to the 595s.
The micro tracks the input frequency and then adjusts the output frequency of the Silabs using its PLL (VCXO).
Call it jitter, call it phase noise, call it frequency alterations (in frequency domain I would call it phase noise).
This inevitabily affects the latch of the DAC.
The synchronization is executed inside the FPGA.
Please, take a look at the DAM diagram of the DAM I have published, the LRCK comes directly from the FPGA (yellow lines).
The Silabs provide the clock to the FPGA and then the FPGA provides the latch to the 595s.
The micro tracks the input frequency and then adjusts the output frequency of the Silabs using its PLL (VCXO).
Call it jitter, call it phase noise, call it frequency alterations (in frequency domain I would call it phase noise).
This inevitabily affects the latch of the DAC.
Sure thats how it works in 1021 - but jitter definition is timing errors < 10UI (unit interval).
//
//
Yes, jitter is in time domain while phase noise is in frequency domain.
Although they are strictly correlated by a precise equation.
The jitter requires a defined integration bandwidth to be calculated, while the phase noise is an absolute value.
That's the reason why I prefere phase noise instead of jitter.
Although they are strictly correlated by a precise equation.
The jitter requires a defined integration bandwidth to be calculated, while the phase noise is an absolute value.
That's the reason why I prefere phase noise instead of jitter.
Last edited:
Yupp!
Same thing, 2 different angles. PN is the more informative one - agree!
Just so we don't lose grip of the *time* differences between sample rate and jitter in a typical DAC context... 1000 times and more...
//
Same thing, 2 different angles. PN is the more informative one - agree!
Just so we don't lose grip of the *time* differences between sample rate and jitter in a typical DAC context... 1000 times and more...
//
I don't care for movie sound either. I think it is the most simple and elegant way.
Just to confirm you were wrong.
Reference DAC Module - Discrete R-2R Sign Magnitude 24 bit 384 Khz
The audio world has become the world of fairy tales.
Sorry but I don't agree.
I don't see any reason to sacrifice performance in the name of elegance.
And it's simple for the designer only since he saves 10 EUR for the ISSI SRAM.
Cool - then no jitter (as per my definition above) can come thru.
SQ impact is due to clock adjustments... must be.
//
SQ impact is due to clock adjustments... must be.
//
Last edited:
Not quite like that, you forgot the jitter of the SI514 used to generate the latch inside the FPGA.
"come thru" NB!
Yes - jitter comes from many sources. But in the DAM case, not from the incoming side, not with 1 ms buffer. Its from:
- adjusting the Si
- the Si intrinsic jitter
- FPGA
- etc
but not from the i2s/coax/toslink source.
It's not even jitter that striggers the Si adjustment, its wander really.
//
Yes - jitter comes from many sources. But in the DAM case, not from the incoming side, not with 1 ms buffer. Its from:
- adjusting the Si
- the Si intrinsic jitter
- FPGA
- etc
but not from the i2s/coax/toslink source.
It's not even jitter that striggers the Si adjustment, its wander really.
//
Last edited: