[alsa-devel] Help required with debugging
Hi,
I see the following behavior and have a couple of questions that would help me debug my new driver/hardware.
snd_pcm_lib_read1() - > snd_pcm_update_hw_ptr() ->ops->ack() This enables the driver to send data to hardware for capture snd_pcm_period_elapsed() -> hw_ptr_interrupt This updates the runtime->hw_ptr_jiffies. The jdelta calculated is proper and I find no issues with this. snd_pcm_lib_read1() is returned back
Alsa calls driver's ack inbetween here snd_pcm_period_elapsed() -> snd_pcm_update_ hw_ptr_interrupt This updates the runtime->hw_ptr_jiffies. The jdelta calculated is proper and I find no issues with this.
snd_pcm_lib_read1() - > snd_pcm_update_ hw_ptr() Here the runtime->hw_ptr_jiffies is updated and this causes my next jdelta to be very less in snd_pcm_period_elapsed() -> snd_pcm_update_hw_ptr_interrupt.
Why is runtime->hw_ptr_jiffies updated in hw_ptr()? This should be only updated in the interrupt context right? Without this statement, my driver/hardware works fine. Or is there any constraint I can set somehow such that the hw_ptr_jiffies is only updated in the hw_ptr_interrupt function?
Thanks, Harsha
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. 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).
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.
Also, hardware with large FIFOs should update properly runtime->delay value now.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
-----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.
participants (2)
-
Harsha, Priya -
Jaroslav Kysela