Not for the sake of interacting with umanager if this is what you ask about - sorry I just saw that you have it working - so you are probably asking about something else?
Hi Soren,
I got the DAC1541 and my friend just past me a Singxer F-1 XMOS USB.
I would like to see the difference by connecting the Singxer usb to the DAC1541.
My best guess was the "J3" jumpers on the DAC board. May I obtain the information on it? Thanks.
I got the DAC1541 and my friend just past me a Singxer F-1 XMOS USB.
I would like to see the difference by connecting the Singxer usb to the DAC1541.
My best guess was the "J3" jumpers on the DAC board. May I obtain the information on it? Thanks.
I'm not sure what you're asking for, but if you want to try to connect an external USB to I2S interface then it's not possible nor needed, the dac1541 have its own perfect USB to I2S interface and it cannot be bypassed.
One question to users who are using Amanero (un-modified version) pairing with the Soekris DAC. What firmware on Amanero do you use to get the DSD playback? As I think I am using the CPLD_for_1080 + Firmware 1.096c3w2 and I get screeching noise when I play a DSD file either via Windows 10 PC + Foobar or Raspberry Pi + moOde OS. I have even tried different images like Volumio, Rune but its the same issue. Is the problem with the OS that I am using or the players (in case of Foobar) or the correct firmware on the Amanero?
Thanks
Thanks
With the standard settings of the amanero board you have to enable DoP (DSD over PCM) for playback in the player(s) not "direct" DSD.
If you use the filters provided by Soekris, than the filters are normal.
There are also customized filter to find, but they are not provided by Soekris.
There are also customized filter to find, but they are not provided by Soekris.
Here again an indication that the frequency tracking of the FIFO of the DAM has some ... ahm ... room for improvement.
My conclusion of the reasoning below is that there is need to add some (preferably fast) damping.
The first image is the long term recording of a 96Hz square wave (upper track the source, lower track the recording).
In the recording you see oscillation of a period of about two minutes.
This comes from the differences in the magnitude of the overshot (the following second image zoomed in as illustration) due to a phase shift the location of the flank of the square wave moves in the sample (the ADC is oversampling, we see the result of the low-pass filter + decimation).
I think the phase shift comes from how the FIFO frequency tracking is performed. Assume the input signal is perfect (no jitter). The start frequency of the DAM (I have the impression it uses some memorised value to start from) can be slightly different from the actual signal frequency, the tracking adjust the frequency towards the signal, but it will overshot the aimed frequency and then track in the other direction and so on.
If I stop the signal and start it again it seems that the DAM starts with the frequency where it stopped before. So with some try and error you can get as start frequency, more or less, the right value and a recording without (noticeable) oscillation and this will survive start and stops until you change the sample frequency - then the whole game starts again.
So some damping in the tracking is needed to prevent this oscillation - especially if the input signal is very good.
I do not claim that the oscillation has audible effects but it is "wrong".
The recording was made with the RTX6001 analyser, which has a good clock. The signal for the DAM came from the RTX6001 by SPDIF.
The low frequency oscillation her is something different from the oscillation due to slightly different clock speeds when using a USB interface with its own clock for the signal for the DAM. This I reported here. This oscillation has much shorter period and is gone if you use the SPDIF of the analyzer, and thus the clock of the analyzer, as source.
My conclusion of the reasoning below is that there is need to add some (preferably fast) damping.
The first image is the long term recording of a 96Hz square wave (upper track the source, lower track the recording).
In the recording you see oscillation of a period of about two minutes.
This comes from the differences in the magnitude of the overshot (the following second image zoomed in as illustration) due to a phase shift the location of the flank of the square wave moves in the sample (the ADC is oversampling, we see the result of the low-pass filter + decimation).
I think the phase shift comes from how the FIFO frequency tracking is performed. Assume the input signal is perfect (no jitter). The start frequency of the DAM (I have the impression it uses some memorised value to start from) can be slightly different from the actual signal frequency, the tracking adjust the frequency towards the signal, but it will overshot the aimed frequency and then track in the other direction and so on.
If I stop the signal and start it again it seems that the DAM starts with the frequency where it stopped before. So with some try and error you can get as start frequency, more or less, the right value and a recording without (noticeable) oscillation and this will survive start and stops until you change the sample frequency - then the whole game starts again.
So some damping in the tracking is needed to prevent this oscillation - especially if the input signal is very good.
I do not claim that the oscillation has audible effects but it is "wrong".
The recording was made with the RTX6001 analyser, which has a good clock. The signal for the DAM came from the RTX6001 by SPDIF.
The low frequency oscillation her is something different from the oscillation due to slightly different clock speeds when using a USB interface with its own clock for the signal for the DAM. This I reported here. This oscillation has much shorter period and is gone if you use the SPDIF of the analyzer, and thus the clock of the analyzer, as source.
Nice find zfe! Keep up the good job.
As I understand the algo, what one should see is a possible jump/skip at the most every appr. 2 minutes (the filtering time). Between the adjustment, the whole D/A process should be firmly locked to an unaltered oscillator.
//
As I understand the algo, what one should see is a possible jump/skip at the most every appr. 2 minutes (the filtering time). Between the adjustment, the whole D/A process should be firmly locked to an unaltered oscillator.
//
Lower output level with NOS filter?
Hi Soekris,
I put the DAM1021 (Rev 5) into operation and ported the original NEWNOS filter to the new firmware and uploaded it. Compared to my old DAM1021 Rev 1 with NewNOS filter, the available output level is estimated to be 3-5 dB lower than before (single ended output). This has a very negative effect on kernel streaming with digital volume control, as I have to connect an additional preamplifier stage to drive low-efficiency speakers (in this case Celestion SL600). How can this be explained?
By the way - sound quality with Rev 5 and new firmware is very good.
Hi Soekris,
I put the DAM1021 (Rev 5) into operation and ported the original NEWNOS filter to the new firmware and uploaded it. Compared to my old DAM1021 Rev 1 with NewNOS filter, the available output level is estimated to be 3-5 dB lower than before (single ended output). This has a very negative effect on kernel streaming with digital volume control, as I have to connect an additional preamplifier stage to drive low-efficiency speakers (in this case Celestion SL600). How can this be explained?
By the way - sound quality with Rev 5 and new firmware is very good.
The new 1.20 firmware and 4K filters have zero at -2 dB, the dam1021 then add 1 dB gain, resulting in zero at -1 dB with 1 dB margin, ie when volume level is set to 0 then it's 1.26V rms output at resistor network, about 1.9V at buffered single ended and 3.8V buffered balanced.
I have no idea how your filters are designed and what it have at zero level. Look at the filter file source for details.
Do you say that there is some change in the level, with the new firmware, aside of the FIR1 filter multiplicators (which are about 1.7dB lower in the new firmware)?