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

[Jaroslav Kysela]

On Fri, 13 Jun 2008, Takashi Iwai 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). If driver requires 
extra handling of samples, it can allocate and manage extra buffers 
itself. I don't see the point to have "locked" samples already processed 
by hardware in the main ring buffer described by appl_ptr / hw_ptr.
Application can use this space for new samples.

The only advantage with your implementation might be zero-copy, but USB 
and PCMCIA cards have or create own buffers, so I don't think that this 
advantage can be used in actual drivers and I cannot even imagine 
hardware which work in way to use zero-copy in this situation.

> 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.
> 
> In addition, there will be an API to provide the position
> granularity as mentioned in the above.  But, this can be a different
> thing from the pointer APIs.

I agree.

					Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.