[alsa-devel] alsa timestamps

[Takashi Iwai]

At Tue, 20 Nov 2007 18:07:25 +0200,
Heikki Lindholm wrote:
> 
> Takashi Iwai kirjoitti:
> > At Tue, 20 Nov 2007 16:54:32 +0200,
> > Heikki Lindholm wrote:
> >> Takashi Iwai kirjoitti:
> >>> At Mon, 19 Nov 2007 15:41:46 +0200,
> >>> Heikki Lindholm wrote:
> >>>> Jaroslav Kysela kirjoitti:
> >>>>> On Mon, 19 Nov 2007, Heikki Lindholm wrote:
> >>>>>
> >>>>>> Heikki Lindholm kirjoitti:
> >>>>>>> Hello list,
> >>>>>>>
> >>>>>>> I took up some old dusty code of mine that uses snd_pcm_state followed 
> >>>>>>> by snd_pcm_status_get_tstamp when in capture mode. The code used to 
> >>>>>>> work, but now the returned timestamps are all zeroes. Is there some API 
> >>>>>>> change done recently or is the whole timestamping deprecated or 
> >>>>>>> something? I've tried with different drivers on ubuntu's alsa .14 and 
> >>>>>>> gentoo's .14. I've also tried mmap'ed and r/w modes, and I'm setting the 
> >>>>>>> TSTAMP_MMAP sw param.
> >>>>>> I figured out that this doesn't happen when using hw:x,y devices. Is it 
> >>>>>> a documented feature that some (software?) devices don't fill in timestamps?
> >>>>> I think that it should be fixed. Could you send us 'snd_pcm_dump()' for a 
> >>>>> non-working device? It's probably ommited code in direct pcm plugins (dmix 
> >>>>> & etc.).
> >>>> Here goes. The driver is snd_aoa. It seems as if the timestamp mode 
> >>>> isn't propagated to the hw device.
> >>> AFAIK, the time-stamp mode isn't handled properly with direct plugins
> >>> because of its nature.  Since the direct plugins share the same PCM
> >>> hardware instance with multiple processes, you cannot change the
> >>> parameter arbitrarily from a single client.
> >>>
> >>> We may implement an emulation in alsa-lib instead, though...
> >> For the time being, is there any other way of determining whether a pcm 
> >> supports time stamps than just trying out and seeing if zero is all that 
> >> comes out?
> > 
> > Hmm, at the second look at the dmix/dsnoop code, it has some lines
> > that actually update the timestamp value (as emulation).  So,
> > basically it should work.  Maybe some other parts are broken...
> > Do you have a small test case code just for checking?
> 
> Attached a test case that I just wrote. Seems I need it anyway since 
> drivers are acting bogus, too. On a Power Mac G5, using snd_aoa, running 
> the program with
> ./alsatest hw:0,0 1024
> produces good timestamps whereas running with
> ./alsatest default 1024
> produces zeros (the second param is period size).
> I also observed the same behaviour on a bog standard x86, with SB Live, 
> I think..

Thanks.  Actually it's a bug in alsa-lib.  The patch below should fix
the problem.  I'll push it to the HG tree.


Takashi

diff -r 39d34d6a4587 src/pcm/pcm_direct.c
--- a/src/pcm/pcm_direct.c	Tue Nov 20 15:29:10 2007 +0100
+++ b/src/pcm/pcm_direct.c	Wed Nov 21 12:06:52 2007 +0100
@@ -1001,6 +1001,17 @@ int snd_pcm_direct_initialize_slave(snd_
 		return ret;
 	}
 
+	/* set timestamp mode to MMAP
+	 * the slave timestamp is copied appropriately in dsnoop/dmix/dshare
+	 * based on the tstamp_mode of each client
+	 */
+	ret = snd_pcm_sw_params_set_tstamp_mode(spcm, sw_params,
+						SND_PCM_TSTAMP_MMAP);
+	if (ret < 0) {
+		SNDERR("unable to tstamp mode MMAP");
+		return ret;
+	}
+
 	if (dmix->type != SND_PCM_TYPE_DMIX)
 		goto __skip_silencing;
 
