Regardless of who has the superior algorithm, heavy lifting tasks can be performed much more efficiently and with much higher precision on chips and FPGAs. This is a well known fact....

[Jud]

The title is a quote from a comment in another thread, which was getting OT there and I figured would be good as the start of its own thread. I was curious about any information anyone had on this well known fact, since it is not well known to me, and I am, as always, eager to be educated.

[Blizzard]

Based on what I heard from a very intelligent and informed source, heavy lifting tasks can be preformed with much higher efficiency and precision if programmed into chips or FPGA's, than if preformed on computer CPU's. This includes things like sophisticated algorithms, DSP etc.

 

If anyone can add to this, or has any evidence otherwise please share.

[Jud]

Thanks Blizzard.

[Blizzard]

Thanks Blizzard.

 

No problem

[wgscott]

Based on what I heard from a very intelligent and informed source, heavy lifting tasks can be preformed with much higher efficiency and precision if programmed into chips or FPGA's, than if preformed on computer CPU's. This includes things like sophisticated algorithms, DSP etc.

 

If anyone can add to this, or has any evidence otherwise please share.

 

 

Sure. We do lots of heavy-duty scientific computing. That's why we purchase separate fftw chips to do our Fourier Transforms. It really speeds everything up by several orders of magnitude.

 

Not.

[Blizzard]

Sure. We do lots of heavy-duty scientific computing. That's why we purchase separate fftw chips to do our Fourier Transforms. It really speeds everything up by several orders of magnitude.

 

Not.

 

I should have said "intelligent to add to this"

[Audio_ELF]

Based on what I heard from a very intelligent and informed source, heavy lifting tasks can be preformed with much higher efficiency and precision if programmed into chips or FPGA's, than if preformed on computer CPU's. This includes things like sophisticated algorithms, DSP etc.

Based on what I have heard from a very intelligent and informed source, heavy lifting tasks can be performed with much higher efficiency and precision if programmed onto a high performance processor such as an Intel Core i7, than if preformed on chips.

 

See I can make the same totally meaningless statements too.

 

So, are you just basing your statement on the information given to you when the designer of the Sabre chip came over for coffee (see http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/exasound-e18-e20-e28-info-and-experiences-post-all-here-17190/index35.html#post446162)?

 

I'm pretty sure the real answer is that options 1, 2 and 3 (on static chip design, with FPGA and through general purpose processors) are all possible and that different designers have different skill sets which mean that different options are best for them. You also have to balance things like power requirements, cooling and OS overheads for things like GP processors.

 

Just my $0.10

 

Eloise

[Blizzard]

Without getting into too much technical detail, from what I understand a FPGA can focus 100% of its power on the task its programmed to preform. On top of that it can be clocked with purpose built precision ultra low phase noise clocks.

 

Yes it's true that a computer processor has much more power. But that power is spread out over millions of tasks, the environment is noisy and the clocks are low grade. What makes your CPU run at 90% on your computer can be done on a FPGA without barely lifting a finger.

 

Also It's a well known fact that high CPU load on a computer has a detrimental effect on sound quality.

[Audio_ELF]

I think the argument is though that what requires 100% of an FPGA's power, can be done with a CPU using 3 or 4% if it's power, therefore if you desire you can run a more complicated filter/process on the CPU.

[Blizzard]

I think the argument is though that what requires 100% of an FPGA's power, can be done with a CPU using 3 or 4% if it's power, therefore if you desire you can run a more complicated filter/process on the CPU.

 

 

 

No it's actually the other way around. Sure maybe if the CPU wasn't running the operating system and it's associated millions of simultaneous calculations.

[YashN]

The title is a quote from a comment in another thread, which was getting OT there and I figured would be good as the start of its own thread. I was curious about any information anyone had on this well known fact

 

Well, we have to take into account whose 'fact' it is and in what context.

 

There is some truth to it generally, but if we're talking purely about Computer Audiophilia, things are much more complex:

 

What good is a great algorithm on an FPGA if the overall system implementation significantly pollutes the ground plane and has significant EMI/RFI emissions which affect SQ much more than the same algorithm or a smaller one on a computer?

 

Ted Smith has a reply somewhere here when asked about doing some modifications to the FPGA so that his DAC would do something people were perceiving could be better for SQ. His reply is enlightening about system implementation.

 

The real advantage of making a chip or FPGA is that you potentially can build a smaller system, i.e. a more focused one that the general-purpose machine that a computer is, the latter having a much larger interference/noise footprint.

 

The biggest advantage of using an FPGA is that your hardware implementation is then easily and cheaply upgraded just by changing a text! It is as if you were coding your hardware. The actual connections and hardware components inside the FPGA are described by a Hardware Description Language. When the manufacturer decides to upgrade the hardware, change connections or change hardware elements, he doesn't need to order new electronic components or a new PCB and do more soldering, he just needs to change that HDL text content and make that available as a type of firmware upgrade for the end-user.

 

Quite amazing really.

[Blizzard]

I'm sure if Miska was to develop a full blown system that consisted of an Intel based computer running software for media player, FPGA for DSP/algorithm processing, and DAC chips for D/A conversion all in 1, the FPGA would be used for the DSP/algorithm processing.

[Jud]

Without getting into too much technical detail, from what I understand a FPGA can focus 100% of its power on the task its programmed to preform. On top of that it can be clocked with purpose built precision ultra low phase noise clocks.

 

Yes it's true that a computer processor has much more power. But that power is spread out over millions of tasks, the environment is noisy and the clocks are low grade.

 

But we're not using the clocks in our computers for critical timing at the DAC (unless you've got a quite old DAC with adaptive USB). We're using the DAC clocks.

 

