• Announcements

    • MannDude

      Current state of vpsBoard   02/04/2017

      Dear vpsBoard members and guests:

      Over the last year or two vpsBoard activity and traffic has dwindled. I have had a change of career and interests, and as such am no longer an active member of the web hosting industry.

      Due to time constraints and new interests I no longer wish to continue to maintain vpsBoard. The web site will remain only as an archive to preserve and showcase some of the great material, guides, and industry news that has been generated by members, some of which I remain in contact to this very day and now regard as personal friends.

      I want to thank all of our members who helped make vpsBoard the fastest growing industry forum. In it's prime it was an active and ripe source of activity, news, guides and just general off-topic banter and fun.

      I wish all members and guests the very best, whether it be with your business or your personal projects.

      -MannDude
drmike

Encoding Audio on ARM CPU Devices

17 posts in this topic

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?

Share this post


Link to post
Share on other sites

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

Edited by Fliphost
1 person likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. 

1 person likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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/

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

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.

1 person likes this

Share this post


Link to post
Share on other sites

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.

Edited by drmike

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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).

1 person likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

1 person likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

1 person likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

  • Similar Content

    • By drmike
      I've been cobbling an audio project for a while.  
       
      Some hardcore audio nuts out there with expensive audio suites and racks of sound adjustment gear. I am not one,  yet.
       
      Been banging my head for a while over the audio rendering from onboard audio cards in most stuff (i.e. portables, droids, icrapples, ARM devices, etc.).... The fidelity of such, tends to be horrendous and dimensionally blah. 
       
      Not like I run fancy stuff, but it's painful to listen to moreso with each passing year. Plus all the compression hell.
       
      This lead me to discovering DACs which are for my use, mainly, USB tethered audio cards with upscaling.  They range from Chinese < $20 blah versions to $10k DACs.   Bunches of them in the hundreds of dollars area.
       
      My question for you lads, folks around here using DACs... What DACs have been good and which blah for you?  I am interested in test driving some.
    • By drmike
      G'day chaps!
       
      I have this pile of computers, tablets, "smart"phones, etc.  Audio galore.   
       
      Most of them have the sound output with built in speakers that is laughable and annoying.  Prone to inducing terrible sound and headaches.
       
      Historically I had a pile of cables that went to a mixer and the mixer to a satellite speaker setup.   That worked but is moderately painful to look at and rewiring ends up being annual job.  Plus ability to mix enough things for output at once gets tricky unless you have a big ugly complicated many channel mixer.
       
      Goal is to get steady audio output when I want it with everything piped into satellite or similar real speakers.  Of course, great to shut some things up, while notifications from the phone are mandatory for hearing usually.
       
      Anyone out there doing/recommend something related to simplify or improve this sort of thing?
    • By GIANT_CRAB
      I'm an expert on these matters, so listen up and listen good - I'll try to keep this simple but it won't be easy, because I am an expert, as I mentioned previously.

      Hearing the difference now isn't the reason to encode to FLAC. FLAC uses lossless compression, while MP3 is 'lossy'. What this means is that for each year the MP3 sits on your hard drive, it will lose roughly 12kbps, assuming you have SATA - it's about 15kbps on IDE, but only 7kbps on SCSI, due to rotational velocidensity. You don't want to know how much worse it is on CD-ROM or other optical media.

      I started collecting MP3s in about 2001, and if I try to play any of the tracks I downloaded back then, even the stuff I grabbed at 320kbps, they just sound like crap. The bass is terrible, the midrange...well don't get me started. Some of those albums have degraded down to 32 or even 16kbps. FLAC rips from the same period still sound great, even if they weren't stored correctly, in a cool, dry place. Seriously, stick to FLAC, you may not be able to hear the difference now, but in a year or two, you'll be glad you did.
    • By MannDude
      Been struggling with this one. My system detects my soundcard, yet, here I sit with no sound. Screenshots and command outputs below:
       

       
       
      Ran:

      alsamixer

       




      ~$ cat /proc/asound/cards 0 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xfce78000 irq 21 1 [HDMI ]: HDA-Intel - HDA ATI HDMI HDA ATI HDMI at 0xfe9ec000 irq 42 2 [CA0106 ]: CA0106 - CA0106 Audigy SE [SB0570] at 0xac00 irq 16 ~$ lsmod|grep snd snd_ca0106 38027 2 snd_ac97_codec 106942 1 snd_ca0106 snd_hda_codec_hdmi 30824 2 snd_seq_midi 12848 0 snd_seq_midi_event 13316 1 snd_seq_midi snd_hda_intel 26259 2 snd_rawmidi 23060 2 snd_seq_midi,snd_ca0106 snd_hda_codec 78031 2 snd_hda_intel,snd_hda_codec_hdmi snd_hwdep 13186 1 snd_hda_codec snd_pcm 68083 5 snd_hda_codec,snd_hda_intel,snd_hda_codec_hdmi,snd_ac97_codec,snd_ca0106 snd_page_alloc 13003 3 snd_pcm,snd_hda_intel,snd_ca0106 snd_seq 45126 2 snd_seq_midi_event,snd_seq_midi snd_seq_device 13176 3 snd_seq,snd_rawmidi,snd_seq_midi snd_timer 22917 2 snd_seq,snd_pcm snd 52889 19 snd_timer,snd_seq_device,snd_seq,snd_pcm,snd_hwdep,snd_hda_codec,snd_rawmidi,snd_hda_intel,snd_hda_codec_hdmi,snd_ac97_codec,snd_ca0106 ac97_bus 12510 1 snd_ac97_codec soundcore 13065 1 snd Upon request I did this: 

      nano $HOME/.asoundrc  And made this:
       

      pcm.!default { type hw card 2 device 3 } ~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0] Subdevices: 0/1 Subdevice #0: subdevice #0 card 2: CA0106 [CA0106], device 0: ca0106 [CA0106] Subdevices: 0/1 Subdevice #0: subdevice #0 card 2: CA0106 [CA0106], device 1: ca0106 [CA0106] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: CA0106 [CA0106], device 2: ca0106 [CA0106] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: CA0106 [CA0106], device 3: ca0106 [CA0106] Subdevices: 1/1 Subdevice #0: subdevice #0  
      ~$ sudo cat /proc/asound/cards 0 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xfce78000 irq 21 1 [HDMI ]: HDA-Intel - HDA ATI HDMI HDA ATI HDMI at 0xfe9ec000 irq 42 2 [CA0106 ]: CA0106 - CA0106 Audigy SE [SB0570] at 0xac00 irq 16   
      And here I continue to sit, without audio.