New Audio-gd R-7, R-7HE R-8, R-27, R-27HE, R-28 Flagship Resistor Ladder DACs and DAC/amps
Oct 27, 2019 at 5:18 AM Post #5,326 of 11,196
Is it only me, or did anyone else notice that the full impact of the software upgrade took a few hours to reach?

My theory is, that since this is FPGA and not CPU, with FPGA having a set of fixed circuits interconnected by the Quartus programming, it simply requires some burn-in like any other electronics.
 
Oct 27, 2019 at 7:00 AM Post #5,327 of 11,196
Is it only me, or did anyone else notice that the full impact of the software upgrade took a few hours to reach?

My theory is, that since this is FPGA and not CPU, with FPGA having a set of fixed circuits interconnected by the Quartus programming, it simply requires some burn-in like any other electronics.
Maybe so. Also, moving signal cables around, if you had to unplug everything, can have a temporary effect. Maybe i should give DOP another chance and time to settle. If it works, it would validate your theory since my intertonnect does not seem impacted.
 
Oct 27, 2019 at 9:25 AM Post #5,329 of 11,196
@FredA Could depend very much on the rest of your gear, as well as your personal preferences. What works for me may not necessarily work for you :boy:
My point was related to the fact that dsdclk and dop should sound the same with i2s as the only change introduced by dop was the support of dsd over spdif. So considering your point, i should give dop another try.
 
Oct 27, 2019 at 11:44 AM Post #5,331 of 11,196
@FredA If you check the new R28 (2020) description on new features, under point 2 you have

The FPGA process data upgrade to parallel mode.
The IIS data is series transmit mode, every data must need one clock cycle to process or transmit, one frame data ( Include L and R data) must need 64 clock cycle to process or transmit, so the data has effect by the 64 clock cycles.

But the parallel data process and transmit mode only need one clock cycle can finish the one frame data process and transmit, that can avoid the effect of clock stability .
The IIS input (Include USB and HDMI-IIS) has recombine become dual 32bit parallel data once input , and the SPDIF input after decoder, has recombine become dual 24bit parallel data, and the DSD input has recombine become dual 64bit parallel data once input.
The parallel process and transmit mode can improve the sound quality on the transparency and detail but still analog.


Which is what I assume is why the new FPGA file is called “DOP_Parallel. Not a minor change only for SPDIF.
 
Oct 27, 2019 at 12:27 PM Post #5,332 of 11,196
@FredA If you check the new R28 (2020) description on new features, under point 2 you have

The FPGA process data upgrade to parallel mode.
The IIS data is series transmit mode, every data must need one clock cycle to process or transmit, one frame data ( Include L and R data) must need 64 clock cycle to process or transmit, so the data has effect by the 64 clock cycles.

But the parallel data process and transmit mode only need one clock cycle can finish the one frame data process and transmit, that can avoid the effect of clock stability .
The IIS input (Include USB and HDMI-IIS) has recombine become dual 32bit parallel data once input , and the SPDIF input after decoder, has recombine become dual 24bit parallel data, and the DSD input has recombine become dual 64bit parallel data once input.
The parallel process and transmit mode can improve the sound quality on the transparency and detail but still analog.


Which is what I assume is why the new FPGA file is called “DOP_Parallel. Not a minor change only for SPDIF.
You are right, but i should have mentioned i use i2s 99.9 % of the time.
 
Oct 27, 2019 at 12:36 PM Post #5,333 of 11,196
@FredA If you check the new R28 (2020) description on new features, under point 2 you have

The FPGA process data upgrade to parallel mode.
The IIS data is series transmit mode, every data must need one clock cycle to process or transmit, one frame data ( Include L and R data) must need 64 clock cycle to process or transmit, so the data has effect by the 64 clock cycles.

But the parallel data process and transmit mode only need one clock cycle can finish the one frame data process and transmit, that can avoid the effect of clock stability .
The IIS input (Include USB and HDMI-IIS) has recombine become dual 32bit parallel data once input , and the SPDIF input after decoder, has recombine become dual 24bit parallel data, and the DSD input has recombine become dual 64bit parallel data once input.
The parallel process and transmit mode can improve the sound quality on the transparency and detail but still analog.


Which is what I assume is why the new FPGA file is called “DOP_Parallel. Not a minor change only for SPDIF.
I am still confused about DoP FW, it is supposed to be DSD over PCM, so there should be no effect if u play native PCM, or native DSD, only if u do DSD via DoP an perhaps will affect USB as well as SpDIF etc or even I2S but only if u are playing DSD via DoP; well unless this FW also does something to PCM decoding itself as maybe there is a common pathway for both dop and pcm
 
Oct 27, 2019 at 12:56 PM Post #5,335 of 11,196
@FredA ??? It says that it applies to USB and HDMI-IIS both...? We should both be happy (I run USB; the very good USB output from the SOtM sms-200 ultra neo isn’t improved by neither my ifi iUSB3.0 nano nor my Singxer SU-1).

You missed my previous posts in which i was stating i prefered dsdclk over the last (dop) firmware. The only explanation i got is the fact of adding functionality changes how the circuit is mapped onto the fpga, hence the sound difference.
 
Oct 27, 2019 at 1:41 PM Post #5,336 of 11,196
You missed my previous posts in which i was stating i prefered dsdclk over the last (dop) firmware. The only explanation i got is the fact of adding functionality changes how the circuit is mapped onto the fpga, hence the sound difference.
I see your point, so I suppose there is an additional benefit via FPGA programming for PCM, but no known side effects.
 
Oct 27, 2019 at 5:22 PM Post #5,337 of 11,196
I see your point, so I suppose there is an additional benefit via FPGA programming for PCM, but no known side effects.
FPGA are special device, meant essentially for digital processing. These are powerful and flexible devices, and their programming is very specialized. Again, they are NOT CPUs with a fixed set instructions.
 
Oct 27, 2019 at 6:43 PM Post #5,338 of 11,196
In other work I’ve definitely seen FPGA performance change between one version and another - even if certain sections of the FPGA codebase are identical. This can come up when gate/routing resources run low (fatter code/ new features). Even with minor changes the compiler may pick different FPGA gates/ routing next time for same function as previous version.
 
Oct 27, 2019 at 6:51 PM Post #5,339 of 11,196
In other work I’ve definitely seen FPGA performance change between one version and another - even if certain sections of the FPGA codebase are identical. This can come up when gate/routing resources run low (fatter code/ new features). Even with minor changes the compiler may pick different FPGA gates/ routing next time for same function as previous version.
Nice. You confirm my hypothesis. The firmwares would probably be better still if Kingwa reduced the function set to a bare minimum. Perhaps with removing the tda1541 simulation.
 
Last edited:

Users who are viewing this thread

Back
Top