What makes your CPU run at 90% on your computer can be done on a FPGA without barely lifting a finger.

 

Also It's a well known fact that high CPU load on a computer has a detrimental effect on sound quality.

 

Did you notice you said above that the FPGA would be focusing 100% of its power on running the algorithm, and here you've just said the FPGA would run the algorithm "without barely lifting a finger"? What you said above is more accurate - the FPGA would devote far more of its available resources to running the algorithm than a CPU, for any algorithm an FPGA would be capable of running. (Have a look at resources such as GFLOPS for modern CPUs vs. modern FPGAs.)

 

No filtering software I'm aware of makes even my ancient Core 2 Duo MacBook Pro run anywhere close to 90% load. HQPlayer might run it up to 25% for upsampling to DSD128. Audirvana+ will use the highly thought of bundled iZotope 64-bit SRC to upsample to 352.8/384kHz and barely ever touches 3 or 4% CPU; the software is configured so the resampled file is stored in memory and doesn't impact sonics during playback. This then relieves the DAC chip from having to do upsampling in close proximity to the sensitive DAC circuitry. Of course if you want to completely divorce any electrical effects of filtering/conversion from playback, you can use offline conversion.

 

Edit: Also, (1) you may want to compare prices of DACs with FPGAs to the price of software to do the same or better filtering; and (2) the DAC hardware may become outmoded, while software can be easily updated.

[Blizzard]

maybe because FPGA chips are real time operating systems.

somehow it seems to me that real time operating system works better in audio domain

 

 

 

Exactly. A real time operating system, purpose built for audio and clocked to precision low phase noise clocks. Sorry a general purpose CPU running Windows or OSX in a dirty noisy environment with poor quality clocking just can't compete.

[Blizzard]

But we're not using the clocks in our computers for critical timing at the DAC (unless you've got a quite old DAC with adaptive USB). We're using the DAC clocks.

 

 

 

Did you notice you said above that the FPGA would be focusing 100% of its power on running the algorithm, and here you've just said the FPGA would run the algorithm "without barely lifting a finger"? What you said above is more accurate - the FPGA would devote far more of its available resources to running the algorithm than a CPU, for any algorithm an FPGA would be capable of running. (Have a look at resources such as GFLOPS for modern CPUs vs. modern FPGAs.)

 

No filtering software I'm aware of makes even my ancient Core 2 Duo MacBook Pro run anywhere close to 90% load. HQPlayer might run it up to 25% for upsampling to DSD128. Audirvana+ will use the highly thought of bundled iZotope 64-bit SRC to upsample to 352.8/384kHz and barely ever touches 3 or 4% CPU; the software is configured so the resampled file is stored in memory and doesn't impact sonics during playback. This then relieves the DAC chip from having to do upsampling in close proximity to the sensitive DAC circuitry. Of course if you want to completely divorce any electrical effects of filtering/conversion from playback, you can use offline conversion.

 

Edit: Also, (1) you may want to compare prices of DACs with FPGAs to the price of software to do the same or better filtering; and (2) the DAC hardware may become outmoded, while software can be easily updated.

 

 

 

What I meant was the FPGA would focus 100% of it's resources on the audio related task. Not under 100% load. The load on the FPGA preforming the same task as a general purpose CPU running Windows OSX or Linux, would be much much less.

[Jud]

I'm sure if Miska was to develop a full blown system that consisted of an Intel based computer running software for media player, FPGA for DSP/algorithm processing, and DAC chips for D/A conversion all in 1, the FPGA would be used for the DSP/algorithm processing.

 

You may want to read what Miska's written repeatedly about where he thinks filtering algorithms are best implemented.

[Jud]

What I meant was the FPGA would focus 100% of it's resources on the audio related task. Not under 100% load. The load on the FPGA preforming the same task as a general purpose CPU running Windows OSX or Linux, would be much much less.

 

If the FPGA has far less GFLOPS to devote to the task than the CPU (which is the case), how does your math work out?

[Jud]

Exactly. A real time operating system, purpose built for audio and clocked to precision low phase noise clocks. Sorry a general purpose CPU running Windows or OSX in a dirty noisy environment with poor quality clocking just can't compete.

 

You're tossing around phrases like "real time;" but what that means in the context of audio is that the filtering software is running at the same time the chip is doing playback, producing electrical interference, which is exactly what you don't want.

