I'm hugely disappointed that Rockbox on my Sansa e200 series player won't play HE-AAC v2 acceptably fast. I know their decoder is capable, because I can play AAC+ using the Rockbox in DOS box emulator in Windows, but on my player there are a few seconds of sound followed by silence followed by sound ...
One of their head honchos, llorean, answered a question in their forums with the assertion that HE-AAC uses lots of processor power, so only Toshiba's Gigabeat is up to the task.
I had understood that Ogg Vorbis -- which plays splendidly in Rockbox -- was more taxing on CPUs. And, after all, some really ancient and low-powered Pocket PCs and Palm Pilots play AAC+ just fine.
Isn't it really more likely that the the Rockbox project simply hasn't worked on optimizations for AAC+ decoding? And, if somebody here knows how to do that, would they please contribute the technique to Rockbox?

Vorbis requires a lot of memory, which is a killer for most embedded CPUs.

But HE-AAC and even more so HE-AACv2 are more demanding on the CPU processing power itself.

Thanks, Garf.
Do you think a v1 Nero Digital HE-AAC is worth trying? If so, what would be good parameters to test?
Since I narrowly escaped freezing the Sansa with my HE-AAC experiments, what Nero LC-AAC encoder settings would produce files of quality comparable to the 64 kbps CT/AAC+ used by XM Satellite and Radio@AOL?

I hope I'm permitted another follow-up .
I also have the diminutive Meizu M6 (fits in the case with my Nokia N800!). The Meizu obviously has good CPU power since I can watch movies encoded with BobbyQ's "Batman." An even more powerful CPU is in the latest from another China company, Teclast; I rejected that one because Teclast is criticized for poor firmware with audible hiss.
So, my question: Are the new generation MP4 video players most likely to to have CPUs that could play HE-AAC v2?
Lamentably, Rockbox isn't so likely to support players that most of the world has to import via eBay.
But, I was just wondering why a company like Teclast which hasn't the required firmware expertise doesn't simply open up their specifications and invite Rockbox to port to their player.

As far as I know, Rockbox has no problem playing HE-AAC on the supported Toshiba Gigabeat players. They have a relatively powerful CPU...

With a better optimized AAC decoder (the current one is hardly optimized at all), HE-AACv1 might be possible on slower hardware like the Sansa, at least if the numbers about the Helix decoder that are mentioned here are close to real-world performance. The Helix code isn't GPL-compatible though, so it isn't an option.

Has anyone ever compiled the CPU requirements, and perhaps a list of theoretically capable devices, for decoding - as an example - 64kbps HE-AAC v1 (with SBR, but without PS)?

"Smart" phones have been able to handle this for a while, via TCPMP and the plugin from RareWares. Yes, the old plugins do indeed work with v0.72RC1 of TCPMP, all platforms. My old Samsung i600 (Win CE) did so without any problems, as did my wife's old Treo 650 (Palm). And I just benchmarked my new Treo 680 (also Palm) as being able to decode such files at an average speed of 261%.

It's just difficult to believe a device as advanced as an iPhone, or a video iPod, would lack the "umph" to get the same job done.

- M.

M, thanks for understanding my point.
TCMP on my Pocket Loox 720 plays perfectly the files that stall the Rockboxed Sansa.

Right! So now all we need is a project to either lobotomize old phones to "upgrade" iPods and the like (making the processor capable?), or an effort to port* the old GPL Source Code for TCPMP to such devices, if the processor already meets the theoretical requirements.

- M.

* ... or someone could work on a method of allowing Rockbox to interpret and use TCPMP plugins from existing platforms. Might be like banging your head against a rock (in a box), though.

TCPMP uses the same AAC decoder as Rockbox (based on a different version though), so porting that isn't likely to help much. I had a quick look at the code, and they don't appear to have changed the actual decoder library much (if at all).

The reason "old" smartphones can do the decoding is simply that the CPU is powerful enough, in the same range as the Gigabeat.

This thread actually caused me to spend a little time Googling TCPMP/Betaplayer developments. It appears there was another free release after 0.72RC1, which was labeled 0.81RC1. I've managed to find the PocketPC version and what appears to be the Smartphone version... but does anyone know whether 0.81RC1 exists for Palm OS? Since 0.81RC1 added skin support, it would be nice!

- M.

Edit: May not be worth it... in this thread, betaboy says "0.81 is BAD.... dont bother with it... the skin interface is a hack, it runs slower, it uses more resources.... why bother?!" (Of course, I'm guessing betaboy would prefer folks purchase CorePlayer, but he would also be in a fair position to know.)

Edit2: A bit more Googling turned up this. So now the question is whether "Smartlyric" (with skin support) exists for Palm OS....