吐血推荐：FAAC/FAAD最新版本

snaper

audiocoding.com网站无法续费而被迫关闭，我们深感遗憾，不过audiocoding原来是sourceforge下面的自由项目，sourceforge网站下还可以同步下载最新的更新。
FAAC最新版本是1.25
FAAD最新版本是2.5
http://sourceforge.net/project/showfiles.php?group_id=704[/COLOR]
  总体感觉，FAAC/FAAD功能强大，直接支持到了EAAC+（AAC++或AAC+V2），没有任何与平台相关的库文件，默认平台是x86，在ARM，MIPS平台上编译只需很少的改动。我现在用FAAD2.5在ARM平台上跑，只做LC类型解码，代码空间和数据空间在100K左右，堆栈空间64K左右，堆栈占用了较多空间是因为程序中用到了庞大的局部变量数组。消耗的处理器资源大概在10MIPS左右（假设为零等待存储器），实际应用中加入中断处理和存储器读写延迟等影响，刚好够44.1K采样率，128k码率的实时播放（音质还不错）。
  上述情况是在源码基本没有优化的条件下得到的（直接拿来用），我对比了ARM公司的音频软件提供商spritDSP提供的benchemark发现，这种性能和代码效率确实在嵌入式平台上没有可取之处，人家堆栈空间只有500字节啊，我都不知道是怎么作出来的。所以要想让它少占资源，必须从代码根本上去解决，主要是算法和数据结构上。
  首先我们注意到，嵌入式应用中我们不可能用到它的那么多功能，我先目前来说首要问题是LC类型的解码，因为SBR的解码又要复杂将近一倍，而PS的解码复杂度并不高。从联通和移动的多媒体手机功能需求上看，LC profile是强制要求，而HE profile是可选的（高端手机）。所以选择LC是比较合适的，这样一来FAAD的代码量可以大大“减肥”了。数据结构上，其定义的结构是复杂的，如在有些函数体中毫不吝惜的分配了大量临时数据，使得编程上虽然好理解，但堆栈就有点可怕了。
  其次，在算法结构上，AAC占用资源最多的是MDCT模块，而目前公认的MDCT快速算法都是来源于FFT，也就是说最后的运算都要转为FFT。这就有一个问题，FFT是运算密集型应用，每一个具体平台都有它独特的特点，也就是说快速实现是和具体平台相关的。FAAD的FFT算法直接是用Swarztrauber在87年FORTRAN编写的算法转为C语言的，好处是再任何平台上不用做任何修改，但效率就很难说了，对于ARM9E平台，我用基4汇编写的FFT在性能上要提升三倍之多，可见算法优化空间还是蛮大得。
  再次，就是查找表的精度问题，在定点运算中，FAAD用的常量数据都是32精度（Q31格式），实际上很多DSP，ARM处理器在应用中都是用32×16位的，所有很多都可以把精度降为Q15的，当然这样做也会对最终解码数据精度产生影响，不过早有前辈证明过这些影响都是在指标范围内（见一致性测试标准ISO/IEC 14496－4）。
（今天就写到这，待续中...）
http://sourceforge.net/project/showfiles.php?group_id=704

yaoyongqiang

欢迎接着续写[em01][em01][em01]

lhwei

顶起来
接着写啊，楼主

lhwei

能说说你在做FFT优化的时候
具体改进的是哪几个函数吗

lintiaotiao

ding