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

[Takashi Iwai]

At Tue, 12 Jun 2007 01:59:45 +0530,
Nobin Mathew wrote:
> 
> 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.

Yes.  And the "ping-poing" is the case that you have two periods in a
ring buffer.

Most hardwares support more periods practically.  That's why "periods"
(corresponds to "fragments" in OSS) was introduced, as more generic
abstraction.


Takashi

> 
> 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
> >
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>