External DSP / FPGA with JUCE



Hi, just wondering if JUCE supports external DSPs or FPGA?
I need to be able to use external DSP power for one of my project but can find any answer on this topic on the community forum. Any clue or plan to support such feature?
Thanks in advance


I‘m planing to do my master theiss on that topic (porting a JUCE-based DSP-Application to an ARM/FPGA SoC and using the FPGA for DSP algorithm acceleration).

What I can say: This is such a complex topic and a lot of it’s problems can‘t be solved by c++, so don‘t expect JUCE to come with any part of the solution.

Knowledge you probaly need might range from Hardware Design (you need some Interface between your FPGA or DSP Evaluation Board and your computer if it‘s no SoC), HDL languages like VHDL or Verilog for the FPGA or maybe take the OpenCL approach or old school C/C++ if you are writing Code for a DSP. And then you probably need some kind of driver for this highly custom Hardware you connect to your computer.

But to narrow it down: What‘s your motivation or application that you think would benefit from this setup?


Hi and thanks for your answer.
Just to give you more background, I want to use external “power” for some of high demanding plugins. It has a lot of benefits for a marginal chipset cost (excluding all other costs here :slight_smile: )
I suppose that it is clearly out of scope of JUCE, and that I should dig further on how to integrate an external DSP with pure C/C++ libs then.


Ok I see.
Just two personal thoughts on accelerating audio processing with external dsps:

  1. I did some research on that topic. If you take a look at all DSP chips available, you will notice that all big companies that produce them (mainly Analog Devices, Texas Instruments and NXP) have stopped developing new DSPs quite a while ago. So high-end DSPs like the TI C66x, as used in Avid HDX hardware, which are probably the most powerful DSPs currently available were developed in 2010. These high-end DSPs have a max. speed of 1.4GHz, lots of other, cheaper devices have a much lower speed (AD Sharc has a max. speed of 500 MHz I think). While on the other hand, there are cheap ARM chips with some quite okay NEON vector acceleration and a speed in the GHz range, which will beat a lot of DSPs in the same price range, even if their architecture is not as optimized as a dedicated DSP architecture by pure overall speedup. If you look at standard Intel CPUs with AAX instruction sets, that are built into most modern computers, these old-fashioned DSPs seem quite outdated. So I can hardly imagine an application where I’d chose the DSP-Hardware-acceleration route over more native processing power or maybe an ARM accelerating the algorithms (which probably will be fully JUCE-compatible, by the way :wink: ). In my personal opinion, Waves went the right direction when they decided to equip their SoundGrid Servers with standard Intel CPUs running a headless Linux. I think there should be a more open solution like that (a standard for an Ethernet-connected Plugin-Server) with a public SDK everyone could code against, just like VST.
  2. There is no such thing as standard DSP-Acceleration Hardware. I know of proprietary solutions like Avid HDX and UAD, but targeting those doesn’t seem to be what you’re looking for, right? Now designing your own hardware is a really challenging task. If you have no experience in this area, I would highly recommend to re-think if there is any other solution, because a custom hardware design including driver design will be pretty expensive.


Hum… that made me remember about the Zynq devices from Xilinx:

They have a ARM cortex processor capable of running a linux OS, where you could run the JUCE app, and in the same encapsulation, a FPGA chip where you can put HDL code, with busses nicely connected to the ARM processor.

So for example, you could make put lots of parallel FPUs in the FPGA, and make them accessible to the JUCE code, so you can vectorize float operations in a ridiculous way.
Of course that would require massive HDL programming, linux device drivers development, etc…

Put it’s a possibility… hehehe


And that‘s exactly the approach I want to evaluate in my master thesis. These are the SoCs ( = System on a Chip - on chip containing multiple architectures, maybe a term only electrical engineers like me are familiar with - sorry for using it without explanation above :grin:) I was talking about in my first reply.

By the way, Intel (Altera) has a lot of similar chips from low- to high-power ranges which I would personally prefer over Xilinx but I guess that’s more a matter of personal taste