[alsa-devel] Application hangs with different period sizes
tiwai at suse.de
Fri Aug 8 08:18:24 CEST 2008
At Thu, 7 Aug 2008 15:48:49 +0530,
anuj aggarwal wrote:
> 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
More information about the Alsa-devel