Encoding Audio on ARM CPU Devices

[drmike]

Anyone here using any ARM-based CPUs for doing audio encoding?   Can be something in a datacenter or it can be something on your desk.

Interested in MP3 encoding mostly and LAME based.   Looking to see what anyone is squeezing out of ARM platform on performance, especially with the multi core boards.

Tried earlier ARM based single cores and have been very underwhelmed.  Was lucky to achieve 1-1 ratio of playtime of the recording vs. time to re-encode the audio.  Since it takes 100% CPU, isn't feasible in any way.

Looking to leverage ARM solution due to power consumption and flexibility there, plus ability to run silent / fanless in a small form factor.

Anyone?

 

[Awmusic12635]

Have you considered using one of the newer intel atoms? They have pretty decent CPU power in a lower power setup.

 

[drmike]

Have you considered using one of the newer intel atoms? They have pretty decent CPU power in a lower power setup.

I have considered the new release Atoms.  Problem is form factor and power.  Smallest board with those is a mini itx (which is big for my application and embedding).

Performance per watt is good on those, but constant power draw minimum is too high.

Intending on running these off grid via solar and battery, so watts matter in an annoying degree.  Thus the ARM platform selection.

 

[Deleted]

ARM lacks certain instructions like XMM so it's doing software based encoding which is an order of magnitude slower. Atoms are x86, ARM doesn't have a lot of ins that x86 has to do multimedia. 

 

[drmike]

No doubt about it @.  Considering the impressive performance on many Android devices involving media (set-top boxes, tablets, phones, etc.) something must be accelerating the decoding.  Ideally something out there with hardware support for MP3 or other competing audio codecs for the encode and decode sides.

Performance doesn't need to be stellar.  Not expecting say 40-to-1 ratio on time.   Something say 10-to-1 I'd think is doable with the multi-cores.

Turns out LAME is notoriously slow on ARM gear.  Others have bemoaned this elsewhere.  Partial solution is to move to another older codec more based upon the original MP3 spec.  That however is really only suitable for high bitrate encoding.  In this instance I actually need to degrade the audio down to a low bit rate (32k ~ or in line with mono AM radio signal).

Bandwidth / internet in this solution isn't really reliable or available depending.  So I can ship file to remote, re-encode and get the file back - reliably.

 

[willie]

ARM has the Neon multimedia extensions, same general idea as XMM though the details differ.  Might also be possible to encode with a GPU.  It sounds to me like LAME hasn't been optimized for the ARM, rather than that something is wrong with the ARM processor itself. 

What are you trying to do, that requires solar-powered off-grid encoding of mp3's?

The new Minnowboard (Atom board) is smaller than mini itx, if that matters.

http://www.minnowboard.org/meet-minnowboard-max/

 

[Deleted]

LAME is slow because it has #ifdefs for instructions (if I remember correctly, havent looked at the sourcecode in years) and then it can only do some/most/all of them in software, which makes it slow; In a nutshell,LAME has to emulate instructions in userland, which makes it dogshit slow. 

ARM is nice for lowpower, but sucks for complex things like encoding. I would avoid it if you have to use it for things like 

 

[ihatetonyy]

I tried my hand at using a Raspberry Pi for encoding a police scanner stream - the raw point wasn't encoding, which was actually OK, but was the audio capture.. which was pretty shit.

With the new Wolfson card you may find yourself in a better position; for that matter, one of the new-fangled boards like the ODROID should run circles around the Pi and have better USB support to boot.

 

[drmike]

ARM has the Neon multimedia extensions, same general idea as XMM though the details differ.  Might also be possible to encode with a GPU.  It sounds to me like LAME hasn't been optimized for the ARM, rather than that something is wrong with the ARM processor itself. 

What are you trying to do, that requires solar-powered off-grid encoding of mp3's?

Offloading to GPU sounds interesting.  Unsure if anything really supports it.  LAME in general is just retarded.  Still doesn't support multiple cores.  There is a Windows derivative someone has made multithreaded, but I don't do Windows.

As for the project, it is a bunch of stuff.  Generic top view, it's wifi based network with tiny nodes out there on poles, on roofs, etc.  Each site is bundled with a set of gear - solar panel, battery, charge controller, antennas,  general computing platform, wifi, SDR for various spectrum tinkering and needs, perhaps transmitters depending.

On said network there is to be a storage node the ends can communicate with / will feed and take in data.  Re-encoding will happen there as needed and on end nodes live time from various sources (i.e. existing radio signals transmitted by others).

Right now it is a proof of concept to see where I can take the ends at distance with reliability and work on reliable throughput.  So a platform play.  Down the road special use cases to be defined.

