Jump to content
IGNORED

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....


Recommended Posts

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.

 

FPGA is just like trying to build your ultimate race car out of Lego-bricks. It looks a bit like a real thing, but it won't perform like one... ;)

 

FPGA has bunch of limitations and quite a bit of overhead, so it is good for certain very specific segments where you need high speed for very simple tasks like encryption. But not very good when you need high speed for very complex tasks like adaptive SDM... Even reasonably simple things like floating point arithmetics with trigonometric functions, etc can consume a huge FPGA alone.

 

Adaptive algorithms need to modify the algorithm and approaches on the fly based on detected input signal changes, instead of being static algorithm. That would mean reprogramming an FPGA for every sample.

 

 

P.S. If you have unlimited amount of money to spend, you can do all kinds of things with ASICs, but at the moment, IMO, CPUs and GPUs provide most bang for the buck. (pretty good GFLOPS rates with self-adaptive code)

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Mining bitcoin (brute forcing the SHA-256 algorithm) went from CPU to GPU to FPGA to ASIC...

 

SHA-256 is very very simple algorithm and shouldn't be compared to anything worth noting in audio DSP space...

 

DH+RSA+EC-DSA at full PKCS level using interactive key generation would be a starting point in cryptography.

 

Even in the BitCoin field, the actual intelligence is elsewhere and only the simple straightforward brute force heavy lifting is done using some hardware off-load. The actual intelligence to generate the work blobs and to work with the results is elsewhere.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Without knowing the details of Miska's code, development tools etc. his current code is partially clock bound in that it prefers >= 3.5 ghz and I haven't been able to coax more than 3-3.5 cores worth of CPU. Again, with all dual respect because I think his approach and results are terrific, my impression is that the current code doesn't scale well with >4 CPUs I.e a 4 core 4ghz chip performs ****much better**** than an 8 core 2ghz chip

 

Yes, because not everything can be parallelized because there can be dependencies to previous calculation results or sometime the algorithms may decide the some part of the history needs to be re-done based on achieved results, using different kind of approach and then you need to have enough speed to re-calculate the same data multiple times using different strategies...

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
There's user-configurable stuff on the SABRE chips. Don't know for certain whether that extends to adding user-programmed interpolation filters, but I don't see why not.

 

You can upload your custom filters to replace the built-in ones, but the filters are very limited so in the end you don't have so much freedom afterall...

 

(note that you can only change the filters, but not the modulator)

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

Sorry for my short replies earlier (working on iPad) but I fully agree Miska and it is what I meant to say. The relatively simple (mathematically seen) SHA-256 hashing algoritm is suited for ASIC where I could imagine your DSP algorithms are not but of course only you could confirm this since only you actually know your algorithms. :)

 

Edit: SHA-256 hashing is so easy it can be done using a pencil and paper. :)http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html

Link to comment
FPGA is just like trying to build your ultimate race car out of Lego-bricks. It looks a bit like a real thing, but it won't perform like one... ;)

 

FPGA has bunch of limitations and quite a bit of overhead, so it is good for certain very specific segments where you need high speed for very simple tasks like encryption. But not very good when you need high speed for very complex tasks like adaptive SDM... Even reasonably simple things like floating point arithmetics with trigonometric functions, etc can consume a huge FPGA alone.

 

Adaptive algorithms need to modify the algorithm and approaches on the fly based on detected input signal changes, instead of being static algorithm. That would mean reprogramming an FPGA for every sample.

 

 

P.S. If you have unlimited amount of money to spend, you can do all kinds of things with ASICs, but at the moment, IMO, CPUs and GPUs provide most bang for the buck. (pretty good GFLOPS rates with self-adaptive code)

 

I suppose in the end that the complete implementation is what really matters when it comes to the end result.

 

Even if your algorithms are superior to the algorithms in the 9018 chip, or what is possible on a FPGA, could there perhaps be more lost in between the algorithm and the chip using today's best implemented USB interfaces?

 

