Min MHz ARM for audio?

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My assumption is that an ARM doing audio processing must be able to loop at 44.1KHz (22 or 23usecs) and still have 50% cpu left over for doing something. Any Rule Of Thumb for what it takes to do this? 100MHz? 200MHz? Is there a Preferred Audio Codec that everyone likes that I've never heard of? Does the razberry have one of these? I'm way behind as you can see.

Imagecraft compiler user

Last Edited: Thu. Nov 14, 2013 - 01:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What "audio processing" are you talking about? Do you mean a compression/decompression codec, add echo, remove noise, echo cancellation or something else?

Different things cost more CPU than others.

If you are talking about CD quality 44.1kHz you are presumably talking about encoded music rather than anything else (like speech)?

So do you mean soft decode of MP3/Ogg/AAC or similar? What bit rates?

Anyway I've seen some ARM code that needed 48MHz to do MP3 decode but I think that was fairly low rate MP3's like 64kb/s

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

OK, that's less than I thought was needed. Maybe read udp off an ethernet and output stereo to monitor headphones? Volume controls, maybe some automatic gain control to keep from blowing out the ears?

Imagecraft compiler user

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

Just to mention RTP. It's the protocol used in VOIP (along with SIP) which actually delivers the audio data in realtime (RTP = RealTime Protocol). You may want to explore that if you want faithful reproduction of audio.

For one thing routers tend to police a thing called QoS (Quality of Service) and they give priority to RTP as they know it must be delivered on time as a priority. You won't get this with UDP. In fact UDP may be delayed because some higher QoS priority is hogging the bandwidth.

Of course if you want to play the RTP game you need to use something that knows the RTP protocol (and QoS and so on). The obvious candidate is Linux (as it is when virtually any internet protocol is involved). So consider a Raspberry Pi or something. It costs $25, gives you every internet protocol you could ever hope for (and codecs galore like MP3, Ogg, AAC or anything else you can imagine in libavcodec) and the CPU is an ARM9 doing about 600MHz or something so there's no question about it's ability to do even the most complex audio protocols (like AAC) in realtime and at high bit rates.

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

bobgardner wrote:
Does the razberry have one of these?
Broadcast-quality OBs with Raspberry Pis (Talk Unafraid)
but it has an audio/Ethernet problem.
Uses the Opus software codec.
Opus 1.1 does have a speed improvement; Cortex-M?
Refs.
OpenOB - Open Audio over IP for Broadcasters
OB is used for community radio.
Opus update 20130712: 1.1 Beta Release (xiph.org) (search for "speed")

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

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

You Dudes are as far above me as I am above the Ant.

Imagecraft compiler user

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

Then consider xiph's introduction to digital signal processing videos.
The first one is as xiph says a "firehose" but the second one is fascinating.
http://xiph.org/video/

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

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

bobgardner wrote:
My assumption is that an ARM doing audio processing must be able to loop at 44.1KHz (22 or 23usecs) and still have 50% cpu left over for doing something. Any Rule Of Thumb for what it takes to do this? 100MHz? 200MHz? Is there a Preferred Audio Codec that everyone likes that I've never heard of? Does the razberry have one of these? I'm way behind as you can see.
did you consider using DMA to do the A/D samples transfer to memory?

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

Opus MIGHT run on a SAM4 but may need the EBI.
A SAMA5D3 would be a better fit and can run Linux; it has some audio drivers if want a bare board.
ASF has something for SAM3/4 but much more for AVR32 UC3 including software codecs.
Release Notes - SAMA5D3x Software Package (Atmel, 1.3.1, 2013-8, search for aud)
http://asf.atmel.com/docs/latest/search.html?search=audio
Atmel AVR Digital Audio Platform
Edit: added last 2 URLs.

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

Last Edited: Thu. Nov 14, 2013 - 11:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What you need to look for is how big and fast the HW multiplyer is, rather than only raw speed.

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

Quote:
What you need to look for is how big and fast the HW multiplyer is

There are also fixed point implementations and these do not emulate floating point but the whole algorithm is tailored to fixed point.
Quote:
This project gives results which are among the best in the industry, indicate that stereo MP3 at 44.1KHZ and 128KBPS can be decoded using 30-40MIPS on the ARM7TDMI.

So that seems doable on Cortex-M0 with mul, running at below 50MHz.
lfmda

No RSTDISBL, no fun!

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

bobgardner wrote:
You Dudes are as far above me as I am above the Ant.

I'm feeling rather sub-ant here.

I did once try connecting a speaker to a pwm output through an RC filter. I converted a .wav to raw data and played it out from flash. I could hear something attempting to make the intended "ding" sound. So I got the app note and included the op-amp filter on a board I haven't etched yet.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

Quote:

There are also fixed point implementations and these do not emulate floating point but the whole algorithm is tailored to fixed point.

I mean fixed point, but there are a big difference in the speed of the integer multiplyer.
From the smallest cortex without a HW multiplyer to 32x32=>64 in 1 clk. (and even FP)
(and some oddballs in between I used a LPC2138 it's HW multiplyer is 8x32 bit in 1clk).