On Tue, 16 May 2017 08:54:17 +0200, Takashi Sakamoto wrote: > > 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. It's about the less-optimized code path with snd_pcm_mmap_read/write. For the code path calling snd_pcm_mmap_begin() / snd_pcm_mmap_commit(), there is no hwsync ioctl call. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
