tiny6410作sip电话终端时，同时录放的导致9714死掉

采用alsa的库进行录放，无论怎么选择录音和放音的模式，什么阻塞的，异步的，mmap的等等，都是会死掉。然后snd_pcm_wait总是超时，再也无法工作。哪位高手有什么解决办法？是硬件问题？驱动问题？

请详细描述“死掉”的具体状态，你具体又是怎么操作的

$arecord | aplay

然后就随机的没有声音了。只有重新启动板子。

后来又测试了一个终端开着alsa lib下的测试程序pcm.c 选择程序提供的各种播放模式，同时开着一个声音采集进程。同样的情况，过一会就声音也采不上来，播放的声音也写不进去。

你提供的这些信息仍然不足以定位问题

建议：
1) arecord 或 aplay 可以加上 -v 看看调试信息
2) 参数如period size, buffer size, 这些影响很大，需要多注意
3) 试试 8K 16bit 2声道 采样
4) arecord 和 aplay 运行的过程中，你可以去 proc/asound下去看看状态

我尝试了几个格式，其中-f cd 时，声卡在1个小时后死掉了。debug的信息大致如下：

arecord: pcm_read:1692: read error: Input/output error
aplay: pcm_write:1603: write error: Input/output error

911gt3，请进一步指教一下:如何选择period和buffer的大小？我也倾向于认为是什么参数导致的，但是找不到什么有效的选择参数的原则。而且手里的两块tiny6410板子出现问题的频次大不一样。死掉的时间随机出现。

-f cd 的话数据量很大，对于 sip 来说是没必要的

至于period，越小延时(jitter)越小，但是实时性要求也高，你可能得自己多试试

呵呵，我是说，怎么才能减少死掉，而不是传输质量

我目前还没办法知道是什么原因导致这个问题的，我也没有遇到过
所以，只能你自己多试试，比如说你采用8k看看是不是就没那么容易“死”了

至于我为何要提到实时性，是因为我不清楚你测试时板上是不是已经运行了很多其它的应用，CPU占用率是不是已经很高，这些是有可能带来干扰的
简单一点说，要定位问题，你应该先将环境中可能有干扰的因素去除掉

8k稍微好点。这么说吧，我买了两块板，都会死，只是死得频次有差别。

我没做任何的东西，只是友善的系统，还关掉了Qtopia、http server

然后就是用板子上友善编译的alsa的utils：arecord | aplay，这样的命令，就是采用默认的8k、8bit LE、单声道，然后最好的一块板在工作了1个小时左右就停止录放了。准确的说是，此时，录音buffer中没有数据，而放音那里buffer 上溢，并且重新启动进程也声卡也无法正常工作了。

兄弟，请回去帮忙做个试验，看看你那里有没有这个现象。没天理啊，我什么都没动，怎么两块板没有一块能长时间正常工作呢？