Is there any chance that what's gained with the superior algorithm, could be lost in other areas?

Link to comment

An FPGA gives a DAC manufacturer complete freedom to develop their own ideas, and be independant of any computer software which can change at the drop of a hat and bricking a DAC in an extreme case.

 

Far as I know, protection systems in industrial gear rely on dedicated chips for speed. Run of the mill programmable logic controllers (PLC) would be and are too slow to cycle through the program, detect a fault and act on it. PLCs have CPU structure similar to a regular computer, but run on their own tailored codes, not an os like OSX or Windows.

AS Profile Equipment List        Say NO to MQA

Link to comment

I have done lots of work on CPUs, FPGAs and ASICs, over the years so I think I have a fairly good idea of the tradeoffs.

 

One of the things that seems to be what is being discussed here is using an already existing general purpose computer, in the tradeoffs is this assumed to be free, or do you include the price of the computer in the tradeoff? Are you including the $600 to buy the computer against $600 of FPGA?

 

Some general observations about the different options:

 

General purpose computer: CAN give a lot of computational horsepower, but has some drawbacks, for me the biggest is getting the data in and out of the thing. You are limited to the IO subsystems existing on the computer. If you are trying to get very high speed multibit info in and or out, you are not going to get it in the ultimate form you want, so you have to do things like USB interface with converter to the format you want, or PCIe interface cards which need drivers etc. It certainly can be done, but it takes time and money to do well.

 

The general purpose computer is great at doing things with large decision trees. For example reading a file off a disk formatted with a modern file system is fairly easy on a processor, but a horrible bear on an FPGA.

 

FPGA: wide range of price and capability. Allows you to generate exactly the interface you want. Very good at doing lots of different things in parallel, particularly when time critical. Can have a lot of computational horsepower. Each individual piece is not as fast as in a high end general CPU, but you can have lots of them running at the same time. You get to choose whatever format, bit length etc you want to work in, you are not shoehorned into the formats supported by the processor.

 

FPGAs are not great at dealing with large decision trees, each decision and branch uses dedicated hardware resources. For fairly simple things this allows very fast multiple decisions to be made in parallel, but gets very bogged down when dealing with complex decisions. The aforementioned reading a file system is a prime example.

 

FPGAs can also be great for simple, low powered things. A $10 FPGA can do a lot of things that are just impossible for a $10 CPU based system to do.

 

As an example of some of these tradeoffs, a while back I was looking into doing some complex filtering for a system, It would take a $200 FPGA to do it, I can have exactly the inputs and outputs I wanted. OR I could do it on a general purpose computer running linux (let's assume you already have the computer so we won't include the price), but the computer doesn't talk the interface I'm using, so it takes a USB interface to be built to talk between the computer and system. That also need a linux driver to be written. Then there is using an embedded processor board with a powerful enough processor to do what is required. A big advantage of these is that they have a LOT of different interfaces available that are not on general purpose computers. For this case it was possible to re-purpose a camera interface to do the right thing, but again that takes a custom linux driver.

 

An ASIC is the ultimate (full custom integrated circuit), you can do anything you want. A processor (or two or 16) to do whatever is best suited to a processor or custom DSP stuff to do any number crunching you want and exactly the interfaces you want. But they take a long time to design and cost a fortune, not very appropriate for high end audio.

 

An interesting hybrid is an FPGA with an ARM processor, the ARM core can do the complex decision making and let the FPGA do DSP and interface.

 

John S.

Link to comment
I have done lots of work on CPUs, FPGAs and ASICs, over the years so I think I have a fairly good idea of the tradeoffs.

 

One of the things that seems to be what is being discussed here is using an already existing general purpose computer, in the tradeoffs is this assumed to be free, or do you include the price of the computer in the tradeoff? Are you including the $600 to buy the computer against $600 of FPGA?

 

