[alsa-devel] Application hangs with different period sizes

[Takashi Iwai]

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