Rationale behind snd_pcm_htimestamp()

Rationale behind snd_pcm_htimestamp()

[Lennart Poettering]

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?

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.

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...

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: 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

Re: Rationale behind snd_pcm_htimestamp()

[Lennart Poettering]

On Mon, 16.02.09 17:08, Takashi Iwai (tiwai@suse.de) wrote:

> > 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...

Hmm, so I understood you correctly then the API would need changing to
get the timestamp, the delay and the avail value that belong together?
That's unfortunate.

Why doesn't calling _avail() and then _status() do what I want?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Rationale behind snd_pcm_htimestamp()

[Takashi Iwai]

At Wed, 18 Feb 2009 22:51:57 +0100,
Lennart Poettering wrote:
> 
> On Mon, 16.02.09 17:08, Takashi Iwai (tiwai@suse.de) wrote:
> 
> > > 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...
> 
> Hmm, so I understood you correctly then the API would need changing to
> get the timestamp, the delay and the avail value that belong together?

Yes, if you stick with snd_pcm_htimetamp(), snd_pcm_avil() and co.

But basically snd_pcm_status() does sync and fetch all status data.
Shouldn't calling this suffice for your purpose?


Takashi

Re: Rationale behind snd_pcm_htimestamp()

[Lennart Poettering]

On Wed, 25.02.09 16:13, Takashi Iwai (tiwai@suse.de) wrote:

> > Hmm, so I understood you correctly then the API would need changing to
> > get the timestamp, the delay and the avail value that belong together?
> 
> Yes, if you stick with snd_pcm_htimetamp(), snd_pcm_avil() and co.
> 
> But basically snd_pcm_status() does sync and fetch all status data.
> Shouldn't calling this suffice for your purpose?

Hmm, so snd_pcm_status() does sync? Good to know. I'll then use that.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4