[alsa-devel] hw_params function and OSS emulation

[Timur Tabi]

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