alsa timestamps

alsa timestamps

[Heikki Lindholm]

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.

-- Heikki Lindholm

Re: alsa timestamps

[Heikki Lindholm]

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?

-- Heikki Lindholm

Re: alsa timestamps

[Jaroslav Kysela]

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.).

						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project

Re: alsa timestamps

[Heikki Lindholm]

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.

Plug PCM: Rate conversion PCM (48000, sformat=S16_BE)
Its setup is:
   stream       : CAPTURE
   access       : RW_INTERLEAVED
   format       : S16_BE
   subformat    : STD
   channels     : 2
   rate         : 44100
   exact rate   : 44100 (44100/1)
   msbits       : 16
   buffer_size  : 15052
   period_size  : 940
   period_time  : 21333
   tick_time    : 0
   tstamp_mode  : MMAP
   period_step  : 1
   sleep_min    : 0
   avail_min    : 940
   xfer_align   : 940
   start_threshold  : 1
   stop_threshold   : 15052
   silence_threshold: 0
   silence_size : 0
   boundary     : 4236761349448794112
Slave: Direct Snoop PCM
Its setup is:
   stream       : CAPTURE
   access       : MMAP_INTERLEAVED
   format       : S16_BE
   subformat    : STD
   channels     : 2
   rate         : 48000
   exact rate   : 48000 (48000/1)
   msbits       : 16
   buffer_size  : 16384
   period_size  : 1024
   period_time  : 21333
   tick_time    : 0
   tstamp_mode  : MMAP
   period_step  : 1
   sleep_min    : 0
   avail_min    : 1024
   xfer_align   : 1024
   start_threshold  : 1
   stop_threshold   : 16384
   silence_threshold: 0
   silence_size : 0
   boundary     : 4611686018427387904
Hardware PCM card 0 'SoundByLayout' device 0 subdevice 0
Its setup is:
   stream       : CAPTURE
   access       : MMAP_INTERLEAVED
   format       : S16_BE
   subformat    : STD
   channels     : 2
   rate         : 48000
   exact rate   : 48000 (48000/1)
   msbits       : 16
   buffer_size  : 16384
   period_size  : 1024
   period_time  : 21333
   tick_time    : 1000
   tstamp_mode  : NONE
   period_step  : 1
   sleep_min    : 0
   avail_min    : 1024
   xfer_align   : 1024
   start_threshold  : 1
   stop_threshold   : 4611686018427387904
   silence_threshold: 0
   silence_size : 0
   boundary     : 4611686018427387904


-- Heikki Lindholm

Re: alsa timestamps

[Takashi Iwai]

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...


Takashi

Re: alsa timestamps

[Takashi Iwai]

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?


thanks,

Takashi

Re: alsa timestamps

[Heikki Lindholm]

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?

-- Heikki Lindholm

Re: alsa timestamps

[Heikki Lindholm]

[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]

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..

-- Heikki Lindholm


[-- Attachment #2: alsatest.c --]
[-- Type: text/plain, Size: 2285 bytes --]

#include <stdio.h>
#include <stdint.h>
#include <alsa/asoundlib.h>

#define FORMAT SND_PCM_FORMAT_S16_BE
#define RATE 48000

int main(int argc, char *argv[]) {
	snd_pcm_t *handle;
	snd_pcm_hw_params_t *params;
	snd_pcm_sw_params_t *swparams;
	snd_pcm_uframes_t period_size;
	snd_pcm_uframes_t buffer_size;
	snd_pcm_status_t *status;
	uint8_t *buf;
	int rate;
	int ret;
	ssize_t r;
	int t;

	if ((ret = snd_pcm_open(&handle, argv[1], 
			SND_PCM_STREAM_CAPTURE, 0)) < 0) {
		goto out;
	}

	snd_pcm_hw_params_alloca(&params);
	snd_pcm_sw_params_alloca(&swparams);
	if ((ret = snd_pcm_hw_params_any(handle, params)) < 0) {
		goto out;
	}
	if ((ret = snd_pcm_hw_params_set_access(handle,
			params, SND_PCM_ACCESS_RW_INTERLEAVED)) < 0) {
		goto out;
	}
	if ((ret = snd_pcm_hw_params_set_format(handle, params, 
			FORMAT)) < 0) {
		goto out;		
	}
	if ((ret = snd_pcm_hw_params_set_channels(handle,
			params, 2)) < 0) {
		goto out;
	}
	rate = RATE;
	if ((ret = snd_pcm_hw_params_set_rate_near(handle, params,
			&rate, 0) < 0)) {
		goto out;
	}
	period_size = atoi(argv[2]);
	if ((ret = snd_pcm_hw_params_set_period_size_near(handle, params,
			&period_size, 0)) < 0) {
		fprintf(stderr, "failed to set period size.\n");
	}
	t = 1000000;
	if ((ret = snd_pcm_hw_params_set_buffer_time_near(handle, params,
			&t, 0)) < 0) {
		fprintf(stderr, "failed to set buffer time.\n");
	}
	if ((ret = snd_pcm_hw_params(handle, params)) < 0) {
		goto out;
	}
	snd_pcm_hw_params_get_period_size(params, &period_size, 0);
	snd_pcm_hw_params_get_buffer_size(params, &buffer_size);

	snd_pcm_sw_params_current(handle, swparams);
	if ((ret = snd_pcm_sw_params_set_tstamp_mode(handle, swparams,
			 SND_PCM_TSTAMP_MMAP)) < 0) {
		goto out;
	}
	if ((ret = snd_pcm_sw_params(handle, swparams)) < 0) {	
		goto out;
	}
	if ((ret = snd_pcm_prepare(handle)) < 0) {
		goto out;
	}

	buf = malloc(period_size*2*2);

	snd_pcm_status_alloca(&status);
	for (t = 0; t < 1000; t++) {
		r = snd_pcm_readi(handle, buf, period_size);
		if (snd_pcm_status(handle, status) < 0) {
			fprintf(stderr, "snd_pcm_status failed.\n");
		}
		else {
			snd_htimestamp_t tstamp;
			snd_pcm_status_get_htstamp(status, &tstamp);
			printf("time: %d %d\n", tstamp.tv_sec, tstamp.tv_nsec);
		}
	}

	snd_pcm_close(handle);
out:
	return 0;
}

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 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;