Some general observations about the different options:

 

General purpose computer: CAN give a lot of computational horsepower, but has some drawbacks, for me the biggest is getting the data in and out of the thing. You are limited to the IO subsystems existing on the computer. If you are trying to get very high speed multibit info in and or out, you are not going to get it in the ultimate form you want, so you have to do things like USB interface with converter to the format you want, or PCIe interface cards which need drivers etc. It certainly can be done, but it takes time and money to do well.

 

The general purpose computer is great at doing things with large decision trees. For example reading a file off a disk formatted with a modern file system is fairly easy on a processor, but a horrible bear on an FPGA.

 

FPGA: wide range of price and capability. Allows you to generate exactly the interface you want. Very good at doing lots of different things in parallel, particularly when time critical. Can have a lot of computational horsepower. Each individual piece is not as fast as in a high end general CPU, but you can have lots of them running at the same time. You get to choose whatever format, bit length etc you want to work in, you are not shoehorned into the formats supported by the processor.

 

FPGAs are not great at dealing with large decision trees, each decision and branch uses dedicated hardware resources. For fairly simple things this allows very fast multiple decisions to be made in parallel, but gets very bogged down when dealing with complex decisions. The aforementioned reading a file system is a prime example.

 

FPGAs can also be great for simple, low powered things. A $10 FPGA can do a lot of things that are just impossible for a $10 CPU based system to do.

 

As an example of some of these tradeoffs, a while back I was looking into doing some complex filtering for a system, It would take a $200 FPGA to do it, I can have exactly the inputs and outputs I wanted. OR I could do it on a general purpose computer running linux (let's assume you already have the computer so we won't include the price), but the computer doesn't talk the interface I'm using, so it takes a USB interface to be built to talk between the computer and system. That also need a linux driver to be written. Then there is using an embedded processor board with a powerful enough processor to do what is required. A big advantage of these is that they have a LOT of different interfaces available that are not on general purpose computers. For this case it was possible to re-purpose a camera interface to do the right thing, but again that takes a custom linux driver.

 

An ASIC is the ultimate (full custom integrated circuit), you can do anything you want. A processor (or two or 16) to do whatever is best suited to a processor or custom DSP stuff to do any number crunching you want and exactly the interfaces you want. But they take a long time to design and cost a fortune, not very appropriate for high end audio.

 

An interesting hybrid is an FPGA with an ARM processor, the ARM core can do the complex decision making and let the FPGA do DSP and interface.

 

John S.

 

IMO the only real reason to put a computer into the playback chain this day and age, is to take advantage of the great remote interfaces such as Jremote.

 

If using a phenomenal mobile user interface such as Jremote isn't a possibility, what's the point of adding the complexity of a computer, USB interface, endless tweaks, etc into the signal chain vs implementations such as the SD card reader in the Resonessence Mirus?

 

In the case of HQplayer, to get the best from it you need to use not only a computer, but a renderer on the other end of a network. The purpose of this is to isolate the computer that's performing the heavy CPU intensive algorithms from the computer connected to the DAC.

 

Even with all this complexity you still don't have a better user interface experience than a clean, simple and superior SD card direct to FPGA implementation.

 

This implementation avoids so many of the compromises required to get the audio from the source to the DAC chip. Not only that it takes all the extra pieces of equipment out of the picture altogether.

Link to comment
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.

FWIW, we did that at a company I worked for in the early 1970s. Of course, there were no computer chips back then, but we had a specialized computer capable of doing nothing but FFTs, which was faster than an IBM 360 programmed to do it in Fortran. But I get the impression that computers are somewhat faster and cheaper nowadays.

HQPlayer (on 3.8 GHz 8-core i7 iMac 2020) > NAA (on 2012 Mac Mini i7) > RME ADI-2 v2 > Benchmark AHB-2 > Thiel 3.7

