[alsa-devel] Coherence of status structure after SYNC_PTR
In alsa-lib, pcm_hw, htimestamp(), avail is rechecked to ensure a valid timestamp.
I guess this is for the case when status is mmaped, when hardware pointer is read, an interrupt occur, and timestamp is read.
Does SYNC_PTR ioctl always fill a coherent status?
Cheers!
pasquali
On Thu, Dec 27, 2018 at 03:22:24PM -0200, Ricardo Biehl Pasquali wrote:
In alsa-lib, pcm_hw, htimestamp(), avail is rechecked to ensure a valid timestamp.
I guess this is for the case when status is mmaped, when hardware pointer is read, an interrupt occur, and timestamp is read.
Does SYNC_PTR ioctl always fill a coherent status?
Exactly.
The ioctl command was firstly introduced to solve an issue in cache-incoherent architectures such as arm or a part of atom platform in Intel architecture.
In cache-coherent architectures, kernel memory can be mapped to process VMA to share status and control data of runtime of PCM substream ('struct snd_pcm_runtime.status' = 'struct snd_pcm_mmap_status' and 'struct snd_pcm_runtime.control' = 'struct snd_pcm_mmap_control'). For example, state of runtime of PCM substream is in the 'status' data. Members of these two can be changed by both of kernel/userspace, thus need to care of cache-coherency.
In cache-incoherent architectures, the mapped memory is not necessarily cache-coherent, thus a call of the ioctl command delivers changed data in temporary buffer to copy from process VMA to kernel memory or vise versa.
Of cource, the ioctl command works expectedly in cache-coherent architecture as well.
I note that there're some levels of timestamp and autio timestamp. Additionally, audio timestamp is updated only in any hardware/software IRQs, thus it's not available with 'no-period-wakeup' runtime, FYI.
Regards
Takashi Sakamoto
On Fri, Dec 28, 2018 at 12:45:49PM +0900, Takashi Sakamoto wrote:
I note that there're some levels of timestamp and autio timestamp. Additionally, audio timestamp is updated only in any hardware/software IRQs, thus it's not available with 'no-period-wakeup' runtime, FYI.
Oops. No, the audio timestamp can be updated in updating process of hardware pointer. A call of ioctl with SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT can return updated audio timestamp.
Regards
Takashi Sakamoto
On Fri, Dec 28, 2018 at 01:21:24PM +0900, Takashi Sakamoto wrote:
On Fri, Dec 28, 2018 at 12:45:49PM +0900, Takashi Sakamoto wrote:
I note that there're some levels of timestamp and autio timestamp. Additionally, audio timestamp is updated only in any hardware/software IRQs, thus it's not available with 'no-period-wakeup' runtime, FYI.
Oops. No, the audio timestamp can be updated in updating process of hardware pointer. A call of ioctl with SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT can return updated audio timestamp.
Thank you for the explanation!
Regarding the alsa-lib, pcm_hw, htimestamp():
Although not needed, adding a 'break' in the loop when 'mmap_status_fallbacked' is true would avoid another ioctl.
Cheers!
pasquali
participants (2)
-
Ricardo Biehl Pasquali
-
Takashi Sakamoto