[alsa-devel] hw_params function and OSS emulation
timur at freescale.com
Thu Aug 23 21:13:08 CEST 2007
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?
Linux Kernel Developer @ Freescale
More information about the Alsa-devel