Link to comment
For anything to be faster than fortran is pretty remarkable. (I had heard of this kind of chip or whatever it was, btw.) The only modern-day equivalent I can think of is GPU.

 

Been a few years since I used Fortran. I liked the language for its purpose. I hated Cobol. Yuck! But yes, for mathematics Fortran is pretty spiffy. Of course this was mostly on a Xerox Sigma 7 and PDP10 (later on the PDP 11 microcomputer). Briefly Pascal on a PDP11, and then didn't do programming any longer to any extent. Liked the old moonlander game on the PDP11 however.

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment
For anything to be faster than fortran is pretty remarkable. (I had heard of this kind of chip or whatever it was, btw.) The only modern-day equivalent I can think of is GPU.

 

for speed the critical parts are written in assembly.

There is no harm in doubt and skepticism, for it is through these that new discoveries are made. Richard P Feynman

 

http://mqnplayer.blogspot.co.uk/

Link to comment
IMO the only real reason to put a computer into the playback chain this day and age, is to take advantage of the great remote interfaces such as Jremote.

 

If using a phenomenal mobile user interface such as Jremote isn't a possibility, what's the point of adding the complexity of a computer, USB interface, endless tweaks, etc into the signal chain vs implementations such as the SD card reader in the Resonessence Mirus?

 

In the case of HQplayer, to get the best from it you need to use not only a computer, but a renderer on the other end of a network. The purpose of this is to isolate the computer that's performing the heavy CPU intensive algorithms from the computer connected to the DAC.

 

Even with all this complexity you still don't have a better user interface experience than a clean, simple and superior SD card direct to FPGA implementation.

 

This implementation avoids so many of the compromises required to get the audio from the source to the DAC chip. Not only that it takes all the extra pieces of equipment out of the picture altogether.

 

I think you are exaggerating a bit. A renderer for NAA can be a little low power $100 fanless PC which basically consists of a board in a case with Linux built in. Even if you add in a quality PS the cost is fairly low. "Endless tweaks" is also quite an exaggeration. Especially since you aren't immune to some tweaking when you own a Mirus.

 

If you exclusively use HQP your position makes a fair amount of sense, but otherwise the UI/library limitations are a deciding factor. I'd add that there are at least a couple of people working on better interfaces for HQP, including Roon, who've hinted that there implementation will come around the end of the summer. If that happens HQP will definitely be a major player, as it UI limitations will have been "solved."

 

As far as your DAC with SD cards, it's great that you like it. It may be hard for you to understand, but for lots of us that interface "isn't ready for prime time": Lots of limitations in UI, library navigation, and memory size. You can't get any where near the flexibility of UI for your library as you can with just about any modern playback software; and unless you have a very small collection, you have to switch cards to listen to all of your music. One of the main reasons I switched to CA was ending the need to load an LP or disc.

 

There was still a problem with gapless FLAC a while back, have they TOTALLY solved it?

 

None of this may bother you, but for many of us it's an off the top deal breaker. That said, such a setup may well be the future. No doubt that in terms of system complexity and SQ it is a superior method. When they can overcome the UI/navigation limitations and we have semi-affordable cards that hold at least a terabyte, then we will have something that many more users would want to adopt.

Main listening (small home office):

Main setup: Surge protector +>Isol-8 Mini sub Axis Power Strip/Isolation>QuietPC Low Noise Server>Roon (Audiolense DRC)>Stack Audio Link II>Kii Control>Kii Three (on their own electric circuit) >GIK Room Treatments.

Secondary Path: Server with Audiolense RC>RPi4 or analog>Cayin iDAC6 MKII (tube mode) (XLR)>Kii Three .

Bedroom: SBTouch to Cambridge Soundworks Desktop Setup.
Living Room/Kitchen: Ropieee (RPi3b+ with touchscreen) + Schiit Modi3E to a pair of Morel Hogtalare. 

All absolute statements about audio are false :)

Link to comment

