[alsa-devel] Trouble understanding ALSA's DMA buffers

Nobin Mathew nobin.mathew at gmail.com
Mon Jun 11 22:29:45 CEST 2007


Hi,

Now ALSA (audio ) buffer is divided into periods, i.e. a chain of small packets.

periods size is configurable. Data transfer to the codec starts only
after reaching start_threshold point (start_threshold is in periods),
this time DMA trigger is called.

This trigger onwards application will get notification from the kernel
saying that period buffer is empty you can write into it.Till the end
of music file.

Nobin Mathew



On 6/12/07, Timur Tabi <timur at freescale.com> wrote:
> I'm writing an ALSA SOC driver for an I2S-based device, and I'm having a really hard time
> understanding how ALSA uses the DMA buffers.  And yes, I've read the documentation and
> studied some sample source code.
>
> I used to write audio drivers for a living, but that was many years ago, and it wasn't for
> Linux.  Perhaps the concepts in my head are outdated, but I just don't see enough
> explanation as to how DMA buffers are supposed to work.
>
> Back then, audio drivers used "ping pong" DMA buffers.  A single DMA buffer is allocated,
> and the audio hardware is programmed to read from that buffer in a loop.  That is, it
> would automatically restart reading from the beginning of the buffer without any
> reprogramming.  The hardware would also be programmed to issue an interrupt when it got to
> the end of the buffer, and when it got to the half-way point.
>
> To start playback, you first filled the whole buffer with audio data, and then told the
> hardware to start playing.  After the hardware got to the half-way point, it would issue
> an interrupt.  You would then tell the OS you need more data, and you'd get it.  You then
> copy that data into the first half of the buffer *while* the hardware was playing the
> second half.  Later, the hardware would interrupt you when it got to the end of the
> buffer.  You'd then copy more data to the 2nd half while the hardware is playing the first
> half.
>
> And so - hardware plays one half while you copy data to the other half.  Hence, "ping pong".
>
> So how do I implement this in ALSA?  The "Writing an ALSA Driver" document doesn't even
> contain the words "ping" or "pong".
>
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>


More information about the Alsa-devel mailing list