用的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的时候，会处在录音数据丢失呢？

明白你的意思了

有种可能是处理速度慢了，采集的缓冲区满了，丢掉了一部分数据
--------------------------------------------------------------------------------
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