I feel you miss the primary point of using HQPlayer- re-sampling.

IMO the only real reason to put a computer into the playback chain this day and age, is to take advantage of the great remote interfaces such as Jremote.

 

If using a phenomenal mobile user interface such as Jremote isn't a possibility, what's the point of adding the complexity of a computer, USB interface, endless tweaks, etc into the signal chain vs implementations such as the SD card reader in the Resonessence Mirus?

 

In the case of HQplayer, to get the best from it you need to use not only a computer, but a renderer on the other end of a network. The purpose of this is to isolate the computer that's performing the heavy CPU intensive algorithms from the computer connected to the DAC.

 

Even with all this complexity you still don't have a better user interface experience than a clean, simple and superior SD card direct to FPGA implementation.

 

This implementation avoids so many of the compromises required to get the audio from the source to the DAC chip. Not only that it takes all the extra pieces of equipment out of the picture altogether.

Forrest:

Win10 i9 9900KS/GTX1060 HQPlayer4>Win10 NAA

DSD>Pavel's DSC2.6>Bent Audio TAP>

Parasound JC1>"Naked" Quad ESL63/Tannoy PS350B subs<100Hz

Link to comment
I feel you miss the primary point of using HQPlayer- re-sampling.

 

He simply likes the internal filtering in the Mirus better.

One never knows, do one? - Fats Waller

The fairest thing we can experience is the mysterious. It is the fundamental emotion which stands at the cradle of true art and true science. - Einstein

Computer, Audirvana -> optical Ethernet to Fitlet3 -> Fibbr Alpha Optical USB -> iFi NEO iDSD DAC -> Apollon Audio 1ET400A Mini (Purifi based) -> Vandersteen 3A Signature.

Link to comment

Blizzard, the other primary reasons I'd point to are cost and ubiquity.

 

Start with a reasonable computer that most people will have anyway. Add, for example, Miska's software. It's been a while since I bought it, so I'll just guesstimate it at $150. Add an NAA, which can easily be done for $100. Miska's DSC1 uses about $400 worth of parts. So you can play in something approaching the Mirus' league with $650 if you're not afraid of a little DIY, using a computer you already have and $650 worth of commonly available electronic items. No surprise this appeals to people who might hesitate to spend nearly $5000 on a Mirus or equivalent.

One never knows, do one? - Fats Waller

The fairest thing we can experience is the mysterious. It is the fundamental emotion which stands at the cradle of true art and true science. - Einstein

Computer, Audirvana -> optical Ethernet to Fitlet3 -> Fibbr Alpha Optical USB -> iFi NEO iDSD DAC -> Apollon Audio 1ET400A Mini (Purifi based) -> Vandersteen 3A Signature.

Link to comment

What - exactly - do you mean by "efficiently?"

 

If you mean using less power, the answer is different than if you are referring to expensive programmer time, and something yet again different if you mean in terms of speed, cost, time to market, maintainability, etc. All have different answers, and all are facts.

 

-Paul

Anyone who considers protocol unimportant has never dealt with a cat DAC.

Robert A. Heinlein

Link to comment

The point I'm getting at is that there's more to a complete system than just algorithms. If your goal is ultimate sound quality there's better ways. If your goal is a better user interface there's better ways.

 

But to get back to the subject of the thread topic. The reason I'm using the SD card reader for an example is because the FPGA is doing 100% of the processing. There's no CPU in the picture except for the one programmed into the FPGA. In my experience so far that system produces the best sound. So based on this the FPGA is better at doing the heavy lifting. Maybe it's not because of the algorithm, but because of the compromises involved in the process of getting the audio from the computer to the DAC chip.

 

Perhaps a lighter weight algorithm preformed on a FPGA could be better than a heavy weight one on a CPU.

 

Either way I'm not knocking the technology. I think it's great. And I hope he keeps developing it.

Link to comment
Blizzard, the other primary reasons I'd point to are cost and ubiquity.

 

