I want to get my teeth back into a new Audio related project. I'll be designing from the ground up and was considering using an ARM Cortex-M7 based device.
Most of the current devices I examine support Audio through I2S ports, but also limit connectivity to other external devices like SDRAM which I want my device to have (for storing long Impulse Responses and delay lines).
I am wondering what you all are using and what might be the most popular, and still low cost, devices for Audio these days?
Previously I used FPGAs since I could define all the connectivity myself, but of course FPGAs can be a bit pricey and audio signal processing doesn't require too much power normally...
I'd appreciate any suggestions from the community...
Not strictly a true DSP, but I use STM32 ARM processors for a lot of audio DSP. Any of the families with Cortex M4F do quite nicely - even the low end STM32F3xx parts have sufficient horsepower for some decent audio. If you need external SDRAM then definitely look at the F4, F7 and H7 families - they're sufficiently powerful to do FFT-based convolution effects, reverb, etc. Hardware-wise they're inexpensive and easy to DIY if you're handy with a soldering iron, but if not then the pre-built devboards are super affordable.
Thanks yes STM32F7 and F4 devices are on my list for consideration. It seems tricky figuring out which one(s) will allow the simultaneous and uncomplicated use of the I2S ports (I'd like to use 3 if possible) with external memory as well. Usually they have shared pin functions which makes it difficult if not impossible, hardware-wise.
But I'll take another look using STM32 Cube MX and see if there's a combo that works.
Replying to Robert: yes the new ARM Cortex-M chips have dedicated DSP sections, some with floating point. There's also an optimized library called CMSIS from ARM which makes the DSP functions efficient.
See if you can find examples of how they use their FMC/FSMC to interface with external ram. Beyond that, sacrificing a modest number of samples worth of latency will allow you to use their DMA in double buffer mode, which should make parsing 3 audio streams a breeze. Beware the HAL implementation for DMA from ST, it is super confusing. I ended up using a combination of their source and some custom code to get it running. Without knowing the actual PN I can’t say for sure you won’t hit a muxing issue with the pin out, but at face value it seems totally doable. The nucleo boards are super affordable too, which makes prototyping way more cost effective
I still have yet to really do any work on an ARM even though I am told that some C code I wrote (and tested with Xcode) found its application on a phone running some ARM.
And I think that some ARMs have a built-in DSP, but I am unfamiliar with it.
Doing DSP in a more general-purpose CPU is fine, but you have to worry about modulo arithmetic or some method of efficiently implementing a circular buffer for delay lines and FIRs and the like. With a DSP chip there is usually a hardware mechanism for the "wrap-around" addressing for a circular buffer. If I am programming in pure C, I usually do it with a buffer of length of a power of two and do simple bit-masking on the index.
If you want to use a dedicated DSP chip, I guess the only decent modern ones are either some TI chip or an ADI SHArC.
ARM's Cortex-M4F claims to have "DSP instructions" but it's nowhere near as cycle-efficient as a "real" DSP would be - no simultaneous operand buses, no auto looping and addressing, etc. Basically boils down to a few MAC instructions that might save a cycle here and there. Frankly I find that the hardware floating point has much greater positive impact on my applications.
The real benefit of these low-end ARMS is that they have pretty good peripherals and DMA, coupled with reasonable IRQ latency. I use the SPI/I2S and SAI ports, driven with custom circular DMA configurations (don't try to get by with just the HAL/CubeMX auto-generated code) to do fairly complex tasks in synthesis and effects.
When using non-DSPs for DSP work, high speed, peripherals, and low cost can cure a lot of ills. But, as stated, their use comes with some baggage.
I've been riding the ADI train for a long time - from the 218X/2106X to now the 58X. I like their DSPs. I've thought of branching off to other manufacturers, but I have never developed sufficient urgency.
I've been experimenting recently with the ADI SigmaDSP codecs for a couple of upcoming projects. Using them forces a user to conform to a predefined operation set. ...and that's not typically what signal processing folks prefer. ...but - for many projects - the predefined functions are all that is needed and their application is quick and easy.
I've seen Sigma Studio and have a friend who was raving about those low cost audio processors. They look terrific for basic FX and EQ algorithms, though they lacked the memory for delays and long reverbs. Still I have to agree - a very attractive development environment!
We're working a lot with FPGAs. You can get really cheap devices meanwhile, so price is not an issue. But if it comes to algorithms, I'd not deliberately choose such a device. Because fundamental programming and overcoming obstacles may cost a lot of time, while programming in a dedicated OS brings it all "batteries included".
Years ago, I had the chance to work with a SHARK device (Analog Devices).
Most of all I liked the OS layer (Visual DSP++).
Simply spoken, it is a fully baken ready-to-use system where you just install interrupts for incoming/outgoing ports like I2S, let it do the basic work in a fairly potential signal path (C++) for filtering etc.
Superimposed you find threads and processes almost like in a linux system.
If it were my choice, and if I could afford, it would still be my favorite choice.
For a more sophisticated system, my next check would be an FPGA with an embedded processor (Zync is fine, but maybe overkill). If ethernet comes into play, I'd certainly aim at Linux (either on Xilinx FPGA or on a BlackFIN).
Trying to sum up my experience: hardware for audio processing is not critical.
But you'll spend most of the time and invest most efforts in programming the software/libraries/OS. So make sure you really like/enjoy working with that.
- Renesas RZ/A1: Cortex-A9 based, 400 MHz, Floating Point (NEON), available also in LQFP. From 3MB up to 10 MB internal SRAM. Amazing for long delay lines, impulse responses, etc...
- Renesas Synergy S5/S7. Cortex M4F based (120 MHz / 240 MHz respectively), up to 640 kB SRAM, also internal.
- Analog Devices SHARC (up to 1x Cortex-A5 and 2x SHACR+ DSPs, also available in LQFP)
- Analog Devices Blackfin