Re: [PATCH v2] pcm: null: Do not allow a period size of 0

From: Takashi Iwai <tiwai@suse.de>
To: twischer@de.adit-jv.com
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH v2] pcm: null: Do not allow a period size of 0
Date: Mon, 08 Apr 2019 14:28:20 +0200	[thread overview]
Message-ID: <s5hpnpwznob.wl-tiwai@suse.de> (raw)
In-Reply-To: <1554713754-6629-1-git-send-email-twischer@de.adit-jv.com>

On Mon, 08 Apr 2019 10:55:54 +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>
> ---
> 
> Hi Takashi,
> 
> > Why 32?
> I thought there is also no use case for a period of 1 frame. Therefore I
> increased it to a 2^n value to also lower the CPU usage in case of null
> plugin.
> 
> > Or does it cause a problem?
> I do not see any issues here. But for example portaudio will automatically
> choose a period size of 1 frame which will result in a higher CPU load.
> 
> But anyway I would also be fine with this higher CPU load if you prefer
> this patch.

Well, this is rather a bug in portaudio, then.  Clearly it's nonsense
to return zero for the minimal size, but any positive number can be
seen as a theoretically valid number.  This doesn't mean that any
value is usable for the practical use case, because such parameters
strongly depend on the other components like the CPU speed, memory
speed, whatever.  From the same reason, this can't be fixed from the
driver or the plugin itself.

So, I took now your v2 patch as is.  The rest should be a tuning
issue.

thanks,

Takashi