Tír Na HiFi

My understanding of the Chord dac architecture is that the FPGA does the de-jitter, upsampling and noise shaping required to produce a high bandwidth bitstream (1 bit) pwm datastream.

The Pulse Array is very similar to the dcs Ring dac (at least in principle if not execution) in that it using an averaging/randomised conversion approach, using multiple elements to average out the non-linearity inherent in the conversion process, ensuring a highly accurate (resolving) current output, but without the horrible noise present in classical bitstream approaches.

Rob Watts started down this path back in the days of his highly respected Deltec PDM1024 dac in 1994. Modern chips and design tools have made the implementation of this approach much more cost-effective and the results much more impressive.

Looking at the Mola-Mola dac design (by Bruno Petzeys of Hypex fame) it is another implementation of this principle. In effect what I understand happens is that the output stage is a form of filter and by bombarding it with a varying high frequency pulse you get an output current that reflects the averaged signal level at the desired reconstruction rate (audio passband), voila music!

It's interesting what Rob Watts says in a number of areas - it's just that I might have a different approach to these same issues:

Certainly, the DAC implementation does have a large bearing on the sensitivity to clock jitter, so does the noise shaper characteristics, so does the signal RF noise levels. To further complicate the matter, fixed noise from jitter sources is not audible as such (in terms of SQ), as it just contributes to the dynamic range noise.

Agree that noise modulation may well be a bigger issue (or limiting factor) with digital audio(Delta Sigma method(D-S) which most ADCs & DACs now adhere to) than we currently consider. Most don't consider this of significance - it would be GUBU given that the industry has gone the D-S route. The low level at which a modulating noise floor may have a psychoacoustic effect may well be surprising. Hints of this were shown in that ESS youtube video we have referenced in the past.

1. The interpolation filter is key to recreating the amplitude and timing of the original recording. We know the ear/brain can resolve 4uS of timing - that is 250 kHz sampling rate. To recreate the original timing and amplitude perfectly, you need infinite tap lengths FIR filters. That is a mathematical certainty. Hugo has the largest tap length by far of any other production DAC available at any price.

Yes, agree that interpolation filter is a key element in the DACs output & most are not so well designed. I would just try a different approach (can't let out what I'm thinking at the moment)

2. RF noise has a major influence in sound quality, and digital DAC's create a lot of noise. Hugo has the most efficient digital filtering of any other production DAC - it filters with a 3 stage filter at 2048 FS. The noise shapers run at 104 MHz, some 20 times faster than all other DAC's (excepting my previous designs). What does this mean? RF noise at 1 MHz is 1000 times lower than all other DAC's, so noise floor modulation effects are dramatically reduced, giving a much smoother and more natural sound quality.

Yes, RF noise is crucial - a different way of looking at this is diametrically opposite to Rob - use as low a speed as possible. Whatever approach some RF noise appears on the output of the DAC & should be dealt with.

3. The lack of DAC RF OP noise means that the analogue section can be made radically simpler as the analogue filter requirements are smaller. Now in analogue terms, making it simpler, with everything else being constant, gives more transparency.

Yes

There are certainly more than one valid approach, so it'll be interesting to see what you might produce in this area John.

I spent a few hours looking into the FPGA development route and decided I did not know enough to realise something beyond the "toy" level of sophistication. There is an FPGA diy site where someone shows a simple model for making basic building blocks for a dac, but as Dave says, there is much more to it than simply implementing the mathematical model using a bunch of gates.

A fully discrete ladder dac like the Totaldac design might be more achievable, though costly and very time consuming.

LowOrbit wrote:There are certainly more than one valid approach, so it'll be interesting to see what you might produce in this area John.

I spent a few hours looking into the FPGA development route and decided I did not know enough to realise something beyond the "toy" level of sophistication. There is an FPGA diy site where someone shows a simple model for making basic building blocks for a dac, but as Dave says, there is much more to it than simply implementing the mathematical model using a bunch of gates.

A fully discrete ladder dac like the Totaldac design might be more achievable, though costly and very time consuming.

Is this the site? http://ultra-embedded.com/fpga_audio?

I emailed the guy behind the project and he has taken it forward to include USB stick input. It does use the FPGA that DaveF knows all about I think. Would be interested to hear if DaveF thinks that project is at all suitable as the basis of taking an audiophile player forward, which was not the the main aim of that guy's project. Taking out the MP3 circuit would make it even simpler.

There is source code for the player available.

I don't believe that there is any magical audio advantage in using an FPGA - my DACs & converters use an ARM MCU & Xilinx FPGA :)
What may confer some advantage on FPGAs is the low voltage that they operate at (1.2V or 1.8V) - lower internal ground bounce (read ground noise)?

For instance, there is only one clock in that link to FPGA project - all audio clocks derived from one clock = not a good idea

jkeny wrote:I don't believe that there is any magical audio advantage in using an FPGA - my DACs & converters use an ARM MCU & Xilinx FPGA :)

