alsa中的dma传输问题

testh

在snd_pcm_lib_write1()中调用了wait_for_avail()，在里面调用了schedule_timeout()然后返回后即开始判断runtime->status->state,想知道，到底是谁在schedule_timeout()期间改变了这个值呀

testh

回复 2# stephen_du


    我是想知道在alsa中，playback是怎么传输数据到外部codec的，现在了解到用了一个内部的缓冲区，但是如何用这个缓冲区还不太清楚，可否指点一下

testh

它的调用流程大概了解，目前在看snd_pcm_lib_write1()的实现代码，在这段代码中实际并没有移动或者copy数据的操作，但是却有不断的查询当前的runtime->status->state的判断，从而不解的是：实际作搬运的代码到底在哪里?他们之间又是如何联系的?


目前我在sound/soc/jz4740/jz4740-pcm.c中了解到，在jz4740_pcm_hw_params()中设置好dma的中断回调函数，并在回调函数中继续启动下一次dma传输，直到传输完毕，同时，在每次进入dma的回调中都会调用snd_pcm_period_elapsed()，到这里，我根据代码的推断是：在用户编写的driver中，即jz4740-pcm.c中会维护一个有关dma起始地址，当前地址，dma缓冲区大小的数据结构，同时，也把这些数据cpy到runtime中的dma结构中，使用的接口是 snd_pcm_set_runtime_buffer(),这样，在alsa－core中和driver中就有一个一份相同的dma地址信息，当每次调用dma的回调函数时再调用snd_pcm_period_elapsed()到时候，就会更新alsa－core中的dma信息。这样就把dma的传输操作和alsa－core中的地址信息给联系起来了。原来不能光看alsa-core的部分，还需要用户的driver协助，其实也对，毕竟alsa-core是一个抽象，他不能将所有soc的dma硬件操作包含进去，也没有那个必要，千奇百怪的也写不过来，就只好放在每个具体的soc的driver里实现了。

不知道我分析的是否正确?

testh

http://www.alsa-project.org/~tiw ... driver/ch05s07.html
以前也看过这段文章，但是当时看完后没能领悟，现在理解了。看来非得带着问题，并且被问题逼得找不着道路时看文章才能有收获。饭到嘴边的时候不知道吃，没饭的时候才有吃的欲望。怎一个贱字了得。

testh

回复 4# stephen_du


    我刚下载看了你写的《LinuxKernelDesignAnalysisAndExperiments.pdf》，很不错，向你学习，希望以后有机会共同探讨，感谢兄弟回复

heyustudent

你好，请问这个问题你最后怎么解决，我也出现这个问题，一直没办法解，不知道为啥schedule_timeout()了

kangear

也在带着问题看alsa，有点意思。