The error in your calculation: According to Soeren, the DAM1021 has 1 millisecond of buffer, that would make it 500 microseconds in either direction. Not nanoseconds, you are off by an order of magnitude [EDIT: Make that 3 orders], I think. 20 samples at 44.1 khz are 0.4535147392290249 ms.
Last edited:
Here my attempt for calculating the delay ;-)
The y-axis is deviation of the target input frequency (22.57892MHz). Easier to read the frequencies at the dashed red line, the values appear in the table below. The difference of the two traces at that line is about 5.5Hz. So your green line falls about 5.5Hz in 10000s.
For a constant frequencies with a (constant) difference of delta_f, you get delay of about delta_f / f * t.
But here the frequency difference increases with the time i.e. we have delta_f(t)=5.5Hz/10000s * t (if we put the zero of the coordinate system suitable and stick to the part of the green line).
Thus the delay is the integral of "delta_f(t) / f *t dt" in the range 0...t
So the delay d is: d = 1/2 5.5Hz/22MHz/10000s t^2
=1.25 *10^{-11}/s *t^2
Next: 20 sample at 44.1kHz take 453 mu seconds ;-)
So 4.53*10^{-4}s = d and thus
t= sqrt(d/1.25 *10^{-11} * s)
= sqrt(4.53*10^{-4}s/(1.25 *10^{-11} *s)
= sqrt(3.5*10^7)s
= 6019s
The y-axis is deviation of the target input frequency (22.57892MHz). Easier to read the frequencies at the dashed red line, the values appear in the table below. The difference of the two traces at that line is about 5.5Hz. So your green line falls about 5.5Hz in 10000s.
For a constant frequencies with a (constant) difference of delta_f, you get delay of about delta_f / f * t.
But here the frequency difference increases with the time i.e. we have delta_f(t)=5.5Hz/10000s * t (if we put the zero of the coordinate system suitable and stick to the part of the green line).
Thus the delay is the integral of "delta_f(t) / f *t dt" in the range 0...t
So the delay d is: d = 1/2 5.5Hz/22MHz/10000s t^2
=1.25 *10^{-11}/s *t^2
Next: 20 sample at 44.1kHz take 453 mu seconds ;-)
So 4.53*10^{-4}s = d and thus
t= sqrt(d/1.25 *10^{-11} * s)
= sqrt(4.53*10^{-4}s/(1.25 *10^{-11} *s)
= sqrt(3.5*10^7)s
= 6019s
Sounds about right. More than 1.5h. And not too far removed from my own tests with the Lavry Gold as clock source.
I knew it!
So I was off 2 magnitudes - you guys are so picky 🙂 (+ a factor 2 🙂)
//
So I was off 2 magnitudes - you guys are so picky 🙂 (+ a factor 2 🙂)
//
Last edited:
Nice measurements !
Maybe doing clock adjustments based on the moving average could be an enhancement.
It's my understanding that the lowpass filter used already does that. E.g., if the filter cutoff were were at 0.1 Hz, a moving average over 10 seconds would result.
Maybe Soeren can shed more light on this.
Not to distract from the discussion on clock adjustments. But I noticed that the x8 I2S playback on my dual-mono setup still has some problems - the sound is significantly shifted to the right (left channel delay?) compared to x1, x2, x4 playback... This has to be a dam1021 issue still with at least one of the boards. There is also a bit of occasional pop and crackle in the right channel... Maybe I should leave it off for a while longer?
Also, @soekris can we get an explanation of this behavior?... Is there something I could've done to prevent this type of damage to the boards, or is this actually a vulnerability of the dac design? I do hope to be able to use the USB/I2S input without constantly worrying about ESD in the future.
Also, @soekris can we get an explanation of this behavior?... Is there something I could've done to prevent this type of damage to the boards, or is this actually a vulnerability of the dac design? I do hope to be able to use the USB/I2S input without constantly worrying about ESD in the future.
Btw I finally got the EMU0404 SPDIF out to work... Apparently SPDIF out only works under ASIO mode from USB input, and then in addition I need to configure ASIO channel mapping to assign the SPDIF L/R outs instead of the analogue L/R outs. I've been able to get x2 outputs to work, but not x4. Anyways, this means that my EMU0404 probably isn't broken and just has a distinctive sound signature is all.
I know everyone probably hate me right now for my OT content. But I need to post this update. I finally found some time to try level-matching the EMU0404 and the dam1021. Unfortunately, it might be hard to conduct a reliable double-blind test because the EMU0404 has unbalanced channel levels. I set the dam1021 balanced output to be -19db and it's exactly 0.289v in both channels when a 0db 1khz sine wave is applied (plus my EQ settings). On the other hand, the EMU0404 left channel has a higher output level than the right; I managed to get 0.299v L and 0.280v R with the same Toslink input. It's not immediately perceptible but it seems more than likely that I will be able to pass an ABX test on the channel imbalance issue alone. It's a bit unfortunate since the output impedance of the two devices are very closely matched (20 and 22 Ohms).
In addition, the sonic difference, if there is any, might also be more subtle than I previously thought. The night and day difference from the EMU0404 is definitely partly due to my EQ settings not being correctly applied to the new device when my dam1021 first malfunctioned. It could easily explain the additional harshness from the EMU0404, and perhaps also the lack of presence, but I'm not sure to what extent.
I honestly felt that there was a bigger difference even after I corrected for the EQ issue, but of course by that point I had already had plenty of preconceptions about how the EMU0404 should/might sound compared to the dam1021. It's quite a disappointment that a sighted level-matched test provides limited support for a perceptible difference between the two devices. But then maybe we can all enjoy music to the fullest extent with just onboard PC audio, which isn't a bad conclusion in and of itself 🙂
In addition, the sonic difference, if there is any, might also be more subtle than I previously thought. The night and day difference from the EMU0404 is definitely partly due to my EQ settings not being correctly applied to the new device when my dam1021 first malfunctioned. It could easily explain the additional harshness from the EMU0404, and perhaps also the lack of presence, but I'm not sure to what extent.
I honestly felt that there was a bigger difference even after I corrected for the EQ issue, but of course by that point I had already had plenty of preconceptions about how the EMU0404 should/might sound compared to the dam1021. It's quite a disappointment that a sighted level-matched test provides limited support for a perceptible difference between the two devices. But then maybe we can all enjoy music to the fullest extent with just onboard PC audio, which isn't a bad conclusion in and of itself 🙂
In other news, 8x I2S mode started to work properly again on my dam1021 lol. @soekris Can we please get some ideas on how to prevent ESD/EMI damage to your DACs in I2S mode?
I also second the requests to fix the clock drift compensation code. The results simply look amateurish compared to those of other implementations, such as the Amanero...
I also second the requests to fix the clock drift compensation code. The results simply look amateurish compared to those of other implementations, such as the Amanero...
Last edited:
It will be interesting to know how many DAMs have suffered such damage. I have a nagging suspicion it is not a common failure. Could it be just one? Mine has shown a remarkable resilience towards my attempts to kill it and it doesn't even have galvanic isolation on the i2s lines any more.
At the very least, it is two dam1021-rev4 boards that have suffered the same exact damage being connected in dual-mono configuration. To me, it seems highly deterministic and not a product of random chance. Both failed at the exact same time, with basically the exact same symptoms, and also recovered from the damage (at least functionally speaking) around the same time. To be clear, there are some differences in their behavior, but the similarities are far greater.
I wasn't trying to damage it. It was sitting in a grounded and conductive metal box, and I was at least 3 feet away. The USB input cable also has multiple ferrite beads near the Amanero/dam1021. I felt that it was supposed to be pretty safe from a scientific perspective.
EMI/ESD damage could also accumulate over time. This is the first time I've had any problem with the dam1021 over the last 3-4 years.
Btw, I think I might've fixed the PC monitor signal dropout problem by replacing the HDMI cable with a slightly better quality one. Turns out you can't trust the $1 HDMI cables on eBay after all 🙂 To be fair, I also had the same issue with a quality 4k 60hz lightning to HDMI adaptor, but no issues with lightning to mini-DP adaptor from the same company, so I assumed maybe the Dell monitor was just susceptible to ESD under HDMI mode, hence why I waited so long to replace the HDMI cable... I can't say for sure the problem is completely gone though bc humidity has gone up a little in the last few weeks, but it is surely better.
Last edited:
So I double checked and my PC actually grounds everything to earth. I thought I didn't ground the USB signal at the DAC but there is a switcher between the DAC and the PC, which also terminates the shield to ground (I specifically lifted the shield pin of the USB socket on the Amanero). This created a ground loop within the USB cable which may have exacerbated the problem, since the cable is 10ft long. However, I would think that the induced voltages would not affect anything outside of the loop itself. Perhaps I was wrong? I've now made sure that the USB shield is only terminated to ground at the PC. @soekris why has this taken so long for you to explain?... I thought you designed communication devices for a living before all this...
Please, let me know if it's better for me to actually ground the USB shield at both ends (which means connecting the USB shield/ground to the DAC chassis, with a ground loop breaker between that and dam1021 ground) like most manufacturers seem to do by default...
Please, let me know if it's better for me to actually ground the USB shield at both ends (which means connecting the USB shield/ground to the DAC chassis, with a ground loop breaker between that and dam1021 ground) like most manufacturers seem to do by default...
Last edited:
There is no problem with the dam1021, there is nothing to explain, I have sold several thousand without problems, so maybe its your end that's the problem.... Almost all issues have been user issues.
Well maybe it is something on my end that was the problem, but what could it be?? That’s the kind of explanation I was looking for. I implemented my build based on all the best practices in this thread and have asked questions when I wasn’t sure. Do let me know.
Hey Soeren, have you seen the measurements by zfe? What do you think - can you tweak the clocking so phase noise is lower?
He should just get one of the guys here to sign an NDA and write the code for him - can't take much more than a full evening... (provided the code isn't too hard to understand) Maybe FPGA stuff has a higher learning curve, but it's still just a piece of code that's supposed to do something pretty simple and has been done by others many times before... How hard can it possibly be