[alsa-devel] Misusing snd_pcm_avail_update()

[Takashi Iwai]

At Thu, 22 Jan 2009 23:20:15 +0100,
Lennart Poettering wrote:
> 
> On Wed, 21.01.09 01:39, Takashi Iwai (tiwai at suse.de) wrote:
> 
> > > 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.
> > 
> > Isn't it snd_pcm_delay() that was originally designed for?
> 
> No. Let me summarize the meaning of snd_pcm_update_avail(),
> snd_pcm_delay() and my snd_pcm_busy_for() to opefully make clear where
> the differences are:
> 
> snd_pcm_update_avail() -- returns how many samples can be written
>                           right now without blocking.
> 
> snd_pcm_delay() -- returns how many samples will be played before the
>                    samples that are written now can be heard.
> 
> snd_pcm_busy_for() -- returns how many samples will be played before
>                       ALSA would enter an underrun situation if no
>                       further samples are written.

Well, in a ring-buffer model,

    snd_pcm_busy_for = buffer_size - snd_pcm_update_avail

If a granularity matters (e.g. no accurate sample position update can
be done), it would be

    snd_pcm_busy_for = max{0, buffer_size - s_p_u_a - granularity}

The granularity is between 0 and period_size.  The batch-mode is
granularity = period_size.

> snd_pcm_update_avail() and snd_pcm_busy_for() return metrics that are
> solely dependant on the size and metrics of the hardware buffer and
> its current indexes. snd_pcm_delay() also includes information about
> any extra latency that comes after the playback buffer.
> 
> Onle snd_pcm_update_avail()/snd_pcm_busy_for() are influenced by "fast
> starts" as done by the USB driver's double buffering and by
> block-based transfer.
> 
> Hmm, I am trying my best to explain why I want this function and what
> exactly it should do. Any chance I can convince you guys that this
> function really matters for timer-based audio scheduling?

I don't care much about the user-space API at this moment.  My main
concern is what kernel <-> user API is needed in addition or needed
to be changed.

If it's a question how to pass the granularity to user-space, usually
it's a constant value, and thus it can be put somewhere in the
existing struct, or add a single ioctl. 

OTOH, if it has to be implemented as a form of snd_pcm_busy_for(),
the kernel needs the compuation like the above.  That's my concern.

> > Did you check my previous patch?
> 
> You mean the one that makes snd_pcm_delay() for USB devices actually
> include the extra latency that comes after the playback buffer? No, I
> didn't check that one yet. It takes so much time to patch the kernel
> and test things... I'll try too finally do it this WE.

Hehe, changing API (should) take time, too :)


Takashi