[alsa-devel] Verification of settings

Lars-Peter Clausen lars at metafoo.de
Mon Jul 11 21:29:13 CEST 2016


On 07/11/2016 09:10 PM, Rob Nertney wrote:
> Hi all,
> 
> Could I please get a sanity check on my hw_params?
> 
> I have a DMA which is providing between 1-16 channels of 4 bytes/ch worth
> of data as a frame. I get an interrupt to my driver every frame's worth of
> data (64 Bytes). The data is S32_LE, 16000Hz.
> 
> My DMA has 2 buffers, PING and PONG. Each receives an IRQ on a frame
> length, and these local buffers are the size of a frame length (64Bytes).
> 
> #define MAX_BUFFER (64 * 2)
> static struct snd_pcm_hardware my_pcm_hw =
> {
>   .info = (SNDRV_PCM_INFO_MMAP |
>       SNDRV_PCM_INFO_INTERLEAVED |
>       SNDRV_PCM_INFO_BLOCK_TRANSFER |
>       SNDRV_PCM_INFO_MMAP_VALID),
>   .formats          = SNDRV_PCM_FMTBIT_S32,
>   .rates            = SNDRV_PCM_RATE_16000,
>   .rate_min         = 16000,
>   .rate_max         = 16000,
>   .channels_min     = 1,
>   .channels_max     = NUM_CHANNELS,
>   .buffer_bytes_max = MAX_BUFFER,
>   .period_bytes_min = 4,
>   .period_bytes_max = 64,
>   .periods_min      = 2,
>   .periods_max      = 2,
> };
> 
> 
> My understanding is that the MAX_BUFFER needs to be at least twice the size
> of a period so I don't underrun. .periods_max means the maximum number of
> periods in a the alsa dma_area buffer, right?
> 
> So when my DMA fires its ISR, I copy from its local PING buffer to the
> dma_area at offset 0, increment the buf_pos by the frame_length (64Bytes),
> and call snd_pcm_period_elapsed.
> 
> My DMA fires its ISR for its local PONG buffer, copies to the
> dma_area+buf_pos, increments buf_pos (now back to 0, since buffer only
> holds 2 frames/periods), and I call snd_pcm_period_elapsed again, correct?

Hi,

In principle sounds OK. But there is not much of a point to use a
ping-pong buffer if you give the real buffer the same restrictions. You
might as well use the dma_area buffer as the target of the DMA in that
case. But since in your case the DMA is very restrictive in what it can
support it makes more sense to use the ping-pong buffer and broaden the
restrictions on the real buffer. Allow larger period sizes (only call
snd_pcm_period_elapsed() every N interrupts), allow more than two
periods and so on.

- Lars



More information about the Alsa-devel mailing list