Re: What does snd_pcm_delay() actually return?

[Lennart Poettering <mznyfn@0pointer.de>]

On Fri, 13.06.08 17:55, Takashi Iwai (tiwai@suse.de) 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.

I could agree to that. However, to be useful it must be possible to
query those three pointers atomically. i.e. in a single call:

   typedef struct snd_ptr_info {
        snd_uframes_t curr_ptr;
        snd_uframes_t hw_ptr;
        snd_uframes_t appl_ptr;
   } snd_ptr_info_t;

   int snd_pcm_get_ptr_info(snd_pcm_t *pcm, snd_ptr_info_t *i);

> I really don't understand why we need to hide hw_ptr and appl_ptr in
> the current API.  To me, exposing these points is much more
> straightforward.

I think I could subscribe to that.

Lennart

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