[alsa-devel] What does snd_pcm_delay() actually return?
perex at perex.cz
Fri Jun 13 18:11:12 CEST 2008
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
> 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.
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
More information about the Alsa-devel