[alsa-devel] Misusing snd_pcm_avail_update()

[Lennart Poettering]

On Tue, 20.01.09 19:48, Clemens Ladisch (clemens at ladisch.de) wrote:

> > I currently deal with this by always halving the first wakeup time --
> > which works most of the time but is a hack.
> 
> In theory, you could deduce this behaviour from
> snd_pcm_hw_params_is_double(), but the USB driver forgets to set this
> flag.

But still, with this flag I would only now that the startup sequence
is "fast". But not how "fast".

I appears to me that it would make a lot more sense if the driver
would simply tell me how long I may sleep instead of adding multiple
new functions 1) that tell me if double-buffering is used and what the
size of the second buffer is, 2) that tell me that data is pulled
block-by-block from the buffer and what the block size is, and so on. 

The function should look like this:

    snd_pcm_sframes_t snd_pcm_busy_for(snd_pcm_t *pcm);

I called the prototype "busy for" since effectively the value I am
looking for is the time the card will be busy with the data it already
has, and doesn't need any new data.

Can I convince you guys that a function like this would make a lot of
sense?

Instead of exporting all the gory details about blocks/double
buffering and so on, just a simple high-level call. 

> > With the function I suggest I'd be able to explicitly query how much
> > time I have before I need to wake up.
> 
> I was thinking about a function that returns the hardware's block size
> (i.e., the precision of the avail/delay values), but that wouldn't be
> able to describe this behaviour of the USB driver.  I think I might just
> remove this feature.

I am pretty sure there might be other drivers that work like this as
well. Hence I think simply removing double buffering in the USB driver
doesn't really solve the general issues I have.

> > > Well, you could make the "some extra margin" above larger than one
> > > period.
> >
> > To save power I want to disable interrupts from the sound cards as
> > much as possible.
> 
> In some cases (unusal hardware, but also USB), the period size affects
> the block size, i.e., smaller periods give better timing precision.

It would be good if this could be controlled independantly from
each other. 

> For this case, it might be useful to make the "pointer precision" a
> hardware parameter that can be restricted by an interval, like the other
> parameters.

That would be good.

Lennart

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