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