id prefer to have all i2s under 20mm lengths short as possible and not worry about the shielding or separate return paths ive never found a need for it, but id keep transformers etc far from signal lines
usb cables dont seem to suffer near as much
So I was using about 18cm I2S wires, just your typical unshielded pin header type ribbons. After reading this conversation I had a go at significantly hardening the I2S paths using about 8cm of coax for each line.
Nope, I certainly couldn't tell any difference either...
75mm and over is noticeable unshielded
maybe the coax helps
So I was using about 18cm I2S wires, just your typical unshielded pin header type ribbons. After reading this conversation I had a go at significantly hardening the I2S paths using about 8cm of coax for each line.
Nope, I certainly couldn't tell any difference either...
I (understand) expect the Soekris reclocks, so any slight loss of synch is recovered.
In Philips original designs, the I2S was often long upto the upsampler that reclocked its output, then rather short to the DAC chips, (I might observe having demolished many boards that where the TDA1543 would allow more distance, the TDA1541 often have the SAA7220 almost touching the DAC chip).
It does more than "re-clock". It writes data into a short buffer (don't recall size but it seem to be able to digest some 30-60 seconds of clock differences)) and adjusts the clock if run out of memory. Re-clocking is made on a cycle per cycle basis using just the registers in the a flip-flop.
So worst case scenario is a clock adjustment every minute. Between these adjustments, jitter or wander emanating from the source can simply not happen as all data is read out from a memory, completely isolating the incoming line from the feed towards the conversion engine. Typically this should happen *much* more seldom, the above is almost an error situation, probably a couple of times at startup and then at temperature changes etc. If this adjustment can be heard or not I wonder...
It would be nice to understand the typical behaviour - Sören if you publish your test result for the buffer solution it would be helpful for some of the discussions here. Facts and knowledge is always a good thing.
//
So worst case scenario is a clock adjustment every minute. Between these adjustments, jitter or wander emanating from the source can simply not happen as all data is read out from a memory, completely isolating the incoming line from the feed towards the conversion engine. Typically this should happen *much* more seldom, the above is almost an error situation, probably a couple of times at startup and then at temperature changes etc. If this adjustment can be heard or not I wonder...
It would be nice to understand the typical behaviour - Sören if you publish your test result for the buffer solution it would be helpful for some of the discussions here. Facts and knowledge is always a good thing.
//
Last edited:
It does more than "re-clock". It writes data into a short buffer (don't recall size but it seem to be able to digest some 30-60 seconds of clock differences)) and adjusts the clock if run out of memory . Re-clocking is made on a cycle per cycle basis using just the registers in the a flip-flop.
So worst case scenario is a clock adjustment every minute. Between these adjustments, jitter or wander emanating from the source can simply not happen as all data is read out from a memory, completely isolating the incoming line from the feed towards the conversion engine. Typically this should happen *much* more seldom, the above is almost an error situation, probably a couple of times at startup and then at temperature changes etc. If this adjustment can be heard or not I wonder...
It would be nice to understand the typical behaviour - Sören if you publish your test result for this solution it would be helpful for some of the discussions here. Facts and knowledge is always a good thing.
//
So worst case scenario is a clock adjustment every minute. Between these adjustments, jitter or wander emanating from the source can simply not happen as all data is read out from a memory, completely isolating the incoming line from the feed towards the conversion engine. Typically this should happen *much* more seldom, the above is almost an error situation, probably a couple of times at startup and then at temperature changes etc. If this adjustment can be heard or not I wonder...
It would be nice to understand the typical behaviour - Sören if you publish your test result for this solution it would be helpful for some of the discussions here. Facts and knowledge is always a good thing.
//
In another soekris-dam1021 related threat was mentioned that the power supply part could be significantly improved.
Unfortunately, it has always remained only with the partly rude reproaches / references. I would be interested in the thoughts of the developer.
Socialized by the English HIFI industry I believe in the positive influence of good power supplies.
Could these be development steps for V5 board?
other questions are these on and off pops history within V4?
Unfortunately, it has always remained only with the partly rude reproaches / references. I would be interested in the thoughts of the developer.
Socialized by the English HIFI industry I believe in the positive influence of good power supplies.
Could these be development steps for V5 board?
other questions are these on and off pops history within V4?
Last edited:
dam1021 rev5 will have just small updates, mostly for logistics and manufacturing reasons, I decided to stay inside current mechanical constrains.
The jfets to clamp the outputs during power up/off was added in rev2.
Physical, Yes. PCB Layout, No. Major work to make space for flipflops between the FPGA and the Resistors Networks. So not this time.... For the ones that see a problem there, there's always the dam1121....
Btw, I should get some Si544 soon, just got the shipping notification.... Seems very interesting and are pin compatible, but they're programmed a little differently and don't seems to be that much better than a Si570 in the areas that matter for Audio....
All depends on pricing for the Si544/Si549, still waiting for that. As most should know by now, I believe that the Si570 is more than good enough, even a Si514 is probably more than good enough, at least people seems to like the new dac1321 a lot and that one have the Si514.... But the new Si Labs parts might be needed for sales pitches....
Last edited:
If we are pitching blue sky updates - I think there is excellent scope for an alternate firmware to use the ladder as a DSD decoding filter, a moving average filter like the Signalyst DSC1. This is - I believe - the way the Holo audio DSD decoder works.
Just a thought! I'm loving my 1121 based dac as is.
Just a thought! I'm loving my 1121 based dac as is.
I have plans for firmware, but not in the near future....
That would be the dam1121....
I consider my DSD decoding better than the DSC1 or Holo, I do it in perfectly in the digital domain, that way I can use the digital volume control. Anyway, DSD is delta-sigma modulation and the whole point of a R-2R DAC is to avoid delta-sigma....