At Thu, 7 Aug 2008 15:48:49 +0530, anuj aggarwal wrote:
Hi,
Regarding the below mentioned problem, we added some debugging in ALSA layer and our audio codec driver to understand the problem. And I think, we understand the root cause of the issue. Whenever we call *snd_pcm_writei* function from application, it executes kernel function *snd_pcm_lib_write1* from sound/core/pcm_lib.c. This function copies the user buffer and updates some alsa variables and trigger the DMA ( if alsa is in PREPARED state). And same thing is done in snd_pcm_readi() function call.
In case of DMA transfer, the DMA callback will update the hw_ptr depending on the number of bytes xfered. So now two functions are updating the hw_ptr (DMA callback and write/read function) and this is the problem. Only DMA callback should update the hw_ptr because DMA is the one who is doing the real transfer, not the write/read function. Read and write function should only update the appl_ptr and leave the hw_ptr for DMA callback.
After applying the below patch, my application works fine. Can someone look into the patch provided below and confirm our understanding?
The hw_ptr can be updated at any time. It can be updated at hwsync or other calls, too. And, the update is protected via a substream lock, it's no racy.
I guess your problem is the implementation of pointer callback. The update of hw_ptr purely depends on the value returned from the pointer callback. Or, the driver assumes wrongly about the handling of hw_ptr...
Takashi