Re: [alsa-devel] Verification of settings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Related question:

Once I have copied my data from PING into dma_area, and called snd_pcm_period_elapsed, can I assume arecord has consumed that data by the time i finish writing PONG, calling snd_pcm_period_elapsed, and hit the IRQ to recopy PING?

in other words, what/where is the guarantee that arecord has consumed the data in dma_area, such that the user can rewrite to it?



On Mon, Jul 11, 2016 at 12:33 PM, Rob Nertney <rob@xxxxxxxxxxxxx> wrote:
Thanks Lars.

My problem with the DMA is that it doesn't support cyclic mode, but does support SG mode. I have to create a new descriptor every time, and requeue/resubmit it. I don't want to drop any frames, so PONG is being received while PING is being copied and resubmitted to the Linux queue.

On Mon, Jul 11, 2016 at 12:29 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote:
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



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user

[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux