1

I am trying to find a nice clean solution to this problem since some days now, and couldn't make myself to stick to a solution.

I need to develop some stream and block processing for audio, including cascaded biquad, FT and iFT, FIR, dynamic correction. The whole audio chain will be embedded either in a DSP or on a ARM running Xenomai Linux.

What I am looking for is a way to quickly compile and test bits of codes, getting audio in and out, and in a language that will allow me to target a broad range of devices. (Would be C or Cpp surely).

I don't want to choose the definitive platform now because I don't know yet how much processing power will be required to make my full project runs.

Here are some tought:

  • I am using Gnu Octave but afaik it will not compile a real-time pipeline and the code is hardly portable.
  • I tried Audio Weaver from DSP Concepts (which is great) but the targets DSP are limited and the engine is proprietary.
  • I looked at Faust which is a very promising framework for audio (even able to generate Cpp code), but unfortunately it was designed with stream processing in mind and not meant to process blocks of data
  • I looked at some LabView + FPGA solution but the price and licensing is just WOW !
  • I looked at some IDE from Ti and AD but there also the price is too high.
  • Using a simple VST or ALSA framework might be ok but I don't really know where to start.
Tioneb
  • 111
  • 2
  • i am opposed to closing this question. i see there is a single vote to close. – robert bristow-johnson Feb 06 '19 at 03:04
  • you can stream audio by processing blocks of data. the mechanism to do that is **double buffering**. processing by blocks of samples makes code efficient. //"*The whole audio chain will be embedded either in a DSP or on a ARM running Xenomai Linux.*"// --- do you know which one? if DSP, which DSP? that choice makes a difference. – robert bristow-johnson Feb 06 '19 at 03:08
  • I don't know at the moment. I hope everything will fit in a ARM SOM but there are other stuf going on (webserver, networking, display...). The costs are low for Linux SOM these times. If I have to defer to a DSP, I will surely be on a Ti C6000 architecture. – Tioneb Feb 06 '19 at 09:01
  • Thanks for your opposition on the closing. The question looks development/hardware related but really touches the heart the heart of the signal processing subject. I am also going to ask it on the Electronics Stack Exchange. – Tioneb Feb 06 '19 at 09:09
  • maybe post to the Software Engineering SE. – robert bristow-johnson Feb 06 '19 at 19:56
  • I found a related Ask: https://dsp.stackexchange.com/questions/912/analogous-library-to-opencv-for-audio-processing-analysis/914#914 – Tioneb Feb 06 '19 at 20:01

1 Answers1

0

I finally settled on python, and here is why:

I had no reason to limit myself to a specific language or framework. The target plateform was not specified, but I needed to have proof of concepts for the project, and quick.

I choose python because of its versatility, the profusion of libraries, the speed over other scientific calculation packages, and the scientific community.

And so far so good.

Tioneb
  • 111
  • 2
  • I would strongly recommend checking out Julia before committing to Python. Julia is *fast*, it has a very active community, it is easy to learn and has all the scientific calculation packages you could ever need. – Jazzmaniac Feb 06 '20 at 16:29
  • Oh yes ! I checked it some years ago when it didn't had that much traction. It is *ridiculously* fast ! Amazing language. I didn't remembered it at the time I started to work with python... Will give it a go again. Thanks for the reminder ! – Tioneb Feb 08 '20 at 10:37