Hi Paul,
unfortunately, at this stage, i cannot further specify "audio fx instance". As you said, it could be literally anything. Possibly the question shouldn't be as objective as "how many times more powerful is a DSP compared to an ARM", but rather be a subjective question asking what, given your own experiences, you would recommend me to use. I know that even this isn't a simple question, since the project description is more than vague. But even something as simple as "Better go with a DSP, because X" or "given that you are willing to optimize the **** out of your algo for the given device, it will run faster on a DSP/ARM" could be valuable advice. Regarding dynamic loading, I'm sure I can find an adequate solution satisfying my needs for any given device. Even compiling multiple modules into one monolithic image and then use build-in software switches to bypass certain modules again and repeatedly flashing this monolithic image (upon reconfiguration) using USB is satisfying enough. And even the most short lived program memory types should be good for a couple of hundred writes, which will be plenty, given adequate simulation software is available for the development environment. Thank you for writing down your thoughts, each though is greatly appreciated. I'll look forward to further input and keep everyone posted about the progress. Thanks, Max ________________________________ Von: music-dsp-boun...@music.columbia.edu <music-dsp-boun...@music.columbia.edu> im Auftrag von Paul Stoffregen <p...@pjrc.com> Gesendet: Freitag, 26. August 2016 18:50 An: music-dsp@music.columbia.edu Betreff: Re: [music-dsp] Choosing the right DSP, what things to look out for? On 08/25/2016 04:44 AM, Max K wrote: Also I yet lack an estimate of how much more audio fx instances a true DSP can handle compared to an ARM, which is a crucial decision factor. But what precisely is an "audio fx instance"? That could mean pretty much anything, from very lightweight operations such as variable gain controlled by a linear-ramp ADSR envelope to something as intensive as a phase vocoder or 1000+ tap FIR filter. Even with the algorithm precisely specified, how quickly it runs on any particular chip can vary depending on implementation details. Performance also depends greatly on the amount of time spent optimizing and level of skill of the programmer. For example, Cortex-M4 has special fixed point DSP extension instructions accessed by inline assembly or compiler intrinsics, which don't follow normal C language semantics and require very careful planning of packed data formats, loop unrolling and register allocation. Using these hardware features effectively requires tremendous effort. Normally only special libraries get this sort of intense optimization. If you take the normal path of using libraries for DSP operations, the overall performance depends on the library's performance, and whether you have to write other algorithms not provided by an optimized library. On top of all that is the small matter of whether these hardware platforms and their software environments are suitable for dynamic loading from files on a SD card. Again using Cortex-M4 as an example, most of those chips are meant to execute code from internal flash memory, which has limited endurance for reprogramming. They can also execute from RAM, but typically there's much less RAM available, which is also needed for all your programs variables and data buffers. DSP chips usually have multiple memory regions meant for different purposes, about as far as you can get from the simple flat Von Neumann memory model of general purpose PCs. Normally programs are compiled as a fixed monolithic image. Dynamic loading on PCs usually involves dynamic memory management, which it in turn built on top of an operating system and virtual memory management hardware which reassigns physical memory to a virtual memory address space seen by individual software programs. How your system would accomplish something similar is a good question. Whether the flexibility of dynamic loading and dynamic memory management imposes a cost on your code's performance is also something to consider. Or perhaps your "audio fx instances" will look more like small scripts or bytecode instructions run by an interpreter? Again, performance impacts to consider.... I don't have the answers to these questions. Realistically, probably nobody does. To really answer "how much more audio fx instances a true DSP can handle compared to an ARM" would require someone to pour an incredible amount of engineering time into deeply investigating these implementation details, in the context of your unspecified algorithms and whatever dynamic loading mechanisms might be possible on each chip. I'm pretty sure the actual answers will come only as you truly get into the implementation details. If you do and if you learn some of these answers as you go, I hope you'll share.
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
