找回密码
 -注册-
楼主: 正点原子

最近做的一款STM32F4板子,软解MP3/FLAC/APE/WAV等,最高支持192K 24位音频播放

[复制链接]
发表于 2014-11-12 04:22 | 显示全部楼层 来自 日本
买过楼主两块板的路过帮顶!!
回复

使用道具 举报

 楼主| 发表于 2014-11-12 11:35 | 显示全部楼层 来自 广东省广州市白云区
引用第26楼cmoslogic于2014-11-12 04:22发表的 :
买过楼主两块板的路过帮顶!!
谢谢支持
回复

使用道具 举报

发表于 2014-11-15 16:35 | 显示全部楼层 来自 广东省深圳市
[quote]引用第0楼正点原子于2014-11-09 17:29发表的 最近做的一款STM32F4板子,软解MP3/FLAC/APE/WAV等,最高支持192K 24位音频播放 :
回复

使用道具 举报

发表于 2014-11-15 20:42 | 显示全部楼层 来自 江苏省苏州市
引用第28楼liyadong于2014-11-15 16:35发表的 :

这个MCU怎么写系统?

系统的话,应该只能上ucos这样级别的
回复

使用道具 举报

发表于 2014-11-15 22:17 | 显示全部楼层 来自 广东省肇庆市
引用第29楼zhangdu于2014-11-15 20:42发表的 :


系统的话,应该只能上ucos这样级别的
嗯,各种类似的都能跑。什么RTT啊,free啊之类的。
回复

使用道具 举报

 楼主| 发表于 2014-11-16 12:06 | 显示全部楼层 来自 广东省广州市荔湾区
引用第28楼liyadong于2014-11-15 16:35发表的 :

这个MCU怎么写系统?
这个MCU支持ucosii,ucosiii,rtt,raw os,trochili等国内外操作系统。
这个实验用的是ucosii
回复

使用道具 举报

发表于 2014-11-18 10:03 | 显示全部楼层 来自 广东省深圳市
这个玩意如果想解APE ULTRA HIGH模式会比较难吧 200兆的CPU估计负荷会较重
回复

使用道具 举报

发表于 2014-11-18 13:07 | 显示全部楼层 来自 江苏省苏州市
引用第32楼liyadong于2014-11-18 10:03发表的 :
这个玩意如果想解APE ULTRA HIGH模式会比较难吧 200兆的CPU估计负荷会较重
等明年M7上市了,就无压力了
回复

使用道具 举报

 楼主| 发表于 2014-11-23 01:14 | 显示全部楼层 来自 江西省萍乡市
引用第26楼liyadong于2014-11-18 10:03发表的 :
这个玩意如果想解APE ULTRA HIGH模式会比较难吧 200兆的CPU估计负荷会较重
APE用F4解不了 ULTRA HIGH。APE解码运算量太大了,flac在这方面完胜。
其实老外比较喜欢flac,ape太耗cpu了。
回复

使用道具 举报

发表于 2014-11-23 20:29 | 显示全部楼层 来自 江苏省苏州市
flac的话,M4有没有可能搞到96k24bit [s:2]
一般48k以上的采样率,都是24bit的了,像96k16bit的,很少见的
回复

使用道具 举报

 楼主| 发表于 2014-11-24 00:04 | 显示全部楼层 来自 江西省萍乡市
引用第29楼zhangdu于2014-11-23 20:29发表的 :
flac的话,M4有没有可能搞到96k24bit [s:2]
一般48k以上的采样率,都是24bit的了,像96k16bit的,很少见的
大大优化代码,最好搞成全汇编的,哈哈,也许可以。
回复

使用道具 举报

发表于 2014-11-24 08:39 | 显示全部楼层 来自 江苏省苏州市
引用第30楼正点原子于2014-11-24 00:04发表的 :

大大优化代码,最好搞成全汇编的,哈哈,也许可以。

好吧,这样估计没戏,不过我有个比较野蛮的方案不知道是否可行,把STM32F4给超频了,我试过超频到240MHz可以运行,但是稳定性不是很好,这个和芯片个体体质有关系,网上有人超到260MHz了,但是另一方面,超到200MHz或者220MHz应该木有问题,不知这样有机会否 [s:2] [s:2]
回复

使用道具 举报

 楼主| 发表于 2014-11-25 22:54 | 显示全部楼层 来自 广东省广州市
[quote]引用第31楼zhangdu于2014-11-24 08:39发表的 :


好吧,这样估计没戏,不过我有个比较野蛮的方案不知道是否可行,把STM32F4给超频了,我试过超频到240MHz可以运行,但是稳定性不是很好,这个和芯片个体体质有关系,网上有人超到260MHz了,但是另一方面,超到200MHz或者220MHz应该木有问题,不知这样有机会否 [s:2]
回复

