On Fri, 05 Apr 2019 16:09:53 +0200, twischer@de.adit-jv.com wrote:
From: Timo Wischer twischer@de.adit-jv.com
Some applications do not expect that get_period_size_min() could return 0. Therefore these applications cannot use the null plugin without this patch. Due to there is no use case for having a period size of 0 this patch disallows a period size of 0 when using the null plugin.
Signed-off-by: Timo Wischer twischer@de.adit-jv.com
src/pcm/pcm_null.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/pcm/pcm_null.c b/src/pcm/pcm_null.c index ff61624..c95fad8 100644 --- a/src/pcm/pcm_null.c +++ b/src/pcm/pcm_null.c @@ -261,7 +261,18 @@ static snd_pcm_sframes_t snd_pcm_null_mmap_commit(snd_pcm_t *pcm,
static int snd_pcm_null_hw_refine(snd_pcm_t *pcm ATTRIBUTE_UNUSED, snd_pcm_hw_params_t *params) {
- int err = snd_pcm_hw_refine_soft(pcm, params);
- int err;
- /* Do not return a period size of 0 because for example portaudio cannot
* handle it. In addition such small buffers would only increase the CPU* load but there is no benefit when throwing the samples anyway away.*/- err = _snd_pcm_hw_param_set_min(params, SND_PCM_HW_PARAM_PERIOD_SIZE,
32, 0);
Why 32? This is a virtual device, hence we don't need to set any practical limit. If the zero is harmfull, the next preferable alternative is 1, when logically thinking. Or does it cause a problem?
thanks,
Takashi