[alsa-devel] alsa timestamps
Heikki Lindholm
holindho at cs.helsinki.fi
Tue Nov 20 17:07:25 CET 2007
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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: alsatest.c
Url: http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20071120/0927edc4/attachment-0001.bat
More information about the Alsa-devel
mailing list