Shouldn't every DAC by design sound pretty much identical?

[invaderzim]

Maybe I just gave-up chasing my audio tail... But my best sounding DAC is PS Audio's NuWave DSD DAC w/FPGA - Believe I'll stop the chase with this one

It's not the most expensive DAC I've had in my main system but there is a SQ about it that I love

It is nice to find the product that gets the trickle-down technology from a companies high end products.
Interestingly, I can't find a link on their site to that DAC. I found the page on it by searching specifically for it. They must not make a lot of money off of it.
When I was DAC shopping recently I thought the only difference between the NuWave and the NuWave DSD was DSD support. Fortunately for my bank account I didn't see the specs and how much the DSD version shares with their higher products and there just wasn't enough about the non-DSD one that made me want to try it for that price.

 

[Frank Sol]

Interestingly, I can't find a link on their site to that DAC. I found the page on it by searching specifically for it. They must not make a lot of money off of it.

Paul and company never sit still so they may be phasing it out

I would love to hear their TOP DAC in my system but I would need to hit the grand Lotto because then I would have to have all the other stuff to match

 

[invaderzim]

That was the main issue when I was considering the NuWave DAC, the percentage of the system price would have gone way in the direction of the DAC at that point.
And not realizing that the DSD version could be updated with software it also seemed like the part most likely to go obsolete the soonest.

 

[Frank Sol]

That was the main issue when I was considering the NuWave DAC, the percentage of the system price would have gone way in the direction of the DAC at that point.
And not realizing that the DSD version could be updated with software it also seemed like the part most likely to go obsolete the soonest.

having a little more time to think about it... PS Audio are pushing their 'Stellar' line now so the NuWave stuff taking a backseat

 

[invaderzim]

That is a shame because it looks like a really impressive piece of equipment. Now that I now maybe someday I'll try one.

 

[Retrovert]

Clearly, they are using the FPGA to implement a custom, oversampling filter. That's still entirely digital, so I'm trying to figure out where the conversion to analogue takes place, and what is performing it.

Digital can simulate analog with discrete time steps, and with enough steps the waveform is close enough. Here is a simplified and handwavy explanation which broke off all the complicated bits and tossed them in the rubbish bin.

The FPGA implements a DSP, since it is less expensive to use a single FPGA as opposed to either:

(a) implementing both the discrete DSP chip plus the requisite glue logic​

—or—

(b) designing an ASIC (Application Specific Integrated Circuit), which is standard digital function blocks connected together with custom wiring and glue logic. Each revision of an ASIC requires a mask change, whereas the FPGA memory (flash) can simply be reprogrammed.
​

The speed and cost of the FPGA are more than adequate for this purpose, and the rework expense is minimal (ROM replaces mask), which is why ASICs are less common. Think of the FPGA as being equivalent to any of the DSP circuits you see with custom programming. Turing equivalence guarantees that. Software is hardware and vice-versa.

