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

[Blizzard]

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

 

 

 

I would love to compare a high end Intel I7 computer/DSC1 combo to the Mirus SD card combo.

[Blizzard]

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.

 

 

That looks an awful lot like a FPGA chip to me. Notice how the SD card transport is only 1/2" away.

 

Sorry but no comparison to running a SD card through a computer, then through a USB cable, and then into the USB chip on the left of the FPGA, and then into the FPGA.

[Jud]

[ATTACH]19789[/ATTACH]

 

That looks an awful lot like a FPGA chip to me. Notice how the SD card transport is only 1/2" away.

 

Sorry but no comparison to running a SD card through a computer, then through a USB cable, and then into the USB chip on the left of the FPGA, and then into the FPGA.

 

http://www.resonessencelabs.com/invicta/faq/#Is the SD Card reader simply a feature or does it have some technical advantages over USB for example?

 

Edit: Somewhat less tersely than just a link - (1) There is an FPGA, but they don't use it for filtering/conversion, which is handled by the twin ESS9018 chips. (2) Their beta testers report hearing no difference between SD and USB input any longer after firmware Release 3.

[jabbr]

What task are we talking about exactly?

 

In the early 1990s I spent some time trying to hand optimize code for an Intel i860 ... Let me tell you that current special purpose hardware has largely been replaced by multiple Xeon architectures. The Xeon is able to do a lot including on the fly optimization.

 

So generally:Xeon but there are specific tasks suited to FPGAs

[Jud]

What task are we talking about exactly?

 

In the early 1990s I spent some time trying to hand optimize code for an Intel i860 ... Let me tell you that current special purpose hardware has largely been replaced by multiple Xeon architectures. The Xeon is able to do a lot including on the fly optimization.

 

So generally:Xeon but there are specific tasks suited to FPGAs

 

Interpolation and associated filtering of PCM digital music files, followed by sigma-delta modulation of the converted files, i.e., converting RedBook and higher resolution files to DSD.

[Blizzard]

It is true they have had reports that the USB interface sounds identical. Our listening tests tell otherwise. But since interfacing via USB is so popular these days, downplaying their USB interface implementation vs SD card transport, wouldn't be a wise marketing strategy.

[YashN]

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

 

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

 

Great older threads to read.

[Jud]

It is true they have had reports that the USB interface sounds identical. Our listening tests tell otherwise. But since interfacing via USB is so popular these days, downplaying their USB interface implementation vs SD card transport, wouldn't be a wise marketing strategy.

 

True - but what do you think of them relegating the mighty FPGA to housekeeping duties?!

 

(Kidding, kidding. )

[Blizzard]

http://www.resonessencelabs.com/invicta/faq/#Is the SD Card reader simply a feature or does it have some technical advantages over USB for example?

 

Edit: Somewhat less tersely than just a link - (1) There is an FPGA, but they don't use it for filtering/conversion, which is handled by the twin ESS9018 chips. (2) Their beta testers report hearing no difference between SD and USB input any longer after firmware Release 3.

 

There's actually 7 filter settings. Only 2 of them are preformed on the chip. The other 5 on the FPGA.

 

I mistakenly was among the crowd that reported no difference between the USB interface and SD card transport. This was very early in my testing of the Mirus. One of the main reasons for this was that I was using my media player system which runs a combination of embedded processor, with embedded light weight operating system. Comparing those 2 is very close but after further listening it became clear that the SD card was superior. However when I connected my Mac mini and Intel Nuc using various media player software, the superiority of the SD card transport became very apparent.

[Jud]

There's actually 7 filter settings. Only 2 of them are preformed on the chip. The other 5 on the FPGA.

 

