请教用了文件系统拼语音的产品,有哪些提速绝招

自已做的MP3模块,想用到数字播报系统上去,用户反映说数字播报中间有停顿感,不连续,并举证说程控交换机上的语音卡与我的MP3模块做对比测试,同样的语音,俺这模块说话有点结巴.
俺已采取以下措施:
1.将每个语音片要播报数字预处理,找到每个数字的起始簇号,播放时直接读簇,除掉遍历目录项查找文件需要的时间.
2.将主控MCU的外频达最大.

俺没做过程控交换机语音播报卡,未悉其中玄机.请大家说说还能有些什么办法提速.不用客气,想到什么尽管说,主要是想多寻些思路.先谢谢大家了.

补充一下,播报单个文件是很流畅的,结巴的是数字之间,比如数字168就需要依次放1.mp3,6.mp3,8.mp3文件的内容.在1.mp3与6.mp3之间会有延时停顿.

可不可以将那些数字音频文件在系统初始化的时候就先读出？总共也就10个吧，应该不大，呵呵。
另外那些音频文件用cooledit打开看看波形是否头和尾有空白信号，有则删掉空白，可能可以节省一些时间，如果不能处理文件就没办法了。
音乐换曲应该会慢的。

交换机的语音播放卡和MP3播放系统是不同的，前者是数字录音机，而MP3播放芯片调入新文件的速度本来就较慢，还要解压缩，一旦选定了某款播放芯片，文件切换速度的上限就已经确定了，提高操控MCU的速度最多只能争取到微秒到毫秒量级的速度，完全可以忽略，要从文件本身和播放芯片上找找是否还有潜力，比如截去文件头尾的空白时间、降低采样率，研究播放芯片本身，是否能够通过操控、设置来提高文件定位、载入的速度等，这方面可与播放芯片制造商联系咨询一下。

在播放的同时就去预处理下一个要播放的片段嘛。

用RAM缓冲数据，缓冲到一定数据量再开始播放

2楼： 补充一下,播报单个文件是很流畅的,结巴的是数字之间,比如数字168就需要依次放1.mp3,6.mp3,8.mp3文件的内容.在1.mp3与6.mp3之间会有延时停顿.

那些1.MP3,6.MP3,8.MP3是怎么生成的？
不可以是168.MP3吗？

楼上说的虽然在存储时不是这样，但可以作参考哟，看看CPU的流水线作业方法，是不是可以先将1.mp3、6.mp3、8.mp3三个文件处理成一个文件再播放？

汗~

最让你基于一个个文件去播放的？

汗~

最让你基于一个个文件去播放的？
xwj 发表于 2009-10-17 14:40

老X还有什么办**我这个不是用在交换机上.是用在其它地方的.

3# awmc_m
一次读出不太现实,除了数字还是26个英文字母,还有其它一些语音,只能根据要求拼起来放音.

什么核？RAM多大？条件满足的话我送你MEGA上的ADPCM，比MP3要快得多，绝对感觉不到停顿。

不过就拼凑语音来说，要做到自然不仅仅是不停顿就可以的，单纯数字好办些，文字的播报要感觉稍微自然，都有些难度。

mp3格式不了解，不过似乎有索引，可以拖放啊

双缓冲

外挂个RAM，全部调入，剩下就是指针寻址，还有就是你的 MP3码率可以很低，频带上限到600Hz-2K就可以了，估计你没重新编码

各位，楼主的方案是已经确定了的，就是“以VS1003B和山景SOC芯片为背景，倾心研制数字化语音录放产品”，当然有其它方案可以轻松解决，但基于楼主的前提，很多招是用不了的，只能基于现有系统优化，除非走投无路。

学习了

呵呵,是chunyang那情况,其它平台软硬件重整,不现实了,只能在现在基础上努力努力.谢谢大家出主意.

您的问题来自两方面:
1.各数字的码流之间的接续时间问题, 采用一些预处理方法应该可以基本解决;
2.各数字发音间的上下文关系, 这个一般人是不注意的(例:"555"的发音中, 3个"5"的声调都是不一样的,如果硬要用一个音去拼接, 那及其不自然, 即使问题1解决了,同样会显得结巴);

恩。
真的很受用