最新消息:20210816 当前crifan.com域名已被污染,为防止失联,请关注(页面右下角的)公众号

【经验与教训】当CPU频率降低后,硬件解码播放MP3出现卡的现象

经验和教训 crifan 2052浏览 0评论

【问题】

在Linux系统中,没有实现cpu 的freq driver之前,其设置是:

CPU,AHBV(video domain),AHBP(peripheral domain)的频率分别是400MHz,200MHz,100MHz,此时系统性能很好,但是功耗很高。

为了实现功耗管理,实现了cpu freq driver,使用ondemand或者consertive的governor管理器去动态管理cpu频率,当cpu负载低的时候,可以动态调节cpu频率,调到很低,此处我的cpu freq驱动中设置的最低是24MHz。此处由于底层频率设置的函数的考虑,当CPU是24MHz的时候,AHBV和AHBP都是24MHz。

此时,出现一个问题,就是,用硬件MP3解码器audhwdecoder去解码播放MP3文件,声音一卡一卡的。

【分析解决过程】

之所以这个是问题,是因为:

于此对应地,在另外一套Segger为平台的系统SDK中,已经实现了,在播放MP3的时候,CPU和AHBV,AHBP的频率最低可以只用12MHz,即可实现audhwdecoder解码播放MP3.甚至是当MP3是常见的44100的samplerate和128Kbps的时候,只需要8.5MHz即可。而且SDK中的CPU的电压还是从1.4V调到0.8V左右,整体系统性能,比同样的CPU频率,性能更低,功耗更低。

所以,此时Linux系统中,即使Linux的系统的overhead很大,此时CPU,AHBV,AHBP都是24MHz的时候,而且cpu电压还是没调节的1.4V,所以没理由不能正常通过硬件解码播放MP3的。

1.开始是怀疑上层的应用程序往硬件mp3解码器audhw送数据没有及时,导致底层数据接收不够,中间有停顿时间,所以声音会卡。后来去改了应用程序,一次往底层audhw写入足够多的数据,比如50个0x400,而且单位是word(4个字节)。这样通过DMA传输给audhw,硬件就有足够的数据用于解码了。

2.但是问题依旧。怀疑是I2SOUT的问题,然后去根据SDK,去加了对应调节AUDIO的clock。但是问题依旧。

3.最后调试找到根本原因,原来是audhw有个CLKDIVIDER寄存器,在用户app层,调用底层audhw驱动的ioctl的时候,会在设置对应的输出为MP3格式的同时,去设置clock divider为1/6,即硬件MP3解码器的工作频率为输入频率的1/6,所以,当设置CPU为24MHz时,AHBP为24MHz,而硬件mp3解码器的输入频率就是AHBP,所以实际audhw的频率为24/6=4MHz,远低于最低工作频率9MHz左右,所以很难正常流畅的解码MP3。

【经验与教训】

以后更加要理解,对于每一个device,多数都是有自己的clock divider的,这样,device可以自己决定使用多少clock。如果对此概念很熟悉,那么之前那次看SDK中的代码,去设置MP3的CLKDIVIDER的时候,就会注意到,而不会忽视了。

转载请注明:在路上 » 【经验与教训】当CPU频率降低后,硬件解码播放MP3出现卡的现象

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
79 queries in 0.171 seconds, using 21.90MB memory