确切的说是CM7, Desire HD (ACE)的CM7版本, 其他的版本由于没测过, 不确定是否存在. Blow!Blow!这个小程序有一天更新后, 在market中收到好几个一个星, 并且用户评论说, 出现”设备使用中”的错误提示, 随后的几天, 甚至有用户反映无法卸载. 这使我极为苦恼. 因为我知道是AudioRecord出问题了, 但不知道为什么会出问题, 程序中AudioRecord的用法非常规范, 除非input device真的被别的程序占用(比如录音机), 否则是不可能有这样的错误发生的. 这时, 我偶尔在我的Desire HD(刷了CM7)上发现启动Blow!Blow!后第一次打开AudioRecord会出现

cannot open codec aic3254 device -1

set_sound_effect failed

的错误日志, 但调用都是成功的. 随后, AudioRecord read到的数据不正常, 几乎都是1, 2,3, 也就是说采集到的声音几乎是静音. 关闭AudioRecord, 再次打开, 又正常了. 这个问题非常诡异, 直到现在还没搞明白为什么, 只知道当AudioRecord和AudioTrack分别在两个线程中同时使用, 就会偶尔出问题. 这个先放一边, 毕竟不是致命的.

接着发现的问题, 就让人无法容忍了. 先说说AudioRecord的几个基本操作吧

1. getMinBufferSize, 获取最小缓冲区大小, 然后按需求适当增大这个size , 可以防止卡顿现象, 我一般乘上5倍. 不要担心, 这不会增大时延(基于android内部record缓冲区每块的大小是固定的猜测)

2. new出一个AudioRecord

3.startRecording

4.循环read

5.stop

6.release, 这一步很关键, 如果不调用, 并且AudioRecord对象仍然可以reach的话, 设备还是被占用这的. 可以把这个方法理解为close.

这几个步骤再简单不过了.

如果已经有程序在使用record设备, 比如录音机, 那么当我们在startRecording的时候, 就会失败抛出异常, 这是正常行为. 而cm7中, 将会导致原来正在运行的录音程序中的录音线程阻塞, 并且record设备资源被永久占用, 直到重启. 这个问题始终没有解决, 好在出现的几率比较少, 毕竟用到录音功能的常用app不多.