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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
