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