1
$\begingroup$

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.
$\endgroup$
  • $\begingroup$ i am opposed to closing this question. i see there is a single vote to close. $\endgroup$ – robert bristow-johnson Feb 6 '19 at 3:04
  • $\begingroup$ 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. $\endgroup$ – robert bristow-johnson Feb 6 '19 at 3:08
  • $\begingroup$ 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. $\endgroup$ – Tioneb Feb 6 '19 at 9:01
  • $\begingroup$ 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. $\endgroup$ – Tioneb Feb 6 '19 at 9:09
  • $\begingroup$ maybe post to the Software Engineering SE. $\endgroup$ – robert bristow-johnson Feb 6 '19 at 19:56
0
$\begingroup$

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.

| improve this answer | |
$\endgroup$
  • $\begingroup$ 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. $\endgroup$ – Jazzmaniac Feb 6 at 16:29
  • $\begingroup$ 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 ! $\endgroup$ – Tioneb Feb 8 at 10:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.