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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
