Discrete DSD DAC - Definition

[4est]

I think that is already well established here in CA [emoji2]

 

No doubt!

[jabbr]

The idea of "no FPGA" is not entirely accurate in this context. An FPGA is never a DAC, as an FPGA always outputs a digital signal. For example, a PS Audio DS or DS-J DAC uses an FPGA to do filtering and oversampling, and then it outputs a DSD 128 stream to a discrete DAC stage, which actually does the conversion to analog, this is still a discrete DAC.

Consider also Chord DACs. They also do oversampling and filtering in an FPGA, but the output from the FPGA then goes to their discrete "Pulse Array" DAC circuit.

These approaches, by using an FPGA to create a high rate data stream, which can then be easily converted to analog by a relatively simple discrete DAC circuit, are really not much different generally to what Miska (Jussi) does: the main difference is that Jussi does the oversampling in a separate computer running HQPlayer, and Chord and PS Audio do the oversampling onboard the component in an FPGA: all of these approaches still do the final conversion from digital to analog via a discrete DAC.

 

Of course there is a vast difference in the processing power of the two types of devices. To the extent that the algorithm requires finite state implementation, the general purpose CPU has been optimized much better and clock rates don't compare nor power requirements on a dollar for dollar basis.

 

Algorithms which have a high degree of fine grained parallelism eg 128 ops, fixed data flow paths, comparatively simple algorithms (eg neural networks) are more suited for FPGA. In many, and increasingly many cases it is most efficient to employ a hybrid approach with CPU accelerated by GPU and or FPGA.

 

While I don't have direct knowledge of the HQPlayer internals we know that CPU clock rate is more important than #cores i.e. a 12 core 2ghz Xeon not the best choice, yet CUDA acceleration is a benefit. This suggests that FPGA alone would be much less cost effective for this particular algorithm.

[jabbr]

The "proper" way to balance the DSC1 circuit is to use 32 additional shift registers for the other side of balanced. One can readily do this using two boards and the existing board outlines and some very simple mods. The DSC1's primary weakness is power supply dependency, as the outputs are directly connected with the power supply via the shift registers. Running balanced registers ameliorates this. There should be enough output to readily just filter this output without other parts. I intend to use a very high quality 1:1 transformer. The parts are on my bench, but sadly I too haven't the time...

 

Agreed. Easy to upgrade power supply. There are several ways to configure the shift registers. As has been discussed on the DIYAUDIO thread, and particularly for folks who consider clocks important, having different path lengths for the BCLK signal to each shift register causes skew which can get significant depending on the design. If the goal with balancing is to offset switching issues, minimizing clock skew becomes more important. The other aspect is common mode noise rejection.

 

The strategy of placing balanced shift registers on opposite sides of the board introduces the variable of clock delay across the necessary via, again if the balanced side is skewed, may not help so much.

 

So an area for improvement is in the clock distribution network -- fairly easy to use a low skew potato semi clock distribution chip (also reduces clock reflections at impedance mismatches),routing the clock signals so the path lengths are equal, and improving the bypass cap network at the shift registers themselves (DSC1 uses a routine 0.1 uF cap)

 

There are two proposed designs -- same schematic but different board layouts -- and it remains unknown which will actually sound better;)

[YashN]

I think that is already well established here in CA [emoji2]

 

Not by the majority yet

[jabbr]

A few remarks on why clock skew is important with balanced switching.

 

One of the reasons for a balanced switching circuit is that the draw from the power supply is relatively constant. Take a d-flip flop, the output signal Q, Q' is balanced, and one is + the other 0, and so assuming both output lines draw the same, the power draw in the presence of switching is relatively constant. Now separate both lines and lets say, place an inverter/buffer across each: when the inverter switches, the current drawn has a rapid change up or down. This can send a spike in the power supply network ie. switching noise. Now suppose there is a significant path length between the d-flipflop and the inverter for each line and lets say this causes a skew of 10 or even 100ps. That means that the switching spikes will be offset by 10 to 100ps, and now the power draw during that skew interval won't be constant, rather increased, or decreased during the interval. and if the circuit is itself sensitive to power supply fluctuations, then other signals will also get skewed.

 

Now suppose we have a fancy "femtosecond" clock in our DAC but because of these clock and signal skews we are introducing many picosecond delays: complete waste of a femtosecond clock. So if we are going to the trouble to get really good power supplies, and really good clocks and going to the trouble of balancing our digital circuit, we need to be even more careful to do a proper clock distribution network, we can also ameliorate switching noise in other ways: rather than a single traditional power supply bypass cap for each shift register chip, we can implement a low inductance bypass cap network

[Miska]

