Takashi Iwai wrote: > At Thu, 23 Aug 2007 13:43:40 -0500, > Timur Tabi wrote: >> Takashi Iwai wrote: >> >>> Err, usually, application = user-space application. Do you mean >>> really this? >> Yes. The application allocates a buffer, locks it down, and passes it to the >> kernel. Since the buffer was allocated in user space, it is virtual >> contiguous but not physically contiguous, hence the need for a list of >> physical addresses. To the hardware, the buffer appears as a collection of >> scattered buffers. Hence, scatter/gather. > > Hm, then it must be a really special application. I've never seen > linux audio apps doing such things... That could be. I'm using a generic definition of S/G. Perhaps I should read the ALSA API before posting further. :-) > The problem in your scenario is that the buffers allocated from > user-space are not always DMA-able for devices, thus not always usable > for the hardware. It's possible for an application to allocate DMA-able memory. I think you need to allocate it normally than use mlock() on it, but it's been a while so I'm not sure. > The ALSA SG-buffer helper is simply to allocate individual pages and > gather as a virtually linear buffer. From the user-space, it's > nothing but a normal linear buffer. So what is the value of having the driver allocate a physically discontiguous buffer when it can easily allocate a contiguous one? Are there systems where allocating a 32KB physically-contiguous buffer is too hard? -- Timur Tabi Linux Kernel Developer @ Freescale _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
