[alsa-devel] What does snd_pcm_delay() actually return?
tiwai at suse.de
Fri Jun 13 18:26:17 CEST 2008
At Fri, 13 Jun 2008 18:11:12 +0200 (CEST),
Jaroslav Kysela wrote:
> 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).
Ditto for hw_ptr. Why is it hidden at all?
> 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.
Wait, wait. Please don't mix up. The above doesn't imply anything
about the further implementation of usb-audio driver. What I
suggested is, instead of hiding two pointers (hw_ptr and curr_ptr) and
creating a complex API, simply expose them.
Now, regarding the usb-driver. Honestly, I don't understand what you
want to do with an extra URB.
As now, usb-audio driver handles as curr_ptr == hw_ptr. But, in
reality, curr_ptr = hw_ptr - samples_in_urbs. So, in the case
of USB-audio, hw_ptr is ahead of curr_ptr. (And the granularity is
More information about the Alsa-devel