While I don't have direct knowledge of the HQPlayer internals we know that CPU clock rate is more important than #cores i.e. a 12 core 2ghz Xeon not the best choice, yet CUDA acceleration is a benefit. This suggests that FPGA alone would be much less cost effective for this particular algorithm.

 

There are several major challenges if one wants to use FPGA for HQPlayer's algorithms.

 

Typically DACs run all DSP processing synchronously to the input data flow / MCLK, so the time it takes to process one sample is constant because the processing is static. However, HQPlayer algorithms are asynchronous and HQPlayer may decide to change strategy on the fly based on input and output analysis and then reprocess the data (even several times) with a different strategy to arrive on a good solution before sending the results out. Software player can also do look-ahead analysis even for the entire track or album to understand the big picture and know what is coming up later.

 

Also most DACs use fixed point processing, implementing number of full 64-/80-bit (double/extended-precision) floating point engines on an FPGA is going to take a huge amount of space. Many DACs are also short on RAM. The processing may easily need a few gigabytes of fast RAM too.

 

GPUs provide huge bang for the buck on certain tasks where those are good and more parallelism than I've seen on FPGAs.

https://en.wikipedia.org/wiki/GeForce_900_series#Products

 

For DSC1, one could replace the logic chips with single FPGA, but it would make building the device harder for people because they would need a programmer device to write the FPGA firmware. It would also make managing power domains harder, now part of the logic is 3.3V and the shift registers are 5V. There's not much availability anymore for 5V output capable FPGAs, even though some have 5V tolerant inputs...

[EuroDriver]

Miska

Typically DACs run all DSP processing synchronously to the input data flow / MCLK, so the time it takes to process one sample is constant because the processing is static. However, HQPlayer algorithms are asynchronous and HQPlayer may decide to change strategy on the fly based on input and output analysis and then reprocess the data (even several times) with a different strategy to arrive on a good solution before sending the results out.

 

Now there is a very strong argument for the superiority of software format/upsampling conversion in software over in DAC box hardware and firmware !

 

Glad we are building a platform to run HQ Player on and not an FPGA based upsampling DAC ;-)

[jabbr]

GPUs provide huge bang for the buck on certain tasks where those are good and more parallelism than I've seen on FPGAs.

https://en.wikipedia.org/wiki/GeForce_900_series#Products

 

I'm eager for the announced 1000 series to come out, for which I'll build an HQPlayer compute server. Have you looked at the "Deep Learning" boards in terms of performance?

For DSC1, one could replace the logic chips with single FPGA, but it would make building the device harder for people because they would need a programmer device to write the FPGA firmware. It would also make managing power domains harder, now part of the logic is 3.3V and the shift registers are 5V. There's not much availability anymore for 5V output capable FPGAs, even though some have 5V tolerant inputs...

 

Yeah I considered doing that for a couple clock cycles. Interest in FPGA on my part is actually a hybrid FPGA/ARM which runs Debian "zynq 7020", and because I can use this to 1) implement SFP+ interface (fiber): the FPGA can run cores for SFP/SGMII/1000base-X so basically hook up an SFP cage, plug in a SFP module and then a fiberoptic cable. the ARM processor should run networkaudiod/NAA under Debian, and then ALSA driver sends the bits to the FPGA logic which clocks them out at DSD. Although the chip is itself complex, it replaces a lot of other modules.

 

Additionally there are other tasks the SoC can do including volume control interface and other preamp functions. Also the possibility of controlling a reclocking section which would be on the other side of some good signal isolation ... now if the FPGA has some space left over we could add in a software defined oscilloscope or something else marginally useful

 

I think its best, however, to keep the FPGA on the noisy input side essentially just replacing the Amanero board.

[bibo01]

Towards this end, a discrete DSD DAC, the latest XMOS xCORE-200 will do with PCM16x and DSD1024.

XMOS 768kHz DXD DSD512(DSD1024) high-quality USB to I2S/DSD PCB - DIYINHK

Perhaps not in this incarnation yet

[jabbr]

Towards this end, a discrete DSD DAC, the latest XMOS xCORE-200 will do with PCM16x and DSD1024.

XMOS 768kHz DXD DSD512(DSD1024) high-quality USB to I2S/DSD PCB - DIYINHK

Perhaps not in this incarnation yet

 

Interesting. The DSC1 and variants are are not limited to DSD512. DSD1024 is not a problem, whether its better is another question. Yet while we thought the maximal benefit was achieved at DSD256 there are good reports (EuroDriver) that DSD512 is an improvement, so why stop there? Issue will be jitter at low Hz and need to find clocks that remain low jitter at bottom end.