[alsa-devel] Driver - PCM MMAP mode timestamps
perex at perex.cz
Tue Jan 8 12:24:31 CET 2008
On Tue, 8 Jan 2008, Takashi Iwai wrote:
> At Tue, 8 Jan 2008 10:45:34 +0100 (CET),
> Jaroslav Kysela wrote:
> > Hi,
> > it seems that we have another inconsistency with PCM MMAP mode
> > timestamps. If I read code correctly, snd_pcm_status() returns timestamp
> > from last interrupt BUT updates hw_ptr to current (calling
> > snd_pcm_update_hw_ptr() again).
> > It means, that application will get unrelated timestamp to
> > hw position returned in snd_pcm_status() in case of mmap mode. I don't see
> > any way to use this timestamp now.
> > To fix this issue, I would like to create a next status ioctl
> > which will return only mmap timestamp plus last related interrupt ring
> > buffer position and remove 'if (runtime->tstamp_mode ==
> > SNDRV_PCM_TSTAMP_MMAP)' condition from snd_pcm_status() in driver
> > completely.
> > Any opinion? Other idea?
> It'd be OK to remove the tstamp_mode check there. It was newly added
> after discussions. We are still in the development phase about this,
> and removing is no regression.
> However, I'm against adding new ioctls. The same thing can be simply
> done by reading the mmapped status struct, as snd_pcm_hw_fast_tstamp()
> in alsa-lib pcm_hw.c. If the mmaped status isn't available, it can
> fallback to the normal snd_pcm_status().
You're right. I forgot on mmaped status and PCM_IOCTL_SYNC_PTR for
> The real problem is that the behavior of TSTAMP_MMAP isn't strictly
> defined. It's just a TSTAMP_NORMAL in the end unless the new if check
> there. I think we may get rid of this mode if the tstamp via mmap is
Actually, after condition removal, TSTAMP_MMAP will just enable
timestamping in interrupt update. No other tests are in the driver.
I commited change to HG.
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
More information about the Alsa-devel