The simulated DSP (FPGA emulates the DSP's programming) then produces a PWM output which is buffered, integrated in a capacitor, and run through a low-pass filter to remove digital artifacts (ringing, aliasing, etc.). The resulting voltage is therefore a function of the pulse train's duty cycle, which, in turn, is a function of the digital value being converted.

It is common to use an FPGA to perform PWM tasks like motor control, and the circuit functionality is essentially a low-resolution DAC. So it may be helpful to consider such circuits when trying to understand how to an FPGA DAC works.

 

[cpt_paranoia]

Digital can simulate analog with discrete time steps

I know; I've been designing digital electronics for 40 years, and developed a noise-shaping RF synthesis ASIC for Vodafone's initial GSM base station and handset rollout in 1988, and have worked on ASIC and FPGA designs, on and off, ever since...

As I said, they must be using a bitstream approach for the DAC part; all their lovely FPGA does is custom digital filtering to create those bitstreams. That's all fairly conventional stuff.

What I'm really interested in is the mechanisms they're using to ensure accuracy of the bitstream pulses, to ensure that all their prior clever work isn't for nought. Having worked on digital PLL designs, I know that errors in a type 2 phase detector (dual d-type) have a profound effect on the purity of the synthesised signal. A dual-d phase detector isn't that dissimilar to the summing filter stage of a bistream converter (pulses injected into a simple filter).

 

[Retrovert]

What I'm really interested in is the mechanisms they're using to ensure accuracy of the bitstream pulses, to ensure that all their prior clever work isn't for nought.

It's just a conventional PWM so it depends on the clock accuracy, n'est ce pas?

Use a good, stable quartz controlled clock and it's all good. An oven would improve the accuracy. But since it's about 25 to 50 parts per million out of the box, no need to fret.

 

[cpt_paranoia]

It's just a conventional PWM so it depends on the clock accuracy, n'est ce pas?

I don't know if it's PWM; all that talk about 'pulse arrays'. Simple PWM won't give you noise-shaping benefits; it has to be a bitstream approach.

Bitstream conversion at 104MHz clock has potential for interesting difficulties with the pulse timing and shape; any variation of either would lead to inaccurate reconstruction. Generating a single, precise 104MHz pulse isn't trivial. If that's what they need to do... As I said; this is the part that interests me.

Long-term frequency accuracy isn't the problem; an oven isn't needed here. It's the cycle-to-cycle accuracy that is critical. And, at 104MHz, that's an interesting switching problem. Those 'magic flip-flops', and how they behave, is the critical element in this converter, I think.

 

[Retrovert]

I don't know if it's PWM; all that talk about 'pulse arrays'. Simple PWM won't give you noise-shaping benefits; it has to be a bitstream approach.

SMD converters are PWM. What else could it possibly be? This is the definition of PWM. No difference between motor control and audio as far as the PWM is concerned.

The DSP portion of the FPGA does whatever shaping and smoothing is required, if any, instead of using a separate linear circuit.

Bitstream conversion at 104MHz clock has potential for interesting difficulties with the pulse timing and shape; any variation of either would lead to inaccurate reconstruction. Generating a single, precise 104MHz pulse isn't trivial. If that's what they need to do... As I said; this is the part that interests me.

Which clock? The clock to generate an oversampling at 128x @ 20k Hz is about 6 MHz, easily within the abilities of an inexpensive FPGA.

I've seen the arguments and proposed solutions for clock jitter in USB streams and it all makes good sense.

 

[cpt_paranoia]

What else could it possibly be

PPM. PDM?

No difference between motor control and audio as far as the PWM is concerned.

Not sure that motor control requires quite the accuracy audiophiles are looking for.

Which clock?

The 104MHz clock mentioned in the video. They make quote a point of the fact that is a lot faster than a normal DAC. 104MHz is well within the capabilities of a Xilinx series 7 FPGA (we use 125MHz for most core logic, and 250MHz for a final upsampling filter), but it's the external 'magic FFs' I'm thinking of. Which the video says are clocked at 104MHz.

 

[Retrovert]

Not sure that motor control requires quite the accuracy audiophiles are looking for.

Ummm, that wasn't my point at all. I was suggesting you could find a simple PWM design for motor control which would explain how a DAC could be implemented using a purely digital device, such as an Arduino or FPGA.

You wrote you didn't understand how this works, so I tried to give you a simple piece of code so you could understand the process.

The 104MHz clock mentioned in the video. They make quote a point of the fact that is a lot faster than a normal DAC.

Uh, yeah, so what? That's just the clock for the DSP being simulated. It has no relevance to the actual conversion bandwidth of the DAC!

This may come as a shock, but companies hype all sorts of nonsense in marketing materials to differentiate a product and make a sale. I know, it sounds unbelievable that an unrelated specification would be touted, but there you go.

The 104 MHz clock is just marketing blather. Pay no attention to it. I wouldn't buy those products because I doubt the engineering is as good as what goes into a product from Analog Devices or TI, and whenever I see all manner of hype I become suspicious of what else is being hyped, exaggerated, or outright lied about.

DAC design is tricky and susceptible to instability in the filters. It takes real expertise to get that right. On general principles I am suspicious of the claims being made.

You won't ever see Analog Devices or TI hyping some internal clock rate.

104MHz is well within the capabilities of a Xilinx series 7 FPGA (we use 125MHz for most core logic, and 250MHz for a final upsampling filter), but it's the external 'magic FFs' I'm thinking of. Which the video says are clocked at 104MHz.

I'm well aware that the clock rate for FPGAs is quite fast. Did you see the implementation of the Cray XMP in an FPGA? Faster than the original, too! Fits in a miniature of the original about the size of a coffee mug.

But this isn't relevant to an audio DAC. It's like writing that an MP3 player uses an 8-core CPU running at 4 GHz!* Wow, talk about an inefficient design!

* NB: This is my desktop. The primary use is not as an MP3 player. But it is a 4 GHz player, for whatever little that is worth.

 

[cpt_paranoia]

I'm fully aware of marketing BS; and that that video is full of it. But, under all that BS, I'm sure there's a working DAC, and probably some interesting engineering. At least I hope there is...

I'm merely interested in a discussion on a point of somewhat idle curiosity, not an argument, so I'll bow out here. We seem to be missing each other's points.

 

[Retrovert]

I explained how you could understand how an FPGA DAC was built using a simple model of motor PWM. Same problem being solved, just simplified so the code is more easily understood and the algorithms simpler. If you understand how the FPGA DAC works for motors, you'll understand building an audio DAC. I also debunked the claims of superiority for a 104 MHz clock as being nonsensical because a DAC only requires a 6 MHz clock rate. So it isn't that I am missing your point at all. I'm trying to explain that the FPGA clock claims are facially nonsensical and trying to interpret obvious marketing hype as engineering fact is doomed to fail.

 

[E-Stat]

... because a DAC only requires a 6 MHz clock rate.

At least those that don't support DSD256.

 

[Retrovert]

At least those that don't support DSD256.

Ok, true, but I specifically quoted a 128x oversampling when I set forth that number in Posting No. 50:

The clock to generate an oversampling at 128x @ 20k Hz is about 6 MHz, easily within the abilities of an inexpensive FPGA.​

Double it for 256x and it's still under 11 MHz.

 

[cpt_paranoia]

I explained how you could understand how an FPGA DAC was built using a simple model of motor PWM

Okay, I'm obviously not explaining my interest clearly.

I understand perfectly well how an analogue signal can be represented digitally, both as a number (PCM), and as a bistream of some form, be it PWM, PPM or PDM.

I understand perfectly well how an FPGA can be used to process digital data to convert PCM or other representation into a bitstream.

I understand perfectly well how a bitstream can be converted to analogue by the use of a clocked switch and a simple filter.

The only thing in the video that piqued my interest was the claimed use of a 104MHz bitstream, because I can see that implementing such a high frequency bitstream converter would be challenging, due to the need to produce 10ns pulses of very consistent energy, to feed into the analogue reconstruction filter.

Now, you might be right, and their 'magic flip-flops' aren't clocking at 104MHz, but at a more conventional rate, and the 104MHz is mere marketing puff. But I'm going on what they say in the video, given that they talk a lot about the much increased sample rate. That's the only thing I have any interest in exploring further; what leads up to that point in the design is, as far as I'm concerned, bread and butter digital design.

 

[Retrovert]

Okay, I'm obviously not explaining my interest clearly.

Here's why I was thinking you didn't understand FPGA DACs. In No. 38 you wrote:

Clearly, they are using the FPGA to implement a custom, oversampling filter. That's still entirely digital, so I'm trying to figure out where the conversion to analogue takes place, and what is performing it.​

So that's why I explained how D to A conversion works with an FPGA.

 

[E-Stat]

Double it for 256x and it's still under 11 MHz.

You are mistaken. DSD256 runs at 11.28 MHz.

 

[Retrovert]

You are mistaken. DSD256 runs at 11.28 MHz.

Yeah, sure. Less than 12 instead of 11. Typo. I wasn't paying attention while I responding while waiting for dinner to finish. I'd written:

The clock to generate an oversampling at 128x @ 20k Hz is about 6 MHz, easily within the abilities of an inexpensive FPGA.​

and since twice 6 is about 12, that's accounted for in my numbers. I wrote less than 11 when I should have written less than 12.

Approximation is less than 6 MHz for 128 and less than 12 MHz for 256. World now safe for democracy? Or DACocracy? Does this even matter? No, it really doesn't.

The point is that while it's easy to build DACs out of DSPs and FPGAs, but that doesn't mean it is a good idea to believe the marketing hype for either. The digital filters in sigma-delta are very complicated, and it is easy to create filters with ringing, ripple, or errors. Many readily become unstable. The amount of simulation and expertise required is considerable, and I would trust the experts at Analog Devices or TI over an ad hoc FPGA implementation.

Barbie say Math is Hard, and Digital Filters are Harder Yet.