Coherence of status structure after SYNC_PTR

Coherence of status structure after SYNC_PTR

[Ricardo Biehl Pasquali]

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

Re: Coherence of status structure after SYNC_PTR

[Takashi Sakamoto]

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

Re: Coherence of status structure after SYNC_PTR

[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

Re: Coherence of status structure after SYNC_PTR

[Ricardo Biehl Pasquali]

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