[alsa-devel] snd_pcm_htimestamp & more PCM mmap timestamping in driver
Hi all,
I just added snd_pcm_htimestamp() function to alsa-lib:
int snd_pcm_htimestamp(snd_pcm_t *pcm, snd_pcm_uframes_t *avail, snd_htimestamp_t *tstamp);
If you have any complaints, please, do now.
Also, I would like to change SNDRV_PCM_TSTAMP_MMAP semantics to SNDRV_PCM_TSTAMP_ENABLE - when hw_ptr is updated in the driver, a timestamp would be always grabbed to ensure that we have always a valid timestamp & position pair. In current implementation, if an application updates hw_ptr in driver (using for example PCM delay ioctl), timestamp grabbed in the interrupt handler won't be associated with any real ring buffer position which makes things complicated and not too much abstract. Opinions?
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Wed, 9 Jan 2008 14:17:28 +0100 (CET), Jaroslav Kysela wrote:
Hi all,
I just added snd_pcm_htimestamp() function to alsa-lib:
int snd_pcm_htimestamp(snd_pcm_t *pcm, snd_pcm_uframes_t *avail, snd_htimestamp_t *tstamp);
Thanks, looks good. I suppose the unimplemented stuff shall be implemented soon in near future?
If you have any complaints, please, do now.
Also, I would like to change SNDRV_PCM_TSTAMP_MMAP semantics to SNDRV_PCM_TSTAMP_ENABLE - when hw_ptr is updated in the driver, a timestamp would be always grabbed to ensure that we have always a valid timestamp & position pair. In current implementation, if an application updates hw_ptr in driver (using for example PCM delay ioctl), timestamp grabbed in the interrupt handler won't be associated with any real ring buffer position which makes things complicated and not too much abstract. Opinions?
Sounds reasonable to me.
Takashi
participants (2)
-
Jaroslav Kysela
-
Takashi Iwai