Ah, OK - interesting. Is that on the page I linked (I didn't read the entire thing)? Do you know which ones are done in the FPGA?

[Blizzard]

Ah, OK - interesting. Is that on the page I linked (I didn't read the entire thing)? Do you know which ones are done in the FPGA?

 

 

 

Yes scroll down to the bottom of the page. The Sabre slow roll-off and Sabre fast roll-off are in the Sabre chip. The other 5 are in the FPGA, and are far superior in my opinion.

[Jud]

Yes scroll down to the bottom of the page. The Sabre slow roll-off and Sabre fast roll-off are in the Sabre chip. The other 5 are in the FPGA, and are far superior in my opinion.

 

Hmm, I didn't see anything saying the filters are on the FPGA, either on that page or on the filter information page. I did see this on the filter information page:

 

There is nothing about the INVICTA filters that is ‘magic’ – a competent software programmer who understands digital filters should be able to duplicate all that we have done in a sufficiently powerful computer environment.

[Blizzard]

Hmm, I didn't see anything saying the filters are on the FPGA, either on that page or on the filter information page. I did see this on the filter information page:

 

They didn't build a special 9018 chip for the Invicta/Mirus. Yes it's true the filters aren't magic. They can also be easily duplicated. The location they are being implemented is what's superior.

[Jud]

They didn't build a special 9018 chip for the Invicta/Mirus.

 

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. It could be on the FPGA, but they actually do talk about a couple of functions the FPGA has (for example, decompressing FLAC files) and don't mention the filters.

[jabbr]

Interpolation and associated filtering of PCM digital music files, followed by sigma-delta modulation of the converted files, i.e., converting RedBook and higher resolution files to DSD.

 

My approach, if I were the software developer would be to maximize parallelization of the algorithm such that it could perform better on multiple cores. Even if each core has less than perfect efficiency, eventually adding more cores, using this approach, wins ... or at least that's how the vast majority of current HPC or so-called supercomputers work these days.

[Blizzard]

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. It could be on the FPGA, but they actually do talk about a couple of functions the FPGA has (for example, decompressing FLAC files) and don't mention the filters.

 

 

 

To be honest I just assumed that the other 5 where implemented in the FPGA. I never actually asked that question directly. But if they are custom programmed into the chip, it doesn't mean that filters can't be programmed into the FPGA as well.

 

Even if far better filters can be implemented on a computer, you need to look at the whole picture. What really matters is the end result of the entire system from source material to analog output. With the Mirus, I'm getting the best sound via the SD card transport. And yes I've tried HQ player with all the filter settings. Fun to play with yes, but when I want to do critical listening it's on the SD card.

[Jud]

With the Mirus, I'm getting the best sound via the SD card transport. And yes I've tried HQ player with all the filter settings. Fun to play with yes, but when I want to do critical listening it's on the SD card.

 

Cool.

[Jud]

My approach, if I were the software developer would be to maximize parallelization of the algorithm such that it could perform better on multiple cores. Even if each core has less than perfect efficiency, eventually adding more cores, using this approach, wins ... or at least that's how the vast majority of current HPC or so-called supercomputers work these days.

 

I assume Miska does this. I think I remember him commenting about it, but am not certain. PeterSt's XXHighEnd allows customization of parallelization (sorry for the multisyllables).

[jabbr]

I assume Miska does this. I think I remember him commenting about it, but am not certain. PeterSt's XXHighEnd allows customization of parallelization (sorry for the multisyllables).

 

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. A goal, IMHO, would be to better equalize these two particularly given the D-1540 ... and heaven might be two of these connected by infiniband (rDRAM)

 

Now as an exercise would be to try and match that CPU power with FPGA and so you see...

[esldude]

Now for something completely different..........................follow the money.

 

What is the best most efficient system for mining bitcoin? Dedicated GPU's running dedicated purpose written software. So my answer would be for optimum real-time, most efficient, most powerful filtering use a dedicated GPU.

[jabbr]

Now for something completely different..........................follow the money.

 

What is the best most efficient system for mining bitcoin? Dedicated GPU's running dedicated purpose written software. So my answer would be for optimum real-time, most efficient, most powerful filtering use a dedicated GPU.

 

Good thought.

[devs]

Now for something completely different..........................follow the money.

 

What is the best most efficient system for mining bitcoin? Dedicated GPU's running dedicated purpose written software. So my answer would be for optimum real-time, most efficient, most powerful filtering use a dedicated GPU.

 

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

[Blizzard]

Perhaps Miska will catch wind of this thread soon and chime in with his thoughts.

[devs]

Whether FPGA or ASIC would be more suitable than a general purpose CPU depends on the algorithms used.

[esldude]

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

 

Good information. I was behind the times on bitcoin mining.