[Blizzard]

You may want to read what Miska's written repeatedly about where he thinks filtering algorithms are best implemented.

 

 

Yes perhaps if you aren't purpose building a complete system. For general purpose use that's compatible with a variety of DAC's there's no other choice than to implement the filters on computer software.

[Jud]

Yes perhaps if you aren't purpose building a complete system. For general purpose use that's compatible with a variety of DAC's there's no other choice than to implement the filters on computer software.

 

Re complete purpose built system and Miska, Google "DSC1."

[Blizzard]

If the FPGA has far less GFLOPS to devote to the task than the CPU (which is the case), how does your math work out?

 

 

I'm not going to claim to be an FPGA guru. I asked someone who knows far more than you or I know about the topic a question. The answer I got back was that a FPGA was a far better environment to handle these operations. If someone who knows far more than you or I on the topic can chime in on why a computer running Windows, OSX or Linux can do a better job preforming sophisticated DSP/filter algorithms than a dedicated for audio FPGA, we might be able to make some progress on the topic.

[Blizzard]

One thing I can say for absolute certainty is, I've tried every media player, operating system and hardware platform you can think of with my Resonessence Mirus, and haven't found anything that matches the sound quality of the built in SD card transport. 100% of all it's operations are preformed in the FPGA.

[Jud]

I'm not going to claim to be an FPGA guru. I asked someone who knows far more than you or I know about the topic a question. The answer I got back was that a FPGA was a far better environment to handle these operations. If someone who knows far more than you or I on the topic can chime in on why a computer running Windows, OSX or Linux can do a better job preforming sophisticated DSP/filter algorithms than a dedicated for audio FPGA, we might be able to make some progress on the topic.

 

http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/excluding-hi-res-and-high-definition-why-use-digital-analogue-converter-processing-capabilities-greater-16-44-1-a-19507/index2.html#post303697

 

http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/excluding-hi-res-and-high-definition-why-use-digital-analogue-converter-processing-capabilities-greater-16-44-1-a-19507/index2.html#post303701

 

Edit: Also - http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/ayre-wants-%241-5k-direct-stream-digitaled-qb-9-a-15650/index8.html#post229267

[Blizzard]

http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/excluding-hi-res-and-high-definition-why-use-digital-analogue-converter-processing-capabilities-greater-16-44-1-a-19507/index2.html#post303697

 

http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/excluding-hi-res-and-high-definition-why-use-digital-analogue-converter-processing-capabilities-greater-16-44-1-a-19507/index2.html#post303701

 

Edit: Also - http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/ayre-wants-%241-5k-direct-stream-digitaled-qb-9-a-15650/index8.html#post229267

 

 

 

Yes it's a complex topic. Everyone seems to have their own best way. I'm working on a system that is going to require sophisticated DSP algorithms preformed. So I have an extremely open mind to hear everyone's point of view. The point of view I shared was one from someone who has proven to me he knows how to design very good sounding audio products such as the Resonessence line of DAC's, along with the chips in roughly 50% of the high end DAC's on the market today.

 

I'm using the Mirus SD card transport as my reference. If I can match or beat it's sound using any other means possible, I will be all over it. I've also had the rear HDMI port reprogrammed to accept I2S over LVDS. This will allow me to use external interface cards to source I2S signals via LVDS.

[Jud]

One thing I can say for absolute certainty is, I've tried every media player, operating system and hardware platform you can think of with my Resonessence Mirus, and haven't found anything that matches the sound quality of the built in SD card transport. 100% of all it's operations are preformed in the FPGA.

 

You mean in the SABRE DAC chips - no FPGA in the Mirus. Two SABRE DAC chips, ESS9016 and 9018 in the older ones, two ESS9018 in the newer ones.

 

I can certainly understand your preference for the SD card as a means of input. It allows you to disconnect your DAC from other electrical equipment. I've run my system using SD card input into my MacBook Pro (in fact I have my entire music collection on SD cards; that's what I listen to when I travel), and yes, I hear a difference when I disconnect my external FW HDD. I eventually determined I liked playback from a RAMDisk better, perhaps because the SD card input is on the USB bus in my model MBP.

 

An experiment: Try upsampling a RedBook file to DSD128 with Audiophile Inventory (AuI ConverteR 48x44 - Hi-End audio converter high resolution files). Load it and the original RedBook file onto an SD card. Make sure the volume is pretty well equalized between the two. (I think the demo version should be able to adjust the volume of the resulting DSD file if you need to. If it doesn't, send me the RedBook file and I'll send you back a reasonably well volume-matched DSD version.) Play back each with your preferred settings, and tell me which you like better (or if you hear little difference). It could go either way, because the SABRE DAC chips can do further conversion/filtering even on DSD128 files, and I assume they're set up to do so in the Mirus. So you'll be hearing the result of both the software and DAC chip filtering from the DSD file, and just the DAC chip filtering from the RedBook file.