Just updated to 1.23, not sure if I'm being influenced by other members here, but it does sound a little odd... I'll probably go back to 1.21 until there's more clarification on this.
Btw I bought another cheap USB DAC from the same company, just to make sure that the noise issue from the last DAC wasn't a random defect. The new one, which is a slightly different model but probably uses the same underlying design, has the same noise problem. Could just be that it's using USB power instead of a separate SMPS. Maybe I'll run some more tests on it when I get the time to see if measurements can explain the obviously audible noise. The simple 1khz 0dbfs measurement has already failed to present any plausible explanation for the noise...
So far, I feel pretty confident that (properly designed) DACs do sound different. But I'll probably do a level-matched double-blind test at some point just to be sure.
Also funny that AKM apparently market their best chips with the VELVET SOUND technology, maybe it's just a coincidence that I think it's exactly what the AKM chip in the EMU0404 sound like, and not in a good way...
So far, I feel pretty confident that (properly designed) DACs do sound different. But I'll probably do a level-matched double-blind test at some point just to be sure.
Also funny that AKM apparently market their best chips with the VELVET SOUND technology, maybe it's just a coincidence that I think it's exactly what the AKM chip in the EMU0404 sound like, and not in a good way...
So member zfe has done some measurements of the clock behaviour of the four latest pre 1.24 (Rev 7 HW) FWs. Should be quite self explanatory. The insigth is that it doesnt seem to be any noticeable measurement difference. But if one try to pick someting, it would be:
attachemnts:
1) The FW compared behaviour long term from startup and fwd
2) Zoom in one 1) during startup
3) Zoom in on 1) later stage
4) A comparison between normal mode and +++ mode. The blue curves illustrates the effect of entering in uManger mode and exiting again. Green is entirely in uManger mode, the other two in normal operation.
5) Zoom in on 4)
6) PN measurements comparing normal mode vs +++ mode. zfe says not take absolute values for sure but relative difference should be correct. Dark blue = norm, White = +++, light blue is measurement limit.
Thanks zfe for nice measurements - as usual! 🙂
//
- First FW seem the calmest.
- Latest one could perhaps see a faster lock-in behaviour (steeper adjustemnt curve) in the zoomed in first phase at start up.
attachemnts:
1) The FW compared behaviour long term from startup and fwd
2) Zoom in one 1) during startup
3) Zoom in on 1) later stage
4) A comparison between normal mode and +++ mode. The blue curves illustrates the effect of entering in uManger mode and exiting again. Green is entirely in uManger mode, the other two in normal operation.
5) Zoom in on 4)
6) PN measurements comparing normal mode vs +++ mode. zfe says not take absolute values for sure but relative difference should be correct. Dark blue = norm, White = +++, light blue is measurement limit.
Thanks zfe for nice measurements - as usual! 🙂
//
Attachments
Last edited:
So +++ works and do good - PN 18 dB lower at 1 Hz.
New clock handling don't seem to be able to give any SQ improvements - maybe the opposite. One see greater derivate df/dt on adjustments.
SQ reports seem to match with measurement results - SQ is favourable in +++ mode => low freq/close-in PN is not desirable. (?)
I personally prefer to listen in +++ mode and hear no audible clocks or pops.
Close in PN is negatively affected by clock adjustments.
Maybe DAM series could benefit from even better clocks with lower close-in PN than the Si (if in +++ mode or in a revised FW that)
//
New clock handling don't seem to be able to give any SQ improvements - maybe the opposite. One see greater derivate df/dt on adjustments.
SQ reports seem to match with measurement results - SQ is favourable in +++ mode => low freq/close-in PN is not desirable. (?)
I personally prefer to listen in +++ mode and hear no audible clocks or pops.
Close in PN is negatively affected by clock adjustments.
Maybe DAM series could benefit from even better clocks with lower close-in PN than the Si (if in +++ mode or in a revised FW that)
//
Last edited:
I think the behavior of the clock adjustments in the pre-1.24 firmwares is the same. I think you would see the same differences running the measurement with the same firmware due to slightly different start conditions.
I think it is more likely that there are other reasons than the clock adjustments if the firmwares sound different.
For the 1941 and pre 1.24 alike firmware I think you will see the same, unless you listen via USB-input then the situation should look like in uManger mode above.
I think it is more likely that there are other reasons than the clock adjustments if the firmwares sound different.
For the 1941 and pre 1.24 alike firmware I think you will see the same, unless you listen via USB-input then the situation should look like in uManger mode above.
I thought the clock solution is shared between the i2s and s/pdif input - if it is, I think you would see about the same behaviour of the clock running the D/A process... maybe Sören could shed some light on this? I'll share some other of zfe's measurements which gives a clear picture on what happens when you do +++ - gif names describes contenet. zfe, what was "amanero" below?
//
//
Attachments
"amanero" is the frequency measurement of the simultanious measured I2S-masterclock of the I2S signal feeding the DAM (an Amanero).
Thank you so much, zfe and TNT!
This confirms my own measurements and listening impressions. And I think we can say that it looks like Andrea Mori was onto something with his insistance on low close-in phase noise, though a question of diminishing returns (and their point zero) certainly remains.
Looking at the long 5h+ measurements - at what point (if any) were the deviations so big that the buffer would be over-/underrun?
Since it's seems very clear now that the clock sounds best that adjusts the least, this is the area that firmware development should focus on.
I'm also interested regarding the differences between clocking from S/PDIF and I2S, since Andrea Mori's measurements have shown the former to have much much higher phase noise than the latter...
This confirms my own measurements and listening impressions. And I think we can say that it looks like Andrea Mori was onto something with his insistance on low close-in phase noise, though a question of diminishing returns (and their point zero) certainly remains.
Looking at the long 5h+ measurements - at what point (if any) were the deviations so big that the buffer would be over-/underrun?
Since it's seems very clear now that the clock sounds best that adjusts the least, this is the area that firmware development should focus on.
I'm also interested regarding the differences between clocking from S/PDIF and I2S, since Andrea Mori's measurements have shown the former to have much much higher phase noise than the latter...
Acc to my calculation and taking 20 samples deep fifo at 44,1 into account, 34 seconds. Here is the calc - I'm prepared to be corrected 🙂
A buffer of +/-20 samples at 44,1 is +/- 453ns. (But at 384ksps, only 56ns)
The total difference in the above example for clock deviation between the +++ point and the greatest deviation is 0,75 ns .
The rate of deviation in the above example from when +++ is entered to the greatest offset duration/offset: 10000/0,75e-6=13,3ns/s
A buffer of 20 sample/453ns would hold water for 34s (453/13,3s) if the rate of change was 13,3ns.
So after 34 seconds the +/-20 sample deep fifo has no more space (assuming it starts to write from pos 20 in the buffer (0...40)) and has to throw one sample away, zero the buffer and start over at pos 20. Repeat and rinse every 34 sec - if you don't at this point change the clock... 😉 You could have a warning at 18 sample full and change clock by half the fault and reset buffer - next time it will take 68 (66) to next event - with no slip/repeat.
But surely there is an error in my calculation...where? 🙂
There would be no difference for a 1021 - they share the clock solution for both these interfaces. In both cases the end result depends some of the source quality as a worse one would trigger more adjustments of the Si.
//