[alsa-devel] Rationale behind snd_pcm_htimestamp()

[Takashi Iwai]

At Mon, 16 Feb 2009 03:35:09 +0100,
Lennart Poettering wrote:
> 
> Heya!
> 
> I am interested to query the current delay and the current avail
> atomically together with the timestamp when they were current.
> 
> Apparantly there is now a function that can get the former two
> atomically (snd_pcm_avail_delay()) and another one that gets the latter
> two atomically (snd_pcm_htimestamp()). _avail_delay() seems to sync
> the hw index data, _htimestamp() apparently not. Hence I had assume
> that first calling _avail_delay() and then _htimestamp() one after the
> other without any further access would return the same avail
> value. Turns out, my test results on an USB card show that this
> assumption is not true.
> 
> An alternative way seemed to be to go via the snd_pcm_status
> structure. However querying that seems not to sync the hw index
> data. Hmm... so let's call snd_pcm_hwsync() right before querying the
> struct -- as it turns out however, that function is now deprecated. So
> which function should I call? The doxygen comments of _hwsync() kind
> of suggest in a way to call snd_pcm_avail_update(), whose doxygen
> comments however declare that it does in fact *not* sync the hw state
> either, but suggest to use snd_pcm_avail() for that.
> 
> Ok, so I am now tempted to first call snd_pcm_avail() and then
> snd_pcm_status() and have all three values atomically. But unfortunately
> that's not the case. Again the avail value of the two calls differs sometimes.
> 
> How can I query the three values atomically? Can i do that at all?

Hmm, there is no way to get them in atomic way anyway, I guess.
Even in *_avail_delay(),  basically each of them is called
sequentially in alsa-lib code.

But, I wonder whether calling snd_pcm_delay() then
snd_pcm_htimestamp() doesn't work?  snd_pcm_avail_delay() is nothing
but a sequential call of snd_pcm_delay() and avail_update().  And,
htimestamp is avail_update() and timestamp check.

Well, *_htimestamp() has a loop to sync with avail, so the similar
logic could be used to sync all of them...


> Also, snd_pcm_hw_params_is_monotonic() always returns 0 on all my
> devices. I am calling that function after having set both HW and SW
> params. Kernel is 2.6.27, alsa-libs is 1.0.19. The kernel itself does
> monotonic/hrtimers just fine.

Right, this seems buggy.  The info flag is never set in the kernel
side.  The kernel setup is changed rather via another ioctl.


> Hmm, last week I started this discussion about "snd_pcm_busy_for()"
> (aka granularity API). Who can I bribe to get an API like this?
> Although snd_pcm_busy_for() would suit me much better than just a call
> to query the granularity, I'd be happy with either...

Don't count me :)  I've been way too busy for other tasks right
now...  I'll keep my eye on it, though.


thanks,

Takashi