21st Century Audio DSP for the hearing impaired

Go To Last Post
91 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
The threshold of perceiving an 'echo' is 10s of ms. If you can understand someone talking 30 feet from you, you can tolerate the 30ms delay involved.

Well there you go. My concerns are almost certainly unfounded.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

and I've yet to hear a lip sync problem.

In most AV systems the audio and video streams of data (that arrive independently on different PIDs in an MPEG2 data stream) have presentation time stamps so after any processing of the audio or the video or both they can still be delivered to the user in sync simply by synchronising PTS at the final moment of play-out. (except when the DTV firmware throws a wobbly and this fails and 10,000 people phone up to say that Audrey's voice in Coronation Street did not match her mouth movements ;-))

The same is true in RTP supporting V(ideo)oIP over TCP/IP.

And I've seen this myself, though I didn't call in. But since my eyes and brain are doing the video processing, the DSP only has to keep up with that lag.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
bobgardner wrote:
The threshold of perceiving an 'echo' is 10s of ms. If you can understand someone talking 30 feet from you, you can tolerate the 30ms delay involved.

Well there you go. My concerns are almost certainly unfounded.
John, could you please explain to me what this is about? I really don't get it.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A lot of filtering in DSP (FIR) relies on having buffers full of data, and if the samples that follow the one being filtered are relevant(as I believe they are in some operations), then there is an inevitable lag between input and output.

However, if Bob is correct, and I have no reason to suppose otherwise, then the lag will probably be insignificant.

Do not forget my inital statement, however, that I speak from a standpoint of almost total ignorance. I may be talking bollocks.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Smiley, you're welcome.

smileymicros wrote:
Well there is real time and then real time. I think that the algorithms running on an Android or Linux are probably fine for recording sound with various filters applied, but since these OS will randomly stop to garbage collect or send your passwords to Nigeria and you can't control that the delay is noticeable.
Audio-visual (AV) would have a different real-time limit than hard real-time (an example is 3600rpm machine safeties, SawStop, etc.).
Our audio and visual recognition is somewhat tolerant.
Linux does have some real-time additions (ref.1) that reduce the latencies to make Linux useful for AV.
Android is catching up to this though it has the added burden of Dalvik and maintaining throughput and reducing latency.
An Android solution is more cores, more DSPs, and more inter-processor communication (IPC).
smileymicros wrote:
Where as the dedicated DSPs have special features that do nothing but manage fast memory, spin the algorithms, and get the signal through with highest priority. IIRC these dedicated DSPs have fast RAM large enough to hold the samples right adjacent to the logic that processes the data.
DSPs are a part of a study in computer architecture because DSPs fit a necessary niche.
Multiple pipelines (coefficients, data in, data out), significant single cycle arithmetic, etc.
DSP algorithms can be implemented in high level computer languages like C and Ada (and maybe others) (refs. 2, 3); assembly language is also available apparently even for TI's miniDSP.
smileymicros wrote:
I'm guessing that on these devices that it is fast enough since they are being used for hearing applications and I've yet to hear a lip sync problem.
Observations from my time with DSPs:
1. 16-bit DSPs - prototype-able, scary (at the time) package.
2. 32-bit DSPs - video, reduced electrical power in comparison to the alternatives.

Ref.
1. Real Time solutions on AT91SAM SoC, Latency (Linux4SAM)
2. "Support has been added for the Texas Instruments C6X family of processors.", http://gcc.gnu.org/gcc-4.7/changes.html
3. How to build an ARM/DSP Hello World program on the DaVinci EVM (Texas Instruments Wiki)

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
... I woud suggest that real time sync is always going to be a problem, not necessarily because of the processor speed, but because most(all?) digital filtering techniques require a certain buffer size for historical samples.
Any filter, digital or analog, will cause a delay.
The filter exists in a system where the delay is either acceptable or is adjusted for.
If the buffer for a FIR filter is too long then an acceptably near-equivalent IIR filter will have a reduced buffer size.
A potential problem is an IIR filter may not be stable.
That's no problem for audio; simply press the mute button ;-)
(scratch head, re-evaluate coefficients, retest, redesign)

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
The same is true in RTP supporting V(ideo)oIP over TCP/IP.
IIRC this can also done by UDP for audio.
fyi, there's a software audio codec, Opus, that supports RTP.
IIRC one goal for Opus is to aid performance artists for group practices.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I'm thinking about the following learning path:
1. Schedule a block of time weekly to work on audio.
2. Order the TI EVM
3. While waiting for it to arrive, see what I can build on a Raspberry Pi using existing open source projects and see if the lip sync issue I noticed on an Android is a real problem with Linux.
4. Set up a portable TI EVM and PurePath audio learning studio and take it to the local mall food court along with a friend to act as a Yacking Guinea Pig for experimenting with filtering out the background crap to hear the nearby speaker.
5. Report progress and problems here.

It would be great if I could entirely fix the problem for those of us in the Say-What? club using the Raspberry Pi and existing projects, but if not then the custom hardware solution might be viable for the engineers among us who want to play around with audio for assisttive hearing applications.

And since I'm already slammed for time, this is going to take a while - maybe I can get something useful before the Grim Reaper terminates the project.

But first I'm going to spend some more time on the Internet because I can't believe I'm the only person trying to hack at this and there probably is already somebody or some open source project doing just this sort of thing.

Sounds like fun!

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think hearing loss is a frequency response dip in the 3.5KHz range. Its called 'boilermakers disease'. You didnt used to be a riveter in a shipyard did you? This can be compensated for with a commercial off the shelf eq. Its cheap, and if you find that a 12dB boost at 4KHz with a Q of 1.414 helps you hear better, I can send you a schematic of how to do that with an opamp and a couple Rs and Cs. I mentioned this once before, but nobody said 'Yeah Bob... that's a good cheap way to run a selfie frequency response' so I thought I'd offer the suggestion one more time, because I consider you to be a decade old colleague, and if you were within driving distance, we'd be listening to the pink noise thru headphones.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think an analog solution will fix the problem. There is far more to my interest in this than simply frequency response. DSP provides a whole suite of possibilities for modifying the sound environment. There are some simply astonishing things that DSP can do to audio. You may have seen some CSI type cop shows where they get a garbled recording from a crime scene and some geeky guy in a white lab coat runs some SciFi looking programs and suddenly it's like the perp was recorded in a studio. Yeah, SciFi but maybe not so much or for long and maybe it can be done in real time.

Years ago I got to hear what DSP could do for recordings taken in places with a lot or a little background noise and I am wondering if the technology has gotten fast and cheap enough to do similar things in real time so that I can tinker with it. I'd like to be able to sit in a classroom or a restaurant and discriminate the individual I'm interested in hearing from all the surrounding clutter. Twenty years ago I could do that without help, now I can't.

I know an audiologist can diagnose and provide tools to help - but I am a DIYer and a cheapskate so I'm thinking modern DSP devices may be a way I can play with the technology and see what can really be done without having to trust someone with $5000 of my cash to fix my problem for me. I think I've got a good plan and even though it may take me a year, I'm going to work that plan.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
... see what I can build on a Raspberry Pi ...
It's likely already built and in Raspbian's repository.
Debian's package database may be easier to browse to locate applications; these applications are likely also in Raspbian.
http://archive.raspbian.org/raspbian/pool/main/a/audacity/
smileymicros wrote:
... but if not then the custom hardware solution might be viable for the engineers among us ...
The much larger operator population would be the hearing impaired operating something the size of a small digital music player.
Your planned use of an inexpensive Linux board to trial algorithms is flexible.
I hope you'll make it to an alpha test of your custom hardware.
smileymicros wrote:
Sounds like fun!
Yes!
Some of the most rewarding work and effort is towards one's need or someone's need.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Its called 'boilermakers disease'.
Sometimes musicians and some in their audience share an affliction.
Is there a name for that which afflicts an arrogant young man at a loud concert?
source = Jefferson Starship, sink = one of my ears.
I know a fellow who has a lot of tinnitus.
His wife expresses her love for him in many ways; one way was by becoming an audiologist.
bobgardner wrote:
... we'd be listening to the pink noise thru headphones.
Using Gtk-Bounce (xiph.org)
Search for Panel 10.
Replace "white noise" with "pink noise"?

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess Starship had bigger amps than the Airplane. More dBs.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I guess Starship had bigger amps than the Airplane. More dBs.

But no one had amps as big as:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://www.element14.com/community/events/3866
Hi Joe,
It may be too late, or you may be in the wrong geographical area, but see the above link.

John

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Later...
Well, you didn't miss much. The audio quality was appalling and it was 30 minutes of very basic information with a book plug tacked on the end.

If you haven't done so already, I suggest that you dowload this (free)book:
http://www.dspguide.com/

This was what I used to give me a basic grounding in DSP some 15 years ago, when I was asked to write some experimental code for the what used to be the RNID. The project was a wash-out, but that's partly because the party in the middle(the guy who got the contract from the RNID and then contacted me) turned out to be a bit of a con man. The DSP platform I was handed had no chance of meeting the final requirements in terms of speed, power or anything.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
Elektor have a project this month using an Analog Devices ADAU1701 in a LQFP48 package. AD appear to supply a drag-and-drop programming environment for it.
Thank you!
I wasn't aware that Analog Devices was competing in enhanced codecs.
ADAU1701 (Analog Devices)

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
I don't think an analog solution will fix the problem.
Maybe partially (noise cancellation).
AS3501 (ams AG)
Active Noise Cancellation
"Feedforward ANC solution for embedded systems"
Active Noise Cancellation Demo (ams AG)
Data Sheet : AS3501 AS3502 (Mouser)

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An alternative to an operating system like Linux is to use a Real-Time Operating System (RTOS).
Or, none of that (like Rockbox).
More work to get something going without a complete OS but usually doable.
An interesting recent addition to the SAMA5 partner list is NX Engineering and their NuttX RTOS (ref. 1).
The SAMA5D3 NuttX port is fairly complete (ref. 2); currently what's missing audio-wise is I2S and a codec.
Some additions to SAMA5D3 Computer-On-Module (COM).
Create a custom base board (your I/O, rechargeable cell, etc.) that uses the COM.
Likewise are a lot of options using ARM9 and SAM9.

Ref.
1. Atmel SAMA5D3 Partners
2. NuttX, SAMA5D3 (follow the README link, go to its bottom for "To-Do List")

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
If you haven't done so already, I suggest that you dowload this (free)book:
http://www.dspguide.com/
I'll give the book a look, but I also had some experience with DSP a while back and I learned that you can do most everything I want for prerecorded signals. What I'm wanting to know now is if predictive filters and the faster/cheaper machines today can do in real time what could be done back then for recordings. I realize that predictive algorithms will never be as good as have enough front samples like you can get from a recording, but again I think things might have progressed enough now as to be good enough for me.

One big problem at the moment is that this project like so many others seems destined to expand to the point that I'll never be able to find the time to do it. I really need to narrow down to the most likely avenues for success which I think are two:

First do a survey of what runs on Linux on the Raspberry Pi and see how good that is.

Second, get the TI EVM and PurePath and see what I can get out of that.

Then depending on the results which I anticipate will favor the TI solution - put together something technically sophisticated hobbyist to play with. This would probably be of interest to more than just the say-what club since a lot of folks like to dabble with audio and it would be fun just to see what you can do with audio DSP especially if it is Arduino cheap and easy.

We'll see. And thanks for all the advice guys - it is really helping me move forward with this.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
And at the moment it looks like I might ultimately to go with the TI PurePath Studio software and the TLV320DAC3120EVM-U Evaluation Module. That EVM is mono and so am I so it seems a good match.
Pardon the pedantic but you're only partially mono; your brain was wired stereo within your mother's womb.
Psycho-acoustics is difficult.
codec TI miniDSP EVM -
A concern is creating algorithms that won't fit within its limited code and data space.
TI created a concept for mobile digital audio that uses a DSP for all code (ref. 1).
A Rockbox port for that is a hope (refs. 2, 3).
While browsing TI 32-bit DSPs I generated a concern that these may not be easy to prototype without using an adapter; I could not locate a package column within the DSP parts selector.
An eZdsp may be too large and is IIRC a 6 layer PCB (ref. 4).
An alternative is the Analog Devices Blackfin DSP; these have prototype-able packages (i.o.w. a 4 layer or less PCB).
GCC can target most of the Blackfin DSPs.
P.S.
There are some TI 32-bit DSPs in prototype-able packages; found by a search at a TI distributor in QFP are:
C6713, C6720, C6722, C6726, C6743, C6745
There are numerous TI 16-bit DSPs (C5x) in QFP.

Ref.
1. MP3 Player/Recorder (Portable Audio) (Texas Instruments)
2. TMS320DSC25 (Rockbox, Wiki, Archos AV100)
3. Rockbox port to the AV120/140 Devices (Rockbox)
4. TMS320C5515 eZdsp USB Stick (Spectrum Digital)

Edit: added then corrected P.S.

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Jan 28, 2014 - 08:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well one thing didn't take long - Raspberry Pi isn't going to do it. Apparently they have craptastic audio capability and are too slow to do real time DSP.

Some of the TI EVMs are daughter boards that require a $299 mother board. I'll pass on those. Some are in the $75 to $100 range and I can see doing that. The problem right now is that it is difficult to really figure out what they've got and then compare that to what I need. That task may take a while.

As far as being mono - the nerve is pretty much gone in the left ear so, yes it is complicated. One of the main pissers to me is that I have yet to figure out a cheap way to mix a stereo signal and run it through a single earphone. I listen to some old rock and roll and know damn well it didn't sound like that then realize that they've got all the drums on the left side or some such mix. I hope the DSP will be able to fix that. And, yes the Android audio app I put on my Samsung Note 3 will let me mix both channels to my right ear, but I've not seen a simple way to do that with some of the other earphone based systems I'm using.

And as far as doing my own board, well I'll first need to prove the concept with an EVM. I realize the IC will probably be 5mm with 64 BGA grid underneath - way beyond my manufacturing capabilities, but if there is interest in a cheaper board, say one that you could put in a case in your shirt pocket, I might do something ballsy like start a kickstarter campaign to get a professional PCB and assembly run made. But that is a ways down the road. Right now I need to pick a TI EVM and get started with that.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'll give the book a look, but I also had some experience with DSP a while back and I learned that you can do most everything I want for prerecorded signals.

Well, it's a while since(sinc?) I looked at any of this, but I certainly don't recall that the book I linked to was restricted in scope to prerecorded audio.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't step 1 determining freq resp? This is a psychoacoustic problem, not a dsp problem?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Possibly, but the corrective will be with DSP. And it is more than frequency response. When folks get hard of hearing the brain jacks up the signal such that it can be difficult to discriminate a close speakers voice in a room with other nearby folks talking or bad acoustics. Those situations can be filtered via DSP regardless of my particular frequency response. And it is probably even more complex than that which is why I'd like an experimental set up that lets me play with as many DSP algorithms as possible - among them frequency response adjustments - but not just that. I was in a conference room today that when the speaker was talking and no one else was talking I could understand him just fine, but when folks near by started chatting I could no longer understand the speaker. Noise cancellation either via a second microphone or some single microphone DSP algorithm might have taken care of that. I don't really know and being a curious sort I want to run my own tests and see what I can learn.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Well one thing didn't take long - Raspberry Pi isn't going to do it. Apparently they have craptastic audio capability and are too slow to do real time DSP.

Have you explored the Beaglbone Black? It's $45. It has an AM3359AZCZ100 processor running at 1GHz. That is not a DSP but it has a NEON SIMD coprocessor which actually allows for similar kind of performance as NEON is designed for video and audio processing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Well one thing didn't take long - Raspberry Pi isn't going to do it. Apparently they have craptastic audio capability and are too slow to do real time DSP.

Have you explored the Beaglbone Black? It's $45. It has an AM3359AZCZ100 processor running at 1GHz. That is not a DSP but it has a NEON SIMD coprocessor which actually allows for similar kind of performance as NEON is designed for video and audio processing.
I'll look into it, but my experience with Android gives me pause. And it will need to have something useful easily available because I'm already feeling bogged down with possibilities and I need something both certain and easy. But like I said, I'll look into it an report back.

Thanks,
Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

but my experience with Android gives me pause

Wonder what that means? :?

Also you don't have to use Android on that board anyway - like an RPi there are various flavours of "plain" Linux that can be used. By default you'd probably use Angstrom.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eewiki is a DigiKey-centric site for Android and Linux on various boards.
Site Spaces : Android on ARM, Linux on ARM
The BeagleBone Black is currently at Android 4.2.2
Linux on ARM - a number of boards; no Raspberry Pi other than in the comments.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The SAMA5D3 NuttX port is fairly complete (ref. 2); currently what's missing audio-wise is I2S and a codec.

Just a minor clarification. I2S works great. Perhaps you mis-read the README.txt. Is the ISI (aka, Camera) interface that is not complete. Not IIS = I2S.

Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's good to read though the README states
"[NOTE: The above statement is anticipatory: As of this writing I2S driver verification is underway and still not complete]."
for "I2S Loopback Test".

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

but my experience with Android gives me pause

Wonder what that means? :?
Just that I have my doubts now that any OS will support real time DSP that can keep up with an audio signal - the lip sync problem I mentioned. The Beagle Bone Black with an Audio Cape looks like it might do the job but the total cost including the cape is about what one of the TI EVMs would run, so I still have some studying to do.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
The Beagle Bone Black with an Audio Cape ...
Note there's a BBB-compatible version of the audio cape.
http://elinux.org/CircuitCo:Audio_Cape_RevB#Revision_B1

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
The Beagle Bone Black with an Audio Cape looks like it might do the job but the total cost including the cape is about what one of the TI EVMs would run, so I still have some studying to do.
Price of BBB+audio cape is about the same as an eZdsp (16-bit TI DSP, local storage, codec, USB, debugger, IDE).
The 32-bit TI DSP kits plus debugger would be about three times the price of an eZdsp.
TI kits or debuggers come with one license instance of TI's IDE for use on that one kit or debugger.
Otherwise the price of the TI IDE seems reasonable; for 32 bit TI DSP the alternative is GCC.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Olimex DSP describes their effort in reducing the entry cost for DSP.
The Olimex TI emulator appears to have good value and states a free license for TI CCS.
The Olimex DSP development boards for TI C2000 would be a fit for motor DSP; these boards do not have an I2S interface.
Some TI C2000 can have an I2S interface.
F28069 Piccolo controlSTICK may break-out the I2S such that a codec could be attached.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm still muddling over this.

I talked to a guy today in a noisy room with a bunch of people in it and he has digital hearing aids that cancel the noise and focus directly on the person he is talking too. It also has several other modes. He offered to give me his old analog hearing aids but I declined since they are fitted to the ear canal - what I didn't say was the yuck factor...

Anyway, I'm still pondering this. There seem to be many ways to set this up as a DIY project and I still haven't decided the path yet, but I'm pretty set on a TI evaluation board with two microphone inputs for noise cancellation. And I only need one DSP output channel since I'm stone deaf in one ear.

I must schedule a block of time and make the decisions!

Thanks,
Joe

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
I'm sort of convinced at the moment that even an ARM won't do the real time processing needed to run the various filters I'd like to test, ...
PJRC has a Cortex-M4F board and an audio board for it.
The audio library software for it has a signficant FIR filter, a biquad filter, and FFT.
Audio Adaptor Board for Teensy 3.0 & 3.1 (PJRC Store)
Audio Library For Teensy 3 (PJRC)

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

That certainly looks like it might do the job and it has the added advantage that being arduino oriented it shouldn't be too difficult to run some experiments on. Also it is dirt cheap!

What's not to love?

I'll order one of these and a Teensy to go with it and see what I can get going. This might not provide everything that a real hearing aid provides but it might provide enough intermediate functionality that if would do for some situation.

I really appreciate your keeping me apprised of these sorts of things.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this thread still active? I am stone deaf in my right ear and conversing in a car is all but impossible.

 

Are there any DSPs that are compatible with the Arduinio IDE?

Zac

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Is this thread still active? Probably not - it’s been dormant for 4 years!
You don’t necessarily need a dsp processor to do dsp - as mentioned in the thread, there are Cortex M4 processors that should have enough grunt for audio dsp work. The likes of the STM32F407 are supported by the Arduino tools.

Pages