I've never tried it, but I hope that's true. I would expect less corrections to result in better performance. A longer period of measuring the incoming clock's speed should make it possible to reduce the corrections to a minimum. I frequently get flanging mixing the phase inverted DAAD file with the original, indicating diverging clocks. Other manufacturer's DACs with reclocking schemes don't have this problem at all.
I spent quite a lot of money and time on this. I will see how it pans out first.
No - I dont belive this. Its not true. If it where, banking, radar and internet pron would not work.
Thats analog - here we talk code and data.
Sorry - try again 🙂
//
Thats analog - here we talk code and data.
Sorry - try again 🙂
//
Last edited:
I believe we know, at least from the empirical point of view.
Many users have replaced the Crystek with better oscillators in their devices and no one has come back since.
Ian did install the SI570 in the early versions of his FIFO, but he discontinued the option almost immeditely.
And it was the SI570 while the DAM has the poorer SI514.
Unfortunately it's just so.
Even every trace on the PCB is an antenna, it transmits and receives.
And it's not just analog, since the VCXO runs at 150 MHz.
Have you seen the oscilloscope plot I have published about Ian's FIFO?
There is a clear crosstalk between BCK and LRCK, and Ian uses a lot of RAM in his FIFO.
I believe the problem is just that, they are RF devices rather than analog devices, and this needs a different approach.
I understand, but unfortunately I believe that the DAM is not best choice for your application.
And I have several doubts that the designer will help you.
LS, as I understand it you are running multiple channels from DAW such as Protools, through SPDIF into DACs and mixing 'out of the box' in analog
domain. Is this correct?
The flanging is most likely multiple PLL'ed clocking schemes in parallel that are independently 'smoothing' the clock extracted from SPDIF. If the PLL low
pass filter is too low and they are not synced, they will drift from each other.
I would suggest that a USB connection between your DAW and DACs is a better solution BUT there are a few ways to run USB->I2S and you need
asynchronous type connection where a fixed clock is at DAC end and data is 'pulled' through. Also, all of the DACs must run off that same clock.
The FIFO with a fixed independent DAC clock should also work perfectly as long as you can tolerate the 1 sec or so time delay in your work flow.
I think the main issue here is you don't clearly understand the differences between these various approaches and they are confusing you. I would
recommend spending some time to get a clearer understanding of how these various approaches apply to your specific application before moving forward
with anything.
TCD
Terry,
It would be nice, but it's not possible with with the DAM1021 since every DAC has its clock on board and there is no way to sync them.
No way to get them slaved to a single master clock, neither to pull data from the source.
Unless the designer will throw out the on board VCXO and provides input for external clock.
But he has already said NO to this request.
It would be nice, but it's not possible with with the DAM1021 since every DAC has its clock on board and there is no way to sync them.
No way to get them slaved to a single master clock, neither to pull data from the source.
Unless the designer will throw out the on board VCXO and provides input for external clock.
But he has already said NO to this request.
The ultimate goal is indeed to mix OTB via the DAM1021s. But I'm not there yet. As I wrote in my post (maybe read more carefully next time), the flanging comes with an external ADC clocking the sound card that in turn clocks the DAM1021. The round trip file lined up with the phase flipped against the (unconverted) original produces various degrees of (unpredictable) flanging with the DAM1021, but not with with every other DAC I've used, all of them employing various PLL / reclocking schemes.
According to Soeren several DAM1021s in parallel should all be in sync as long as they get their signal from the same clock (which is the case in my setup). I have not tested this yet.
No, a delay of that magnitude is not acceptable in a real time multichannel studio application.
And please try to keep patronizing comments based on unfounded assumptions to yourself next time, they have no place here. Thank you! 🙂
According to Soeren several DAM1021s in parallel should all be in sync as long as they get their signal from the same clock (which is the case in my setup). I have not tested this yet.
No, a delay of that magnitude is not acceptable in a real time multichannel studio application.
And please try to keep patronizing comments based on unfounded assumptions to yourself next time, they have no place here. Thank you! 🙂
From how I understood Soeren's answer it would actually be possible with changes to the firmware. After all, there are inputs on the board that would allow to use a WC input seperate from the AES/EBU / S/PDIF signal. But yes, he doesn't want to do that.
I believe this shouldn't be too difficult: an additional small micro into the I2C-line, controling the Si514 based on calculated moving averages from the original I2C commands.
So it's a broken system from a multi channel POV if you want the highest
quality.
TCD
That's a shame so it's worth persevering and trying to find the best solution.
I did a search but couldn't find answer -> what card(s) are you using for AES
OP from computer? Do they have ability to slave off WC input? If so, there is
possibility you could run DACs off a fixed distributed clock and divide down a
WC to send back to card. If you work in one sample rate, say 48k / 96k then
you can use one VHQ clock to run all the DAC's. This is the optimum way to do it.
TCD
There are of course crosstalk in the analog domain in a digital electronic environment but as long as the data is in the digital domain, its integrity is secure - if it is not an extremely poor designed HW. I know you seek explanations for windmills but these do not reside in memories and buses etc. If you think so you are on the wrong track. It all comes down to the point of conversion - thats where it happens and thats where it needs to be law & order.
If clock HF creeps into your power feed lines (and what not), you cant blame the logic ans size of a fifo - can you? Thats something else.... thats an analog problem in an digital environment. If one cant sort out what is what, finish is distant.
//
@Andrea
I would find it very informative if you would already now open a separate thread about your two future DACs. This project here with the upgrade of the DAM is of course very interesting and it is also a certain "proof of concept" of your FIFO Lite.
I think the basic concept of Soekris is very good. I mean less the technical implementation. The points of criticism are well known. But rather these points, which are expandable for the individual - as well as OEM moderately:
- Oversampling (whereby there is also an alternative solution for the NOS friends).
- R2R
- Balanced Output
- Voltage Output
- Output selectable (Tube, Transistor, ...)
- Digital VolumeControl
- x Input Selectors
If the operability (Volume, Selector...) of your DAC is made possible by own software adaption, it would be perfect. So I am very curious how your future concept of the top DAC will look like.
I would find it very informative if you would already now open a separate thread about your two future DACs. This project here with the upgrade of the DAM is of course very interesting and it is also a certain "proof of concept" of your FIFO Lite.
I think the basic concept of Soekris is very good. I mean less the technical implementation. The points of criticism are well known. But rather these points, which are expandable for the individual - as well as OEM moderately:
- Oversampling (whereby there is also an alternative solution for the NOS friends).
- R2R
- Balanced Output
- Voltage Output
- Output selectable (Tube, Transistor, ...)
- Digital VolumeControl
- x Input Selectors
If the operability (Volume, Selector...) of your DAC is made possible by own software adaption, it would be perfect. So I am very curious how your future concept of the top DAC will look like.
Of course I assume bit perfect in the digital domain.
Well, in a R2R PCM DAC, if we leave out the accuracy of the ladder network, the key of the digital to analog conversion is the swithing timing.
In the DAM1021 is the latch signal provided to the pin 12 of the 595 batteries used as the DAC switches.
DATA and bit clock don't matter, the only purpose is to feed the registers of the 595s, so they don't affect the conversion.
I believe we agree on this.
Therefore you need the latch clock as clean as possible. This means:
- you have to provide a very low phase noise latch clock (or very low jitter if you prefere)
- you have to avoid the latch clock to be affected by others RF signals
So the question is: does the DAM1021 meet the above requirement?
The answer IMHO is no.
It uses a poor VCXO, so the first requirement is not met.
The latch clock shares the ground of the other signals on all the PCB, from the input (after the Silabs isolators that generate RF themselves) to the output.
Anything could cross the clock domains.
So I think limiting the operation of the PLL that tracks the input will not solve the issue, the DAM will remain source dependent.
As I said Ian use a lot of memory in his FIFO, there is no PLL tracking the input and provides the input for external fixed oscillators.
Despite all this, although using state of the art oscillators, the FIFO is still source dependent, as reported from many users.
I have measured the phase noise of the clock signals before and after the FIFO. Although there is a clear improvement the curves are somewhat related, like if something from the input was reflected to the output.
And the starting condition of the DAM is far worse than that of Ian's FIFO buffer.