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). 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. > I really don't understand why we need to hide hw_ptr and appl_ptr in > the current API. To me, exposing these points is much more > straightforward. > > In addition, there will be an API to provide the position > granularity as mentioned in the above. But, this can be a different > thing from the pointer APIs. I agree. Jaroslav ----- Jaroslav Kysela <perex@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
