The DAM's "logic" is in the Xilinx FPGA (Field Programmable Gate Array).
Field-programmable gate array - Wikipedia
There are the FIFO, the clock "modulator" etc.
It's changing is only loading a new firmware.... if Soren willing to admit that this part is not functioning perfectly.
Every time the clock frequency is changed, you have to wait until it is settled enough to start using it as a frequency counter reference. Frequency counters have error sources such as aperture jitter that are minimized by using a long count integration time. Shortening that time too much will increase chances of an erroneous frequency change. Depends a lot on jitter, wander, phase noise of the incoming source. Probably easier to track some sources than others. Normally that's the case, so the frequency servo needs to be able to follow a fairly low quality source. That can tend to make the servo perform worse with better quality sources. We are talking about servo control loop bandwidth as it affects sound quality. There is no perfect servo tuning for different quality sources. That's why ESS dac chips have a setting called 'DPLL_Bandwidth.'
"That's why ESS dac chips have a setting called 'DPLL_Bandwidth"
And thats what we essentially are asking for I suppose. Keep the good working current one but add an optional version that will require a good, very stable incoming clock where the DPLL can work much less aggressive despite a small FIFO and reduce clock adjustments to say once a minute after initial capture.
But all has been said a few times already really... its up to Sören - now would be a good time to comment please.
//
And thats what we essentially are asking for I suppose. Keep the good working current one but add an optional version that will require a good, very stable incoming clock where the DPLL can work much less aggressive despite a small FIFO and reduce clock adjustments to say once a minute after initial capture.
But all has been said a few times already really... its up to Sören - now would be a good time to comment please.
//
From his many responses, he already thinks his implementation is already “perfect”.
Really not sure what can reopen his mind to revisit his clock DPLL implementation...
His mind is quite closed, maybe the rework is too challenging for him to undertake... If he cares for his installed base, he should.
Last edited:
I believe he is very capable and would have no problem doing it. But seem to maintain a firm belief of what is audible. Maybe from his own experience or/and a listener reference group. It would be sad if the involved people would not represent or have the ability to meet his high set goals i.e. SOTA sound. It is a risk. To avoid some of that risk and create a bit of a safe zone, it would be smart to "go crazy" and over engineer some to be sure to cover the most demanding requirements. The craziness and over engineering in this case would only have to be a mild breeze of what others are doing.
I'm sure *something* will come - Sören said so.
//
I'm sure *something* will come - Sören said so.
//
Well, I certainly hope so. Crossing my fingers that an updated firmware will be released with improved clock DPLL algorithm...
From the data shared here, it’s pretty obvious that further improvements can be made via firmware.
If he indeed releases a better clock DPLL firmware for his installed base, it’ll go a long way to reassure his existing customers that he listens and support wherever it is reasonable. It’ll also help reconfirm my choice to spend my hard earned money on the TOTL dac1541, instead of competing ChiFi R2R DAC that is also very well received...
With all these clock wandering topic, I do have a technical question...
...if I were to upsample the source material outside of the Soekris DAC to 352/384, and then feed the upsampled stream to the DAC, will the clock wander become lesser of a concern (because of the higher bitrate)? or it won’t make any difference to the issue at hand?
* I am aware by doing so, I wont be using the internal FIR1 filter, which doesn’t really concern me.
...if I were to upsample the source material outside of the Soekris DAC to 352/384, and then feed the upsampled stream to the DAC, will the clock wander become lesser of a concern (because of the higher bitrate)? or it won’t make any difference to the issue at hand?
* I am aware by doing so, I wont be using the internal FIR1 filter, which doesn’t really concern me.
I guess some DPLL strength level would be neat for those of you here who are obsessed with clock. But the few Soekris products I used over USB don't have any locking or clocking problem whatsoever. I guess it's most interesting for those who use a DAM with some s/pdif source.
Isolated USB serves me very well
baten, there is no functional problem as in "it stutters, locking drops, etc", not for s/pdif nore for USB. If you own a Soekris DAC with built in USB, you dont have this wander problem as in this case, the Si is not adjusted. For all others, the above is technically a concern - if it has an audible impact far all is unknown.
boxerfan: Upsamling dont solve or eases the problem. In the end, at the ladder, where it counts, all DAM works at the same speed. It is just the amount of calculation on the way there, that differs.
//
boxerfan: Upsamling dont solve or eases the problem. In the end, at the ladder, where it counts, all DAM works at the same speed. It is just the amount of calculation on the way there, that differs.
//
DAM1021 and Volumio
Finally I have found the time to get the DAM running but I have a problem when I play redbook material from Volumio using the I2S input of the DAM.
I have selected Soekris DAM 1021 in Volumio Output Settings.
It works correctly with Hi-res material but it does not lock with 16 bit/44kHz material.
The DAM1021 does not support redbook material?
Or are there other parameters to set?
Finally I have found the time to get the DAM running but I have a problem when I play redbook material from Volumio using the I2S input of the DAM.
I have selected Soekris DAM 1021 in Volumio Output Settings.
It works correctly with Hi-res material but it does not lock with 16 bit/44kHz material.
The DAM1021 does not support redbook material?
Or are there other parameters to set?
I'm using rpi via i2s from GPIO and the DAM does not lock with redbook material, while it locks correctly with hi-res material.
Maybe the DAM does not support 16 bit depth via I2S?
Can you tell what have I to set in Volumio?
I have checked the I2S signals with a scope, they are perfect.
I'm using Volumio and I have no time to replace the player.
It looks like the DAM1021 does not support 16 bit depth I2S.
Since in the manual there are no I2S specification, is there someone who knows about the supported I2S word length?
Soeren?