Replacing oscillator - was this on the Ian buffer?
The DAM we know alters the "clean clock side" so we don't have to discuss that. I don't call that "crosstalk".
//
The DAM we know alters the "clean clock side" so we don't have to discuss that. I don't call that "crosstalk".
//
"I have experienced myself replacing the oscillator of the source with a better one (not a state of the art clock) and the sound improved drastically."
Wouldn't crosstalk worsen things? I have a hard time thinking that a very good clock leaking into a worse clock (on the clean side) would improve the worse clock... or?
//
Wouldn't crosstalk worsen things? I have a hard time thinking that a very good clock leaking into a worse clock (on the clean side) would improve the worse clock... or?
//
I meant improving the oscillator of the source not the oscillator of the FIFO. From a cheap chinese oscillator to the old Pierce TWTMC-P, nothing special.
Call that as you want, I call that "source dependent" that means non optimal isolation between the two time domains.
I don't know how the issue comes from, if it was my design I would redesign the architecture from scratch.
I think you agree a properly isolated asynchronous reclocker cannot be affected from the source.
I understood that - the clock driving the e.g. i2s into the FIFO. But how can a better incoming clock improve on a bad clock inside a FIFO? Via crosstalk? Impossible.
How is that possible...?
Yes I agree on that.
//
How is that possible...?
Yes I agree on that.
//
In the FIFO was installed a state of the art oscillator (phase noise published) while the FIFO output was not so state of the art.
How can is it possible?
Take a look at the FIFO architecture (both devices).
How can the source affects the output of the FIFO?
Take a look at the FIFO architecture (both devices).
#9540: I have experienced myself replacing the oscillator of the source with a better one (not a state of the art clock) and the sound improved drastically
#9543 "I meant improving the oscillator of the source not the oscillator of the FIFO. From a cheap chinese oscillator to the old Pierce TWTMC-P, nothing special."
but now:...
#9545 "The worse clock were in the source not in the FIFO,"...
Sorry - I'm confused...
//
#9543 "I meant improving the oscillator of the source not the oscillator of the FIFO. From a cheap chinese oscillator to the old Pierce TWTMC-P, nothing special."
but now:...
#9545 "The worse clock were in the source not in the FIFO,"...
Sorry - I'm confused...
//
The FIFO buffer had always the old Driscoll oscillator TWTMC-D with SC-Cut crystal at 11.2896 MHz.
The chinese SD card player with I2S output came with a cheap 22.5792 MHz oscillator.
Then the cheap oscillator was replaced with the old Pierce oscillator TWTMC-P with AT-Cut crystal at 22.5792 MHz and the result was clearly improved.
This means the FIFO is source dependent, it does not act a good isolation between the time domains.
If it provided the proper isolation I should not hear any difference replacing the oscillator in the source since the FIFO is asynchronous.
And if you ask me again the reasons I will answer again I dont' know, ask the designer.
The chinese SD card player with I2S output came with a cheap 22.5792 MHz oscillator.
Then the cheap oscillator was replaced with the old Pierce oscillator TWTMC-P with AT-Cut crystal at 22.5792 MHz and the result was clearly improved.
This means the FIFO is source dependent, it does not act a good isolation between the time domains.
If it provided the proper isolation I should not hear any difference replacing the oscillator in the source since the FIFO is asynchronous.
And if you ask me again the reasons I will answer again I dont' know, ask the designer.
Yes, but it is so strange - a fifo is supposed to turn a bad incoming clock into into a better one. Now you say it may also work in the opposite way - if you have a "bad" design fifo!? Like a better clock always wins somehow irrespectively where it is placed - if its a fifo with crosstalk? Sounds fishy but yes, I bring it up with the designer - maybe.
//
//
No, you have not understood, the FIFO with better clock improves the performance of a bad source clock, but not as what expected.
A numeric example just for reference.
Time 0, initial condition: the performance of the source clock is 2/10, the performance of the FIFO clock is 9/10, the FIFO output performance is 5/10.
Time 1, source clock improved: the performance of the source clock is 6/10, the performance of the FIFO clock is 9/10, the FIFO output performance is 7/10.
Regardless of the source clock quality one expects the FIFO output performance 9/10 like the performance of the FIFO clock (or better since the master clock is divided down several times).
On the contrary the FIFO output performance never reachs the performance of its master clock.
There is an improvement but this improvements follows the quality of the source clock.
And this means the time domains are not well isolated.
A numeric example just for reference.
Time 0, initial condition: the performance of the source clock is 2/10, the performance of the FIFO clock is 9/10, the FIFO output performance is 5/10.
Time 1, source clock improved: the performance of the source clock is 6/10, the performance of the FIFO clock is 9/10, the FIFO output performance is 7/10.
Regardless of the source clock quality one expects the FIFO output performance 9/10 like the performance of the FIFO clock (or better since the master clock is divided down several times).
On the contrary the FIFO output performance never reachs the performance of its master clock.
There is an improvement but this improvements follows the quality of the source clock.
And this means the time domains are not well isolated.
Sorry Andrea, but that is all speculation on your side.... I know that my FIFO works just fine, otherwise my DACs wouldn't get those glowing reviews.... And the extremely jittery 44.1 clock from a RPi wouln't get cleaned up....
This groks with my experience with the DAM1021. I made many changes to the digital input circuitry which either improved or degraded sound quality, while at the same time making changes at the source always had a cumulative (on top) effect.
Concretely, I can definitively say that an added on AES/EBU input circuit using a MAX receiver chip, but no HP filter caps and no transformer (the AES/EBU output is already transformer balanced anyway in my case) sounds best, while setting the clocking at the RME sound card to internal sounds best. Making changes at either location will degrade SQ.
With all of the above set up right I do agree that the DAC sounds stunning, so depending on the conditions of a reviewer's setup their subjective judgement might certainly be valid.
But again, in my case and others there is less than optimal performance with conditions changed at the clock source. Thus focusing only on "glowing reviews" is just following confirmation bias. I would suggest a more inquisitive and problem oriented approach to make this product suceed.
The difference I hear with changes at the source is quite drastic in that the pinpoint accurate time and space definition of percussive instruments (e.g. conga or acoustic guitar strums), the depth of the low end, the ability to listen into the room rever etc. are instantly lost when I switch to the external clock source of the RME card. Roundtrip recordings made with a high end AD converter confirm it, too.
It might very well be (and I would hope this to be the case, since it's the easist fix) that tweaking the reclocking algorithm can mitigate the problem. May I ask again when we can expect this? It has been promised a long, long time ago now.
Soeren,
we were talking about another device not about your DAM.
I have not yet switched on my DAM1021 so at this moment I cannot say nothing about.
I have measured the other device and I will also measure your DAM1021.
About the source dependence of the DAM1021 I have never claimed anything, just some owners of the DAM claimed so in this thread.
So you have to explain to them that it's not true, not to me.
And "extremely jittery 44.1 clock from a RPi wouln't get cleaned up" is your opinion that I totally disagree.
If the different time domains are mixed up there is something wrong in the design.
As an engineer you know this.
we were talking about another device not about your DAM.
I have not yet switched on my DAM1021 so at this moment I cannot say nothing about.
I have measured the other device and I will also measure your DAM1021.
About the source dependence of the DAM1021 I have never claimed anything, just some owners of the DAM claimed so in this thread.
So you have to explain to them that it's not true, not to me.
And "extremely jittery 44.1 clock from a RPi wouln't get cleaned up" is your opinion that I totally disagree.
If the different time domains are mixed up there is something wrong in the design.
As an engineer you know this.
Last edited:
So why are you posting it here ? You should find a more appropriate forum for your speculations....
As an engineer I know my designs. There are no mixups in my designs. You just speculate, I know....
The first post about it's not mine:
"Yes, I have to admit that I'm a bit sceptical to this also but what else explanation could there be? For the DAM there is one. But for Ians buffer where there also are report on source impact - how can that be? Imagination?"
If someone asks me something usually I answer.
"The difference I hear with changes at the source is quite drastic"
"The fact that the sound quality changes with the source's properties is the only serious drawback left for me."
"It is probably not even a timing issue and just noise related."
"a_s, do you mean that it is noise from the incoming data/clock that is contaminating the new clock + data coming out of memory?"
"Yes, contamination is the only explanation that seems viable to me."
None of the above are my speculations, you have to read better before claim.
FIFO_Pi uses a 'reclocker' D-Flip Flop. Scope trace looks a lot like ground bounce of the chip caused by BCLK transitions. The bounce causes some ringing on LRCK. Don't know if its necessarily a problem for a given dac, maybe depends on the dac type. Some people use separate D-FF chips for each I2S signal to help minimize ground bounce induced cross-talk.
Last edited:
In my opinion, it is quite rude of you to come to this thread and crap all over it with your jitter fetishism. You should design your own DAC if you don’t like how this one is implemented.
I don’t prefer or care about R-2R DACs, but I don’t come to this thread to bash its design. It’s funny that you trust Soren to design the DAC but don’t think he understands how to clock it.