[alsa-devel] Verification of settings
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?
Thanks, Rob
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
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@metafoo.de 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
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@rob-otics.com 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@metafoo.de 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
participants (2)
-
Lars-Peter Clausen -
Rob Nertney