[alsa-devel] Trouble understanding ALSA's DMA buffers
tiwai at suse.de
Tue Jun 12 12:36:36 CEST 2007
At Tue, 12 Jun 2007 01:59:45 +0530,
Nobin Mathew wrote:
> 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
Most hardwares support more periods practically. That's why "periods"
(corresponds to "fragments" in OSS) was introduced, as more generic
> 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
More information about the Alsa-devel