would be nice if we had thesycon type drivers
its a weird one even though the xmos is supposed to be jittery enough there seems to be a detail advantage when using the lower buffer and latency settings

For instance, there is only one clock in that link to FPGA project - all audio clocks derived from one clock = not a good idea

don't we need a clock for every frequency family?

i think a device that replaces both the pc and the dac that reads and plays wav files from usb hd or usb key (no usb, no pci etc etc) less complication, less loss, less gain of rfi
might be more optimal

nige2000 wrote:

jkeny wrote:I don't believe that there is any magical audio advantage in using an FPGA - my DACs & converters use an ARM MCU & Xilinx FPGA :)

would be nice if we had thesycon type drivers
its a weird one even though the xmos is supposed to be jittery enough there seems to be a detail advantage when using the lower buffer and latency settings

Yea, it's like a recipe - a pinch of some ingredients, added at the right time, can have a big affect on the flavour of the outcome?

For instance, there is only one clock in that link to FPGA project - all audio clocks derived from one clock = not a good idea

don't we need a clock for every frequency family?

Only two frequency families & for lowest jitter, yes a clock for each is recommended

i think a device that replaces both the pc and the dac that reads and plays wav files from usb hd or usb key (no usb, no pci etc etc) less complication, less loss, less gain of rfi
might be more optimal

I agree with trying to dispense with general purpose computer & replacing with a processor targetted at audio but the digital to analogue conversion step is required somehow, unless using DSD where the average of the DSD signal IS the analogue signal

jkeny wrote: What may confer some advantage on FPGAs is the low voltage that they operate at (1.2V or 1.8V) - lower internal ground bounce (read ground noise)?

FPGAs tend to have higher power comsumption though that for the equivalent circuit in an ASIC. So depending on the FPGA size vs fabric you use, you may end up with some wastage inside. Not such a bad thing as it leaves headroom to add further features/processing/RAM in future.
FPGAs can interface to wide range of signalling options: lvcmos, lvttl, lvds etc. You can also control the skew, drive strengths and slew rates of all IO signals. All of this can reduce EMI and ground bounce issues. (Ground bounce tends to be more of PCB layout and stackup issue though)

jkeny wrote: For instance, there is only one clock in that link to FPGA project - all audio clocks derived from one clock = not a good idea

For FPGAs, you generally bring in a low speed clock from a crystal. Internally in the FPGA you derive other clocks and specify skew, jitter etc through a range of PLL and DCM blocks. Options vary depending what FPGA you use. Alternatively you can use an external clock generator chip in tandem with the FPGA. Crossing async clock domains can add certain complications but sometimes this is necessary. Again its all about context.


The real power of the FPGA is the ability to do processing on your samples such as interpolation/filtering/upsampling etc just like in the Hugo/dCS/Devialet units.

.....and on the subject of dispensing with the PC altogether, I'd agree but we have to keep in mind what the user interface is going to be? How is the user going to select, navigate and play tracks and from where? A NAS, etc?
This will surely involve some sort of product involving a processor/SW/GUI. I believe we touched on this before back in the Tweakers Rash thread.

DaveF wrote:

jkeny wrote: What may confer some advantage on FPGAs is the low voltage that they operate at (1.2V or 1.8V) - lower internal ground bounce (read ground noise)?

FPGAs tend to have higher power comsumption though that for the equivalent circuit in an ASIC. So depending on the FPGA size vs fabric you use, you may end up with some wastage inside. Not such a bad thing as it leaves headroom to add further features/processing/RAM in future.
FPGAs can interface to wide range of signalling options: lvcmos, lvttl, lvds etc. You can also control the skew, drive strengths and slew rates of all IO signals. All of this can reduce EMI and ground bounce issues. (Ground bounce tends to be more of PCB layout and stackup issue though)

I was under the impression that ground bounce can be an on-chip issue as well (I know certain designs have taken steps to address this) but maybe I'm wrong - maybe all chip fabs now have this problem sorted?

jkeny wrote: For instance, there is only one clock in that link to FPGA project - all audio clocks derived from one clock = not a good idea

For FPGAs, you generally bring in a low speed clock from a crystal. Internally in the FPGA you derive other clocks and specify skew, jitter etc through a range of PLL and DCM blocks. Options vary depending what FPGA you use. Alternatively you can use an external clock generator chip in tandem with the FPGA. Crossing async clock domains can add certain complications but sometimes this is necessary. Again its all about context.[/quote]For lowest jitter, I believe the clock ticks (from crystal or clock) should be as unmolested as possible. I know FPGAs, etc give measurements for clock skew, jitter etc. which may be impressive but I have found that:
- using two independent audio clocks feeding the FPGA is better than audio clocks derived internally in the FPGA
- using the same audio clocks to reclock the signal after it emerges from the FPGA again sounds better - leading me to the conclusion that this particular FPGA implementation molests the clock signal in some way

The real power of the FPGA is the ability to do processing on your samples such as interpolation/filtering/upsampling etc just like in the Hugo/dCS/Devialet units.

Agreed but there are other, simpler ways to approach these issues