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?