Getting started with DSP - any suggestions?

[NewestRigolUser]

Hi fellows,
I'm going to buy my first DSP, soon.
I'd like to manupulate audio signals. And as I'm a guitar player, that's my usecase.
First I'd like to create highpass and bandpass/-stop filters. Then I'd like to create a chorus, flanger, fuzz, tubescreamer and stuff like this.
When I'm more experienced, I'd like to create a reverb and even a delay.
And in the end I'd really like to create my own looper - which might need access to external memory.

I spent somd hours on searching for the right DSP to start with. The ADAU1701 seems to be very famous - but it lacks on memory for reverb effects.
Then I found the ADAU1452. This shall lack on ADC and DAC but it shall have enough memory for a simple reverb.
So maybe the ADAU1452 might be a good choice to start with.

On the other hand there are TI devices with nice specs, i.e. TMS320C6652 . It hat 600MHz and supports DDR3 memory.

But as I'm not yet experienced with DSPs I don't wanna spent more than 200 bucks on my starter setup.

I have a signalgenerator, scope (DS1054) and bench PSUs right here. And I'd like to use free software (as there are some devices that require expensive software which would not fit my bill...).

What would you guys suggest to use?

[nctnico]

Start with Octave (a free Matlab replacement) first and then test your implementations on a PC. Once you know your algorithms work it is time to add real embedded hardware in the mix. By the way: you should seriously consider using a regular ARM based microcontrollers. These have lots of processing power and are more suitable for general purpose work as well. I'd only consider a DSP if I really need lots of processing power.

[apblog]

General purpose microcontrollers are so fast now that there isn’t as much need for specialty DSP chips unless you really need maximum performance...  And it sounds like you don’t.

DSPs can sometimes be difficult to program. I’m thinking in particular of TI C6000 chips where getting maximum performance requires that write you assembly and pay attention to “delay slots”.  You have to write your instructions out of order, manually, so they can execute in parallel.  It’s a massive pain.  The peripherals can be more complex too, and there is less beginner info out there for DSP chips.

You might be better off with something like a STM32 or PIC32 series and a nice devel board with audio I/O for learning purposes.   Just a thought.

[NewestRigolUser]

When it comes to cab-impulses or reverb, indeed it needs massive performance. I've read a lot about DSC (digital signal controllers) - but they just have simple filterblocks and are not suiteable for a complex effect unit.

Octave sounds interesting, as I don't wanna support Matlab (wrote them a request for pricing 3 month ago and never got an answer - they don't wanna get my money ).
www.r-project.org shall be a replacement for Matlab as well. Have to have a closer look at both of them

The advantage of DSPs is flotingpoint operations, memory extensions, as well as anti-aliasing. I plan to have at least 24bit 96kHz - so I'm not sure if there is any ARM that's fast enough for this.
Sure, I won't start at those high rates. At the beginning I'm happy is I can pass a signal from input to output, no matter which resolution

Even if it's not easy to get used to program a DSP, I'm willing to learn this. In an ADI world (ADAU-DSPs) there's SigmaStudio which makes the basic setup quite easy. But additional, custom filters need to be creates using Matlab (I hope the free tools might be suitable as well!).

Have you guys been playin' around with DSPs?

[Marco]

Calling the configuration of a SigmaDSP programming is being a bit generous.

Bela is a DSP software/hardware project based on Beaglebone Black which lets you do hard real-time low latency audio processing on it. Plenty of processing power and memory, a ton cheaper than evaluation board from Analog or TI ... only downside, no visual "programming". You have to do actual programming.

There is also the STM32F7 discovery kit, it has SDRAM and plenty of power, but you'll be even more on your own in programming it than with Bela. It doesn't seem to have had a lot of uptake for audio DSP among hobbyists.

[NewestRigolUser]

The BeagleBone's ARM seems to be less powerfull than my old Banana Pi. And it even has less ram. Not sure if it's worth to play around with. Some years ago there's been a project using the first RPi as guitar effect unit. But it wasn't convincing.
Using precompiled images usually community support on those SoCs is quite good. But if we're talking about RTOS there might be quite nobody to help you. RTOS still is not famous enough - so I guess working with an DSP might be the better choice (tough I'm not totally up-to-date with newer ARM devices).

[Marco]

All that is true, but your banana pi doesn't have all the software and documentation Bela created.

