[alsa-devel] What does snd_pcm_delay() actually return?

[Lennart Poettering]

On Fri, 13.06.08 18:47, Jaroslav Kysela (perex at perex.cz) wrote:

> > > > What about just providing three pointers: curr_ptr, hw_ptr and
> > > > appl_ptr?  curr_ptr corresponds to the point being played, and hw_ptr
> > > > is the point where the data was already sent to h/w, and appl_ptr is
> > > > the point where the data is filled by user.  The above definitions are
> > > > all combinations of these pointers.
> > > 
> > > But I think that curr_ptr can be managed in drivers, thus invisible to 
> > > user space (except for snd_pcm_delay() propagation).
> > 
> > Ditto for hw_ptr.  Why is it hidden at all?
> 
> Does it improve something to show this pointer to apps? I don't see any 
> reason to show it outside alsa-lib.

As I already pointed out different applications need different kinds
of timing information. Some want to estimate when the next xrun will
happen, other's want the delay that the next write will take to be
played, even other's want how much of the already written data is not
yet played. Even other's want absolute times.

And I do follow Takashi in so far that when you'd just choose to
export the three pointers to userspace, so that they can be queried
atomically everybody can relatively easily calculate from these 'raw'
values what they need.

The problem I see with those 'cooked' values that are currently
exported (i.e. delay and update_avail) is that they only serve a
single purpose and there are so many different ways to use and
especially misuse them, as we have seen in the WINE case. Certainly,
the ptrs can be misused too, but at least all the information the
kernel has that it uses to calculate those 'cooked' values is
available to userspace too, so without too ugly code userspace can
always calculate what is necessary. If you only have a subset of the
cooked stuff and want to calculate the other cooked stuff from it your
in pain.

I think there are two extremes:

a) export the 'raw' info to userspace: the three pointers

b) export the 'cooked' info to userspace in all its variations:
   similar to the API I suggested that would take an enum for
   choosing the right timing parameter the app wants.

Everything in between these extremes would be incomplete.

I could live with any situation of these two. The question is do you
trust userspace programmers to use the three pointers correctly, or do
you want to make sure they get things right with the enum API?

Lennart

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