ALSA录音数据会丢呢？

[coding码场]

用的wm8993+at6700平台，选用ALSA，在用ALSA 测试工具测试的时候发现有丢录音数据的情况：
1、只用arecord去录音，比如录10分钟，得到的audio数据确实是十分钟，也是在比较准确的十分钟完成，可以对比电脑的系统时间。这种情况下，不管sample rate是8000或者44.1k，都不出现丢数据的问题，也就是说跟理论数据一样。arecord是先计算好像录的时间长度的数据大小，完成这么多量就退出。

2、先在后台用aplay一个44.1k的wav文件，这个文件能播10分钟以上，再启动arecord，同时制定arecord的sample rate为8k，双声道，16bit format。通过在启动arecord命令前后执行一个取系统时间的“date”命令对比，发现这个时候制定录10分钟的音频数据，实际上要多花3秒钟左右，也就是说跟理论上10分钟是有误差的。这过录音过程中没有出现alsa读写错误，很奇怪。不知道有没有大侠，遇到过类似的问题？

在android 2.2平台上，用alsa处理时，在read的时候，加入读写数据量的打印信息，明显发现存在丢录音数据的情况。为什么在playback的substream存在的情况下，且其sample rate为44.1k，record的sample rate为8k的时候，会处在录音数据丢失呢？

[challenge99]

不排除是你方法的问题呢？

文件录了多长时间，我个人认为应该这样计算

file_size/sample_size/channel_cnt/sample_rate = play_time

[coding码场]

[Quote=引用 1 楼 challenge99 的回复:]
不排除是你方法的问题呢？

文件录了多长时间，我个人认为应该这样计算

file_size/sample_size/channel_cnt/sample_rate = play_time
[/Quote]这个问题的核心之处不在测试方法上。你认为的计算方法只不过是个理论的计算法则。我在上面的帖子上已经说过【arecord是先计算好像录的时间长度的数据大小，完成这么多量就退出。】，因此只用理论这一套看文件大小，来计算时间是个错误的。比如你录10分钟，arecord先计算好录的总数据量，如果是8k，双声道，16bit的format，总量就是8000X2X2X10X60,但是完成这个总量需要的实际时间是超过10分钟零3秒样子。因此在实际的10分钟里，得到的数据跟理论数据是有一些差异，就是存在丢数据的问题。

[challenge99]

也许是的，你的播放和采集的采样率不同，你试试使用相同的采样率呢？

会不会声卡只有一个时钟， 采集实际使用的是播放的时钟，然后做的resample呢？ 当然这只是猜测

[challenge99]

明白你的意思了

有种可能是处理速度慢了，采集的缓冲区满了，丢掉了一部分数据
--------------------------------------------------------------------------------
xrun
Once the audio interface starts running, it continues to do until told to stop. It will be generating data for computer to use and/or sending data from the computer to the outside world. For various reasons, your program may not keep up with it. For playback, this can lead to a situation where the interface needs new data from the computer, but it isn't there, forcing it use old data left in the hardware buffer. This is called an "underrun". For capture, the interface may have data to deliver to the computer, but nowhere to store it, so it has to overwrite part of the hardware buffer that contains data the computer has not received. This is called an "overrun". For simplicity, we use the generic term "xrun" to refer to either of these conditions

[coding码场]

关键是ALSA没有-EPIPE的错误上来，其他的错误也没有！也许跟clock有一定关系。

[coding码场]

在android中，播放跟采样率是不一样的，codec只有一个数字接口，只能有一种sample rate。最近继续跟进，发现可能给DMA有关系，DMA的中断次数比理论值就少一些，待进一步证实。