Raymond Yau wrote:
> your program expect the driver support 2 periods per buffer but does not
> expicitly set the period
>
> 8000 Hz , S16_LE and mono
I am not sure why you think this is the case.
The period size is set at line 170 with snd_pcm_hw_params_set_period_size().
I'm setting up the sampling rate of 8000Hz in setup_pcm() starting at line 111.
I either use snd_pcm_hw_params_set_rate_near() or snd_pcm_hw_params_set_rate(),
depending on whether the PCM supports the exact rate or not.
I set up the audio format SND_PCM_FORMAT_S16_LE at line 76 with
snd_pcm_hw_params_set_format().
And finally, I also set up the number of channels (mono) in line 85 with
snd_pcm_hw_params_set_channels().
Last but not least, snd_pcm_dump() shows that exactly these settings are actively used:
------------------------------------------------------------------------
ALSA <-> PulseAudio PCM I/O Plugin
Its setup is:
stream : CAPTURE
[...]
format : S16_LE
[...]
channels : 1
rate : 8000
exact rate : 8000 (8000/1)
[...]
period_size : 160
[...]
avail_min : 160
------------------------------------------------------------------------
In the above output you can see that the format, number of channels, rate, period size and
avail_min are indeed set to correct values.
>>> I verified that avail_min is 160 frames
>
> is there any specific reason to choose 160 frames ?
Yes there is:
The audio frames are used for processing by a DSP lateron, which
requires each speech packet (i.e. period) to have exactly 160 frames.
It is also required that the audio frames are in S16_LE format,
they have a sampling rate of 8kHz and they arrive at the
DSP each 20ms (which corresponds to period_time).
As my code will use the atmel-pcm on an embedded target, the above mentioned
constraints should be no problem.
In fact a look at the PCM in the alsa kernel sources (sound/soc/atmel/atmel-pcm.c) reveals:
------------------------------------------------------------------------
static const struct snd_pcm_hardware atmel_pcm_hardware = {
.info = SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_MMAP_VALID |
SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_PAUSE,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
.period_bytes_min = 32,
.period_bytes_max = 8192,
.periods_min = 2,
.periods_max = 1024,
.buffer_bytes_max = 32 * 1024,
};
------------------------------------------------------------------------
However, as development on a slow ARM target can be a real pain, I am developing
the code *on a PC* which is why the poll() behavior really is an issue
(and maybe even a bug in alsa but more likely in pulseaudio).
As soon as the code is working, it will be easy to port it the ARM target.
cheers,
stefan
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
