使用的是alsa-lib-1.0.25,分别编译了x86和arm版本的libasound.so，且在x86上任何运行都正确。
通过分析alsa-lib的源码发现，在snd_pcm_open()内部通过层层调用，在src/dlmisc.c中的
snd_dlsym_verify()中有一组dlopen()-->dlsym()的调用，很明显，他们是获取libasound.so本身中可
导出的接口的，通过调试发现，使用strace pcm_min
发现段错误就发生在调用dlsym()这个接口里，没有办法再继续跟踪了，dlopen返回的handle非NULL，dlsym()的符号地址为
_snd_pcm_hw_open_dlsym_pcm_001，使用nm -D
libasound.so发现里面是存在这个符号的，况且，在x86上的ubuntu上运行也是没有问题的，不会发生段错误，而且，我又另外写了一个测试
程序，在里面dlopen()动态库libasound.so然后dlsym()这个_snd_pcm_hw_open_dlsym_pcm_001()
也是没有问题的，但是在libasound.so中调用dlsym()来获取_snd_pcm_hw_open_dlsym_pcm_001()就失败，
我又在修改了dlopen()和dlsym()使他们访问libm.so中的cos()接口，这样就没有问题，甚至想到是不是so库本身不能调用本身的
_snd_pcm_hw_open_dlsym_pcm_001?于是又写了一个简单的so库，然后在库中使用dlopen,dlsym来访问库中的另一
个接口，在arm上运行也是没有问题的，至此，没有了思绪，是libasound.so的问题?该从哪里入手?哪位能否给个建议吗?谢了
---------->
找到问题了，是版本的问题。
板子上的alsa-driver是1.0.24的，我上午用的alsa-lib是1.0.25的，换成1.0.24的alsa-lib之后顺利的度过了那里。
之所以会这样是因为：我查看了ubuntu的alsa-driver是1.0.23的，用1.0.25的也可以在上面正常运行，然后我就觉得用
1.0.25的alsa-lib在1.0.24的alsa-driver上应该也没有问题，可它就是出了问题，浪费了很多时间。。。
教训：
调试时要先确定版本，不要和版本号对着干。