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

[Takashi Iwai]

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
samples_in_urbs).


Takashi