On May 16 2017 15:34, Takashi Iwai wrote:
IIRC, the problem isn't about the forward / rewind but about the
normal data transfer. In mmap mode, we transfer data on the mmap
buffer, and update appl_ptr via mmap control. Both are done without
notification to the driver (which is intentional for avoiding the
context switching).
So we want to disable this optimization and always notify to the
driver. Disabling mmap status/control is the straight hack as it
falls back to ioctl and then the driver can know the change.
There's SNDRV_PCM_IOCTL_HW_SYNC command. In kernel land
implementation, this command is handled with a call of 'struct
snd_pcm_ops.pointer'.
In alsa-lib, this command is often executed in most cases to handle
PCM frames.
The HWSYNC or SYNC_PTR ioctls are used only as the fallback when mmap
failed. It's the exact goal of this patch :)
Although SYNC_PTR is in the fallback mechanism of alsa-lib, HWSYNC is
not in.
(alsa-lib)
ioctl(SNDRV_PCM_IOCTL_HWSYNC)
<-snd_pcm_hw_hw_sync()
= struct snd_pcm_fast_ops.hwsync
<-__snd_pcm_hw_hwsync()
<-snd_pcm_hwsync()
<-snd_pcm_avail()
<-snd_pcm_read_areas()
<-snd_pcm_mmap_readi()
<-snd_pcm_mmap_readn()
<-snd_pcm_avail_delay()
<-snd_pcm_write_areas()
<-snd_pcm_mmap_writei()
<-snd_pcm_mmap_writen()
For a case that applications execute ioctl(2) with
SNDRV_PCM_IOCTL_READN/READI/WRITEN/WRITEI, in kernel land
snd_pcm_lib_read1()/snd_pcm_lib_write1() should have calls of 'struct
snd_pcm_ops.pointer', I think.
Regards
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