Start with a reasonable computer that most people will have anyway. Add, for example, Miska's software. It's been a while since I bought it, so I'll just guesstimate it at $150. Add an NAA, which can easily be done for $100. Miska's DSC1 uses about $400 worth of parts. So you can play in something approaching the Mirus' league with $650 if you're not afraid of a little DIY, using a computer you already have and $650 worth of commonly available electronic items. No surprise this appeals to people who might hesitate to spend nearly $5000 on a Mirus or equivalent.

 

Assuming that system can compete with the Mirus might be a bit of a stretch. But probably a great bang for the buck.

 

I would love to hear and compare it.

Link to comment
An interesting hybrid is an FPGA with an ARM processor, the ARM core can do the complex decision making and let the FPGA do DSP and interface.

 

Not really useful in my case, as the decision making is integral part of the DSP process and needs to run at output sampling rate. So you may need to make complex decisions 24 million times per second...

 

Biggest problem with FPGAs for my purposes is not so great floating point math speed and the amount of gates needed to implement a proper FPU. Another problem are clock frequencies, my algorithms need instruction rates roughly 64x the output sampling frequency. So for DSD512 (48kx512) needs roughly 1.5 GHz clock speed. So suitable FPGA ends up costing about $1k and that doesn't yet bring advantages over using a normal CPU with SSE/AVX instruction set. For example a 3.6 GHz quad-core CPU with AVX-512 could do about 121 billion 64-bit floating point operations per second (32 in parallel at 3.6 GHz clock speed). Another issue are RAM interfaces and cache. In order to sustain needed computations, large cache and high speed RAM interface are needed. My current workstation has quad-channel DDR4-2133 ECC memory interface, adding such to an FPGA would also demand a large and expensive FPGA.

 

Most recent generation of GPUs finally have support for 64-bit (double precision) floating point computations, so those could now be used to perform necessary computations.

 

Biggest advantage of using computer for doing the processing is that people already have it, so there's no necessarily extra cost for the hardware at all. My original idea was just to make most out of already existing computer and DAC. Sort of "software upgrade of the hardware".

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
If you were to develop a complete turn key system right from user digital transport to analog, and the target MSRP was $5000 USD, what would you offer?

 

This includes everything from user interface, to analog outputs.

 

Embedded PC + DSC1 could possibly made to hit that price tag. Adding FPGA to the mix would probably increase the price to somewhere between $20k and $50k while doing the same thing.

 

Small production volume component price for DSC1 with power supply and some very simple case is somewhere around $500, which already translates to around $5000 retail price. ($1500 DAC has BOM of about $150)

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Embedded PC + DSC1 could possibly made to hit that price tag. Adding FPGA to the mix would probably increase the price to somewhere between $20k and $50k while doing the same thing.

 

Small production volume component price for DSC1 with power supply and some very simple case is somewhere around $500, which already translates to around $5000 retail price. ($1500 DAC has BOM of about $150)

 

 

What would you use for components in the embedded PC? It would need to have enough CPU power to handle your best algorithms.

 

You wouldn't implement your NAA into the system?

 

How would you handle the volume control?

Link to comment
Far as I know, protection systems in industrial gear rely on dedicated chips for speed. Run of the mill programmable logic controllers (PLC) would be and are too slow to cycle through the program, detect a fault and act on it. PLCs have CPU structure similar to a regular computer, but run on their own tailored codes, not an os like OSX or Windows.

 

That used to be the mantra to sell expensive specialized hardware, both in industrial and military sector (late 90's). They claimed that COTS hardware wasn't able to do the job. I was happy to prove them wrong by making realtime industrial control systems, sonar and radar DSP systems.

 

Nowadays lot of companies focus specifically on industrial systems based on computers (PCs), more and more these days running Linux.

 

New hot topic is Industrial Internet and IoT which also runs out of familiar technologies and inexpensive standard hardware.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...