There aren't a lot of SBCs with Linux hard real time support. Basically the Beaglebone Black/Pocketbeagle, the Rasberri Pis and the Zynq. Getting to the point where you can passthrough audio and start DSP programming will likely take you a while on a Pi or Zynq board relative to Bela. It's a whole different ballgame than normal Linux programming, which the guitar effect unit was probably done with. You can't access the audio I/O through the Linux drivers, everything has to happen through the realtime OS running under Linux (Xenomai Cobalt). That's why the Bela project is valuable, it hides most of the nastiness and just gives you samples in and lets you write samples out.

As for processing power, if you lack it on a Beaglebone black for handling single channel audio you're doing it wrong.

[apblog]

The STM32F4 series has floating point and runs at up to 180Mhz.  Zynq is ARM based and the low end ones are dual core running at approximately 600Mhz.  Plenty of blazing fast non-fpga ARM micros are out there as well.

Personally I think that Linux is a waste of time for a simple DSP effects processor.  It will just add to your difficulties.

Nctnico had the right idea with his suggestion to start in Octave and then move to a PC (for non-realtime file processing tests.).  My advice is also to break the problem into manageable segments.

[Marco]

STM32F4 boards won't have a lot of memory, the F7 discovery board does. There are no free hard realtime OS's for most ARM SBCs and bare metal programming on something with that many systems to initialize is a giant headache. The easiest high power SBCs to run hard real time operating systems on are probably x86.

With Bela, Linux just configures the hardware for you, if that's all you want it to do ... if you want the network stack or do some scripting on the board it's nice to have Linux, but you can ignore it if you want. The audio processing runs independently on the real time kernel underneath. With the basic pass-through example he'll be ready to add processing code very quickly. He doesn't have to worry about Linux or hardware, but it will be low latency. That's the whole point of using their solution, it solves the hard problems for you.

[Marco]

When it comes to cab-impulses or reverb, indeed it needs massive performance.

It doesn't if you implement it smart, it's just so much easier to do it stupidly.

[tsman]

The BeagleBone's ARM seems to be less powerfull than my old Banana Pi. And it even has less ram. Not sure if it's worth to play around with.

The major feature of the TI SoC on the Beaglebone boards is that they've got Programmable Real-time Units. They're 2x 200MHz microcontrollers that have access to the SoC peripherals and main memory. You can do a lot of realtime tasks on them that would be a lot more difficult on other SoCs like the Raspberry Pi one. Read this for more info.

[radiolistener]

you can use FPGA for high speed realtime signal processing. It allows you to perform realtime signal processing at very high sample rate (for example 100-200 million samples per second)

[NewestRigolUser]

