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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
