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