I found the following doc, it talks about periods in depth with a figure. http://delivery.acm.org/10.1145/1020000/1017977/6735.html?key1=1017977&key2=0592661811&coll=GUIDE&dl=GUIDE&CFID=15151515&CFTOKEN=6184618 -pharaoh. On 6/12/07, Pharaoh . <pharaoh137@xxxxxxxxx> wrote: > On 6/12/07, Takashi Iwai <tiwai@xxxxxxx> wrote: > > > > 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 > > > > > Hi > > yet another newbie question about periods here: > > 1. AFAIK, the period size is closely dependent on the h/w, but after reading > some docs I collected > that, they can be given values depending on how much we care about the > latency. Does it mean > that, I can vary it without paying any attention to what h/w manual says > just because I want low or > high latency? I hope this question is clear. > > 2. As periods correspond to fragment size from OSS world, what the other > periods related fields > correspond to i.e. what do the following fields mean? > > period_bytes_min, > period_bytes_max, > periods_min, > periods_max, > > I know what they mean after looking at them but I want to know the > relationship between various > fields. > > For e.g. > > I have, > > buffer_bytes_max = 8192 * 8 > i.e. = AUDIO_FRAGSIZE_DEFAULT * AUDIO_NBFRAGS_DEFAULT > > here AUDIO_FRAGSIZE_DEFAULT is size of period right? Then to get the max > buffer size we should multiply it > by number of periods, is this correct? Also, these are default values of the > period and no of periods, then do > I need to see the h/w manual to decide the periods_min/periods_max and > period_bytes_min/period_bytes_max > fields? > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