diff -r 39d34d6a4587 src/pcm/pcm_dmix.c
--- a/src/pcm/pcm_dmix.c	Tue Nov 20 15:29:10 2007 +0100
+++ b/src/pcm/pcm_dmix.c	Wed Nov 21 12:06:52 2007 +0100
@@ -420,7 +420,14 @@ static int snd_pcm_dmix_status(snd_pcm_t
 	memset(status, 0, sizeof(*status));
 	status->state = snd_pcm_dmix_state(pcm);
 	status->trigger_tstamp = dmix->trigger_tstamp;
-	status->tstamp = snd_pcm_hw_fast_tstamp(dmix->spcm);
+	if (pcm->tstamp_mode == SND_PCM_TSTAMP_MMAP)
+		status->tstamp = snd_pcm_hw_fast_tstamp(dmix->spcm);
+	else {
+		struct timeval tv;
+		gettimeofday(&tv, 0);
+		status->tstamp.tv_sec = tv.tv_sec;
+		status->tstamp.tv_nsec = tv.tv_usec * 1000L;
+	}
 	status->avail = snd_pcm_mmap_playback_avail(pcm);
 	status->avail_max = status->avail > dmix->avail_max ? status->avail : dmix->avail_max;
 	dmix->avail_max = 0;
diff -r 39d34d6a4587 src/pcm/pcm_dshare.c
--- a/src/pcm/pcm_dshare.c	Tue Nov 20 15:29:10 2007 +0100
+++ b/src/pcm/pcm_dshare.c	Wed Nov 21 12:06:52 2007 +0100
@@ -229,7 +229,14 @@ static int snd_pcm_dshare_status(snd_pcm
 	memset(status, 0, sizeof(*status));
 	status->state = snd_pcm_state(dshare->spcm);
 	status->trigger_tstamp = dshare->trigger_tstamp;
-	status->tstamp = snd_pcm_hw_fast_tstamp(dshare->spcm);
+	if (pcm->tstamp_mode == SND_PCM_TSTAMP_MMAP)
+		status->tstamp = snd_pcm_hw_fast_tstamp(dshare->spcm);
+	else {
+		struct timeval tv;
+		gettimeofday(&tv, 0);
+		status->tstamp.tv_sec = tv.tv_sec;
+		status->tstamp.tv_nsec = tv.tv_usec * 1000L;
+	}
 	status->avail = snd_pcm_mmap_playback_avail(pcm);
 	status->avail_max = status->avail > dshare->avail_max ? status->avail : dshare->avail_max;
 	dshare->avail_max = 0;
diff -r 39d34d6a4587 src/pcm/pcm_dsnoop.c
--- a/src/pcm/pcm_dsnoop.c	Tue Nov 20 15:29:10 2007 +0100
+++ b/src/pcm/pcm_dsnoop.c	Wed Nov 21 12:06:52 2007 +0100
@@ -175,7 +175,14 @@ static int snd_pcm_dsnoop_status(snd_pcm
 	state = snd_pcm_state(dsnoop->spcm);
 	status->state = state == SND_PCM_STATE_RUNNING ? dsnoop->state : state;
 	status->trigger_tstamp = dsnoop->trigger_tstamp;
-	status->tstamp = snd_pcm_hw_fast_tstamp(dsnoop->spcm);
+	if (pcm->tstamp_mode == SND_PCM_TSTAMP_MMAP)
+		status->tstamp = snd_pcm_hw_fast_tstamp(dsnoop->spcm);
+	else {
+		struct timeval tv;
+		gettimeofday(&tv, 0);
+		status->tstamp.tv_sec = tv.tv_sec;
+		status->tstamp.tv_nsec = tv.tv_usec * 1000L;
+	}
 	status->avail = snd_pcm_mmap_capture_avail(pcm);
 	status->avail_max = status->avail > dsnoop->avail_max ? status->avail : dsnoop->avail_max;
 	dsnoop->avail_max = 0;