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