But what exactly is improper? Fwiw Ian's fifo behaves in exactly the same manner from my subjective POV. Is it the fifo really?
Do you agree the FIFO operates in a different time domain?
I assume you agree, otherwise I'm losing my time.
Therefore the FIFO operating in a different time domain (asynchronous) means that it uses a different clock, not the one of the source.
Firstly data are stored and then all the signals (data, BCK, LRCK) are reclocked with a different master clock.
This means that (theoretically) there is no relation between the signals before and after the FIFO.
In other words the source (theoretically) should be isolated.
That's the reason why any changing of the components before the FIFO (theoretically) shouldn't affect the output of the FIFO.
So, why the output of the FIFO is affected by the source?
Again the answer is very simple: the source is not well isolated by the FIFO.
And why?
There are several reasons, I have listed them several times.
Is it possible to solve the issue?
Yes, and again I have pointed out several times the way.
I assume you agree, otherwise I'm losing my time.
Therefore the FIFO operating in a different time domain (asynchronous) means that it uses a different clock, not the one of the source.
Firstly data are stored and then all the signals (data, BCK, LRCK) are reclocked with a different master clock.
This means that (theoretically) there is no relation between the signals before and after the FIFO.
In other words the source (theoretically) should be isolated.
That's the reason why any changing of the components before the FIFO (theoretically) shouldn't affect the output of the FIFO.
So, why the output of the FIFO is affected by the source?
Again the answer is very simple: the source is not well isolated by the FIFO.
And why?
There are several reasons, I have listed them several times.
Is it possible to solve the issue?
Yes, and again I have pointed out several times the way.
But Sören, there is a real problem. Not like it klicks or pops but it does not filter out the characteristics of the source - and thats a problem. You are constantly changing the clock driving the ladder.
Ian is totally blocking. It has a real delay of around a second. But Ian doesn't change the outgoing clock depending on the incoming speed - the outgoing clock is fixed. It has a very deep buffer. Ian has a deviation budget to digest the clock ppm deviations allowed by the s/pdif standard - hence the long delay. And thats high end audio solution.
Sören optimise on video audio being in lip sync.
I own both. I have measurements in the DAM I2C bus to the clock showing the constant alterations of frequency to follow the input clock - this is due to the shallow buffer in the fifo I presume.
//
Ian is totally blocking. It has a real delay of around a second. But Ian doesn't change the outgoing clock depending on the incoming speed - the outgoing clock is fixed. It has a very deep buffer. Ian has a deviation budget to digest the clock ppm deviations allowed by the s/pdif standard - hence the long delay. And thats high end audio solution.
Sören optimise on video audio being in lip sync.
I own both. I have measurements in the DAM I2C bus to the clock showing the constant alterations of frequency to follow the input clock - this is due to the shallow buffer in the fifo I presume.
//
Last edited:
TNT, please stop. We have been over how the dam1021 FIFO and clocking works. I have my opinions that it's fine and works as it should. Yes, the dam1021 clocking is not perfect, but more than good enough. Anybody disagree don't need to purchase a dam1021, they can upgrade to the dam1121 or dam1941, or they can make their own.
You might have seen the testing of the new dac2541 over at SBAF, the FIFO and clocking works exactly the same as all my other dams and dacs, except for the hardware differences (si570 directly to the R-2R networks via the LVC74 flipflops), and they seems to be happy for the results, same are the customers so far....
You might have seen the testing of the new dac2541 over at SBAF, the FIFO and clocking works exactly the same as all my other dams and dacs, except for the hardware differences (si570 directly to the R-2R networks via the LVC74 flipflops), and they seems to be happy for the results, same are the customers so far....
I have searched this thread but didn't find you listing the reasons and solutions. Could you please point me there? Thanks!
I can change the source clock with a mouse click, and it reliably changes the sound of the DAM1021. Like I wrote before, making small changes to the AES/EBU signal path, even using the recommended receiver chip and the correct termination resistor also results in audible changes.
How can it work as it should if the quality of the clocking can easily get past the buffer?
The way pro audio converters usually do it is to analyze the incoming digital audio or WC signal for a few seconds and then calculate the correct clock speed and reproduce it. The Lynx Aurora takes more than a minute - before it actually locks it just passes through the incoming clock.
Increasing the buffer size without going to excessive levels would be another way to do it. Why not let us decide the buffer size / clocking behaviour via umanager?
I'm almost done building my 32-channel DAM1021 based converter, it's a shame that the incoming clock does degrade the signal quality...
Last edited:
My DAM1021 receives digital audio via the AES/EBU output of an RME sound card. This sound card can either use an internal clock source or sync to an incoming clock. In theory their PLL is supposed to be transparent, but it isn't.
If I set the sound card to sync to the incoming clock its outgoing clock is still affected by that. So different clock sources to the RME card (usually different AD converters) result in audible differences with many DACs, not only the DAM1021.
The easiest and fastest way to hear a difference is by switching between an external AD converter as the master clock and the internal RME reference. There is even a difference between "internal" and a different source that is not actually connected, probably because the sound card having to "listen" for other potential incoming sources does result in worse jitter performance.
The data sheet does list minimally better jitter figures for the internal clock (<800 ps) vs. the external clock (<1 ns).
It does always sound best on the internal clock. I currently have no way of feeding the DAM1021 a truly low phase noise clock, but I can imagine that it would sound quite a bit better still.
Apparently you can find the time and space to expound upon generalities, but the "several reasons" are impossible to relist
I have tried placing Ian's fifo in front of the 1021. It certainly changes the sound a bit but not in a way that persuaded me it needed to stay. It certainly does not negate the effects of usb cables. And yes, i use it with galvanic isolation and galvanically separated power supplies.
I believe you have answered yourself about the reasons in your latest posts, anyway there are at least two major reasons:
- the Si570 is not a low phase noise oscillator, its datasheet shows clearly that it's a high phase noise device, maybe good for telecommunication but bad for digital to analog conversion
- the PLL tracks continuously the input, that means the timing error of the source are reflected to the output. Moreover this means that it's not really a FIFO, since the output folllows the input. Practically the system is almost synchronous, while with a FIFO the source and the DAC should operate in different time domains
How to solve the issue?
Redesigning the front end from scratch:
- implement a large buffer by using SDRAM to get a real FIFO
- use a pair of really low phase noise fixed oscillators (one for each sample rate family) and dividers
- use relays instead of multiplexer to switch between the two sample rate families
- use optical isolation for the non crucial signals like Data and Bck
- generate the LRCK directly from the master clock avoiding it crosses the FPGA
- implement a FIFO slaved to the LRK
This could be a starting point to get the DAC independent from the source.
Apparently you can find the time and space to expound upon generalities, but the "several reasons" are impossible to relist
I have tried placing Ian's fifo in front of the 1021. It certainly changes the sound a bit but not in a way that persuaded me it needed to stay. It certainly does not negate the effects of usb cables. And yes, i use it with galvanic isolation and galvanically separated power supplies.
I have listed the reasons, here you can find the cure
Building the ultimate NOS DAC using TDA1541A
Read pure5152 (post #126) comparison between coax and USB. Using USB, the DAM clocks are no longer adjusted and left alone, letting the USB system do the asynchronous buffering job....
Soekris DAC2541 Review And Measurements | Page 7 | Super Best Audio Friends
... maybe it's bit errors? (Hint: no!)
//
But most of us are not primarily after a better oscillator but a more (totally) isolating FiFo. That hasn't changed between the models as the fifo works the same i.e. the same time constants and memory depth.
Re-clocking before the ladder is an entry ticket.
//
Last edited:
A large buffer defeats the purpose of a real time converter. And I don't see why it would be necessary, TNT has laid it out well before.
Anyway, since the DAM1021 has a clock output it should be possible to make it the master, shouldn't it? This would eliminate problems originating in the source (since the source's clock would be slaved to the DAM1021's clock). It should then also be possible to sync multiple DAM1021's by connecting the master DAM1021's clock output to the other converter's LRck input, shouldn't it?
Anyway, since the DAM1021 has a clock output it should be possible to make it the master, shouldn't it? This would eliminate problems originating in the source (since the source's clock would be slaved to the DAM1021's clock). It should then also be possible to sync multiple DAM1021's by connecting the master DAM1021's clock output to the other converter's LRck input, shouldn't it?
Exactly, if the DAM1021 were the master the FIFO would no longer matter.
Well, you should ask Soekris to remove the FIFO.
I believe that's not the right way but it's a question of point of view.
Maybe you should also ask for a better oscillator to operate in synchronous mode because the Si570 is a poor device.