[alsa-devel] alsa timestamps
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
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
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
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
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
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
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
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
#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(¶ms); 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; }
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;
participants (3)
-
Heikki Lindholm -
Jaroslav Kysela -
Takashi Iwai