[alsa-devel] Help required with debugging
priya.harsha at intel.com
Sat Jul 4 15:52:21 CEST 2009
>From: Jaroslav Kysela [mailto:perex at perex.cz]
>Sent: Thursday, July 02, 2009 1:39 PM
>To: Harsha, Priya
>Cc: alsa-devel at alsa-project.org; tiwai at 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
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
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
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 Kysela <perex at perex.cz>
>Linux Kernel Sound Maintainer
>ALSA Project, Red Hat, Inc.
More information about the Alsa-devel