使用道具 举报

发表于 2014-11-26 13:07 | 显示全部楼层 来自 江苏省苏州市
嗯嗯,哪有机会了我试试,小超一下 [s:2]
其实等到明年F7出来就好了,不过F7的主频有点让人意外啊,400MHz的内核,让ST做成了200MHz,小失望一下
回复

使用道具 举报

 楼主| 发表于 2014-11-26 14:54 | 显示全部楼层 来自 广东省广州市
引用第33楼zhangdu于2014-11-26 13:07发表的 :
嗯嗯,哪有机会了我试试,小超一下 [s:2]
其实等到明年F7出来就好了,不过F7的主频有点让人意外啊,400MHz的内核,让ST做成了200MHz,小失望一下
别家估计会做高频的吧。比如NXP之类的。
回复

使用道具 举报

发表于 2014-11-26 15:14 | 显示全部楼层 来自 江苏省苏州市
引用第34楼正点原子于2014-11-26 14:54发表的 :

别家估计会做高频的吧。比如NXP之类的。

NXP的学习资料没有ST的全面啊,另外NXP在大陆的推广力度赶不上ST,我倒是想学nxp来着,看看那些开发板然后又放弃了,其实NXP做音频比ST更合适;
话说原子有计划推出NXP的开发板么,有的话打算搞一个,主要你家资料很赞
回复

使用道具 举报

发表于 2014-11-26 19:00 | 显示全部楼层 来自 贵州省
外行搭车问一下,据说单片机做播放器音质很好?因为CPU不用处理其它中断什么的所以jitter什么的更低?
果真如此的话,为何不在数字信号输出给DAC之前做个buffer?
回复

使用道具 举报

发表于 2014-11-26 21:15 | 显示全部楼层 来自 上海市徐汇区
引用第36楼2b青年爱发烧于2014-11-26 19:00发表的 :
外行搭车问一下,据说单片机做播放器音质很好?因为CPU不用处理其它中断什么的所以jitter什么的更低?
果真如此的话,为何不在数字信号输出给DAC之前做个buffer?
都dma了,jitter和cpu是否在处理数据关系不大。
回复

使用道具 举报

发表于 2014-11-26 22:44 | 显示全部楼层 来自 江苏省苏州市
引用第36楼2b青年爱发烧于2014-11-26 19:00发表的 :
外行搭车问一下,据说单片机做播放器音质很好?因为CPU不用处理其它中断什么的所以jitter什么的更低?
果真如此的话,为何不在数字信号输出给DAC之前做个buffer?

我悄悄的告诉你,那些说什么cpu处理不过来,会带来更高的jitter的,都是不懂cpu是干啥的;
因为,如果是cpu处理不过来,或者中断没有及时响应,那么,不会是jitter变大,而是数据断流,直接就能听出来;
操作系统处理各个任务的时间片段,应该是在毫秒级别,而不是jitter那种皮秒级别;
另外,就目前的cpu,比如i3i5i7神马的,两三个G的主频,一般应用时绰绰有余的,你可以试试,如果开太多任务,播放音乐,当系统负荷太高时,表现出来的是音乐播放卡顿,而不是什么没有根据的jitter;
而且,mcu的话,i2s数据一般也都是用dma在跑,和cpu在干啥,关系不大,sd卡读数据也可以用dma跑,所以cpu的负荷可能很轻,特别是wav这样的,mcu的i2s外设本身就带有fifo,就是你说的那个buf,只不过比较小,几十个字节,但是算一下,以16bit44.1k,假设fifo32字节,立体声一次用4个字节,也就是8次采样的时间,大约0.18ms,dma每间隔这个时间搬运一次数据补充到fifo,对于上百兆的总线速度,绰绰有余的。
回复

使用道具 举报

发表于 2014-11-26 23:05 | 显示全部楼层 来自 贵州省
引用第37楼bone于2014-11-26 21:15发表的 :

都dma了,jitter和cpu是否在处理数据关系不大。
引用第38楼zhangdu于2014-11-26 22:44发表的 :


我悄悄的告诉你,那些说什么cpu处理不过来,会带来更高的jitter的,都是不懂cpu是干啥的;
因为,如果是cpu处理不过来,或者中断没有及时响应,那么,不会是jitter变大,而是数据断流,直接就能听出来;
操作系统处理各个任务的时间片段,应该是在毫秒级别,而不是jitter那种皮秒级别;
.......

嗦嘎
回复

使用道具 举报

您需要登录后才可以回帖 登录 | -注册-

本版积分规则

Archiver|手机版|粤icp备09046054号|耳机网-耳机大家坛

粤公网安备 44030602000598号 耳机大家坛、www.erji.net、网站LOGO图形均为注册商标

GMT+8, 2024-3-29 02:59

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表