Hmmmsounds as the F7 would be a suitable device for that. But I still don't like the idea of using an ARM.
I have bad feelings about DAC/DCA quality, reliability on the signal, ressources and EOL (how long will the chip be available? Is it documented well and cheap enough to create my own PCB with? Else it's not worth spending time on it!).

Whatlatency might I get using an ARM? Is it compareable to an DSP? 5ms do make a big difference!

[iMo]

But as I'm not yet experienced with DSPs

Start small. There is a lot of stuff you have to master before you get what you plan. Unless you acquire a "ready to use box" it will be a long way to go, indeed.
An FPGA adds much more barriers to enter. Any better arm/mips based mcu with an external 16bit adc and dac will do your "dsp start" easily..

[apblog]

Hmmmsounds as the F7 would be a suitable device for that. But I still don't like the idea of using an ARM.
I have bad feelings about DAC/DCA quality, reliability on the signal, ressources and EOL (how long will the chip be available? Is it documented well and cheap enough to create my own PCB with? Else it's not worth spending time on it!).

Whatlatency might I get using an ARM? Is it compareable to an DSP? 5ms do make a big difference!

If you are going for quality, external conversion is a must no matter what chip you use.

ARM has some of  the best documentation I have ever seen, and ST is quite good as well.  I wouldn’t worry too much about ST going EOL, and even if it does the port to another ST would be very easy.

I think what we are trying to tell you to that might not seem obvious is that “DSP chip” is in many ways just a marketing term.  Don’t think that you need a DSP chip to do DSP.  The term had real relevance in the 90’s when clock speeds were low and microcontrollers had very simple-minded designs.  Architectural enhancements were key to getting any kind of math performance out of a chip.

But these days most of those enhancements are found in ordinary processors.  Things like excellent DMA, I2S peripherals, floating point, fast multipliers and SIMD instructions are all common now.

Modern DSP chips are still better performing than their general purpose counterparts.  But that extra performance is now needed for really hard things like radar and real time video processing, not audio.

By the way, I did a C6000 project about ten years ago.  it was giant pain in part due to (IMHO) TI’s terse and confusing documentation.  Never again...

[Marco]

Hmmmsounds as the F7 would be a suitable device for that. But I still don't like the idea of using an ARM.
I have bad feelings about DAC/DCA quality

It has I2S, people have used it to make asynchronous USB DACs and soundcards.

EOL (how long will the chip be available?

It's a microcontroller from a major manufacturer.

Is it documented well and cheap enough to create my own PCB with?

I doubt you will find anything cheaper with that level of performance which can use DRAM.

Whatlatency might I get using an ARM?

With any hard real time system you will have basically zero latency, if your algorithms are zero latency. It's only when you start using a normal OS such as standard Windows/MacOS/Linux that latency becomes a problem (Linux with Xenomai is a different beast than standard Linux though, Bela also has negligible latency).

[NewestRigolUser]

Well, I've got some STM32 right here (from the beginning of the Nucleo-series) and one one hand no good documentation was available whilst on the other hand the toolbox didn't support the boards anymore when I finally wanted to play around with this devices about 1-2 years later.
So I don't lije to mess around with STM32 series...but remember: my experience was in the beginning of the Nucleo series! Maybe that changed.
STM32 mainly supports IAR Workbench, KEIL and mbed online (at least when I googled it last time). That's none of my favs, as I prefer opensource or freeware.

[NewestRigolUser]

Bela supports a lightweight and simple Arduino-like API that allows you to focus on the core functionality of your code. The IDE also includes a browser-based oscilloscope to visualise and debug your sensor and audio data in real time.

A browser-based scope sounds interesting. Might be a helpful tool to not always start your DSO. Makes developing independent from your bench - I like this idea!
But how about 24bit ADC/DACs using 96kHz on beagle bone, might it handle it?

//Edit:

The reason why the clock is 44.1kHz is because digital I/O and analog I/O are also clocked by the audio codec and these tasks take time to complete and if the audio sampling rate was higher there would not be enough time for them to run. If you were to disable analog and digital I/O you could probably easily get to 48kHz without further modifications.

Doesn't sound good...

The reason why the bit-depth in use is 16bit is because the noise floor on the board would make the additional 8bits pretty much useless. Also, operating on 16bit values simplifies the code and requires less memory (the PRU, which handles the I/O, has access to 12kB of RAM only), allowing larger blocksizes. Similarly, another good reason for 44.1kHz is that the "upgrade" to 48kHz would probably go unnoticed given the noise floor and it would just require more computations.

Doesn't sound good, too...

[Kalvin]

You can get started with a PC and audio card using Octave and C/C++. Record the sounds into a disk file and process the data through the DSP filter/algorithm. You can use Octave or write the code in C/C++/Java/Python and save the processed data into the file for playback. I suggest to start with Octave and then convert the algorithms into C/C++ as you will get results fast in Octave and the target hardware will be using C/C++ anyway. When you get your algorithms working on a PC, it is typically quite trivial to port them to be running on a real target hardware - unless you run into hardware limitations like running out of CPU cycles for real-time processing or RAM. Typically you need to implement hardware specific functions for reading the ADC and writing to DAC and some UI for the user controlling the system. Start with something simple like reading the audio input and outputting it back without any processing. Gradually add some filtering/algorithms. Probably you will end up spending more time implementing the UI than actual filtering stuff.

[coppice]

For most audio DSP the best place to experiment is on a PC. Even built in sound cards are pretty reasonable these days, and very high quality USB ones are not too expensive. Real time guitar processing needs low latency, and this can be the Achilles heal of many platforms. Nonetheless there is some pretty good open source guitar processing software which runs on PCs without horrendous latency these days.

[radiolistener]

Here is a demo of guitar effects implemented with FPGA:



This is Terasic DE1-SoC board: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=836

Here is another example:

[Marco]

But how about 24bit ADC/DACs using 96kHz on beagle bone, might it handle it?

Apart from long impulse response reverbs there are few audio effects which require a ton of processing power, everything you mentioned is stuff you would have implemented 30 years ago on a 56001 DSP. That's a 33 MMAC DSP, a Beaglebone Black does 4 GMAC with NEON.

[nctnico]

Either way it is better to create the algorithms first and then see which hardware fits best. Going the other way round is very likely to be a major waste of time. The choosen hardware platform may be overkill (expensive and/or difficult to program) or too limited (time wasted on trying to optimise).

[radiolistener]

But how about 24bit ADC/DACs using 96kHz on beagle bone, might it handle it?

With FPGA you can implement DSP for 32bit ADC/DAC 192kHz/Quadraphonic sound end even more   

[PartialDischarge]

Also consider the programming tools/compilers. Their use AND price.
With ST you got atollic which is free but with TI...