-----Original Message----- From: Jaroslav Kysela [mailto:perex@perex.cz] Sent: Thursday, July 02, 2009 1:39 PM To: Harsha, Priya Cc: alsa-devel@alsa-project.org; tiwai@suse.de Subject: Re: [alsa-devel] Help required with debugging
On Thu, 2 Jul 2009, Harsha, Priya wrote:
Why is runtime->hw_ptr_jiffies updated in hw_ptr()? This should be only updated in the interrupt context right?
The idea of hw_ptr_jiffies is to have a check if real-time clock in sync with the DMA buffer position. If your hardware does block transfers and is not able to return fine position in period set SNDRV_PCM_INFO_BATCH flag.
Thanks a lot. Setting the runtime->hw.info = SNDRV_PCM_INFO_BATCH in the ops->prepare(), helps getting past the issue. Its true that the hardware is doing a batch transfer of period_size into the dma_buffer of ALSA.
But it's rather a workaround than a proper fix, because timestamps are updated but the ring buffer position is not moved (which brokes the idea to have a relation between the ring buffer position and the real-time clock).
Actually the firmware does not update the timestamp till the period size is reached, i.e., the firmware increments the timestamp with period_size and transfers the same to the dma_buffer.
I think that this sort of drivers might require to implement the SNDRV_PCM_POS_KEEP return value in case when position does not change from last read to notify midlevel PCM code that they're not able to handle fine pointer resolution.
I don't find this return value in the ALSA code, can you help me with more details of what needs to be returned and where.
Also, hardware with large FIFOs should update properly runtime->delay value now.
I am not finding a field called delay in runtime structure. Where can I find it...and is there a documentation/comment on what this value needs to hold?
Jaroslav
Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.