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

[Takashi Iwai]

At Fri, 13 Jun 2008 18:47:48 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Fri, 13 Jun 2008, Takashi Iwai wrote:
> 
> > 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?
> 
> Does it improve something to show this pointer to apps? I don't see any 
> reason to show it outside alsa-lib.

Then it'll be more clear.

> > > 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.
> 
> I don't see a reason to make current API more complex.

Because the current API is complex and hard to understand.

> We have already two 
> functions, One showing overall latency and second one how much samples can 
> be processed by application. It's enough. We need only improve things 
> internaly in alsa-lib <-> kernel (provide correct information for 
> snd_pcm_delay()).
> 
> > Now, regarding the usb-driver.  Honestly, I don't understand what you
> > want to do with an extra URB.
> 
> Note that we don't need to have extra URBs, just change hw_ptr handling 
> in USB driver.

OK, then it's different from your previous explanation...

> > 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).
> 
> As Lennart mentioned, in this case you can reach underrun at different 
> position than expected (when URB cannot be filled). In my case, you'll 
> reach underrun exactly at point when whole ring buffer is drained. So 
> application can better estimate queueing and also it makes things more 
> logical.

Hm, could you elaborate how to do this more exactly?  That wasn't
clear from your previous post at all.


Takashi