The re-encoding stuff shows up a lot in my world feeding signals from broadcast up and out (AM/FM mainly).  Environments where the source materials exist + bandwidth + accessibility for such often is random.  Not everyone happily plugs at their mixing console.   Some stuff we pull off radio spectrum remotely, re-encode, then blast up to online servers.  Historically, limitations with gear, full sized desktops, big expense, etc.

There are custom solutions out there for this stuff - like Barix, but the devices are expensive and non hackable.

 

[drmike]

So... amazing to me that in mainline Linux there doesn't appear to have been much improvement or development of MP3 encoding in past few years.

OGG and others - open are getting platform attention.  Considering testing their codecs to see how encoding time and quality are.

Offloading to GPU for MP3 encoding, perhaps someone does it, but isn't something over the weekend one glues together.  Sadly. 

Back to the drawing board for me.   I thought performance was in ARM by now and the software for encoding would have been improved

The new Minnowboard (Atom board) is smaller than mini itx, if that matters.

http://www.minnowboard.org/meet-minnowboard-max/

Interesting board.  I looked up the CPU Mark though and went blah about it.  It comes in on the dual core model under what the dual core Atom 330 does performance wise.    Somewhere between the 220 and 330 on performance.

More performance than a N270 but less than a N570.

 

[wlanboy]

Nice topic.

If you look at following page http://www.mp3-tech.org/programmer/encoding.html

you will find:

Shine Fixed Point (release 0.1.2) : - Layer 3 - C/Asm - 39 k
This is a port of Shine to Arm and StrongArm fixed point. It provides a 30x speedup over the floating point release.

Second last on the list.

Another entry point is the Helix community https://datatype.helixcommunity.org/Mp3dec

The Helix MP3 decoder provides MPEG-compliant decoding of MP3 content. Both floating-point and fixed-point decoder implementations are available. The fixed-point decoder is optimized especially for ARM processors but can run on any 32-bit fixed-point processor which can perform a long multiply operation (two 32-bit inputs generating a 64-bit result) and long multiply-accumulate (long multiply with 64-bit accumulator).

 

[drmike]

Nice topic.

If you look at following page http://www.mp3-tech.org/programmer/encoding.html

you will find:

Second last on the list.

Another entry point is the Helix community https://datatype.helixcommunity.org/Mp3dec

I found or rather refound the shine port of LAME right after posting this.   It's ancient.  Talking late 1990's I do believe.  It's meh unless dealing with high bitrate (which I am not in this instance).  But, it's roughly 2-3x faster than recent LAME on ARM platforms.

Helix I stumbled into.  The decoder seems fine, no problem there though with other out of box stuff currently.  Still looking for Helix encoder   Unclear if such a thing exists.   There had been something in the past, but unsure if related and if Linux dev'd too.

I am underwhelmed by the options and general head hit wall many run into on this.  Heck as common as this is, you'd think there would be a market for cheap hardware based encoder that you could tether to whatever to offload. (probably is something like this availble, but very exotic, niche, overpriced).

A few chips I've ran into just for this sort of purpose.  Finding gear packaging such, haven't found.

 

[willie]

There are hardware mp3 encoder chips that use very little power.  They're really just DSP's with special firmware of course.  They are used in consumer audio recorders, so they can't be too expensive, at least in quantity.  I don't know if there's something comparable for Vorbis.  Did you try the regular Vorbis encoder on your ARM?

 

[drmike]

There are hardware mp3 encoder chips that use very little power.  They're really just DSP's with special firmware of course.  They are used in consumer audio recorders, so they can't be too expensive, at least in quantity.  I don't know if there's something comparable for Vorbis.  Did you try the regular Vorbis encoder on your ARM?

I'd try an out of case mp3 encoder chip solution in a hearbeat if I could identify a reasonably low cost unit with docs for Linux.

Vorbis I haven't tried yet.  It appears to have same default floating point dependencies it seems.  But it's on my list to experiment with since it is under current development, open source, etc.

 

[willie]

ARMs have floating point: the A8 etc. have the Neon coprocessor and the Cortex M4 has 32-bit ieee floats and DSP extensions. 

 

[drmike]

ARMs have floating point: the A8 etc. have the Neon coprocessor and the Cortex M4 has 32-bit ieee floats and DSP extensions. 

Good to know / realize.

Most of the new ARM stuff I am considering are A8's or newer.

I am going to have to hunt their communities looking for folks to run some tests to see how said gear does on the encoding.

Turns out the Raspberry Pi DOES have a floating point co-processor.  But, unsure if Debian and current Raspbian ship with proper config to utilize these (stuff in prior years hadn't).  Whole other bunch of searching for this, as I have Pi's here on workbench already.

 

[drmike]

... and the Raspberry Pi floating point works if you run Raspbian OS.  Off to check what I have running there (probably Debian).