[alsa-devel] [PATCH - Intervals v2 1/1] interval: Interpret (x x+1] correctly and return x+1

[Takashi Sakamoto]

Hi,

On Thu, 18 Oct 2018, Timo Wischer wrote:
> The reason for this fix was an issue where an interval of (x x+1] is 
> interpreted as not a single value.
> Before the change in snd_interval_single() the following intervals were 
> interpreted as a single value:
>
> * (x x) -> required for rounding issues e.g. 32ms * 22,05 kHz = 705,6
>   frames => (705 706)
> * (x x]
> * [x x)
> * [x x]
> * (x x+1)
> * [x x+1)
>
> With this change (x x+1] will also be interpreted as a single value (which 
> looks reasonable for me).
> But the interval [x x+1] is still not interpreted as a single value (which 
> also sounds right for me)
>
> Before the change in snd_interval_value() for all intervals x was returned.
> With this change only in case (x x+1] x+1 will be returned. All other 
> intervals are not changed.
>
> Therefore this is a minimal change which solves issues. I have already at 
> least two use cases which
> are failing without this fix. (Somehow simple use cases with rate->dmix->hw 
> where the hw truncates
> the default period_time of 125ms and fails with EINVAL on 
> snd_pcm_set_period_near()).
> Therefore I would expect that these issues will be seen soon by other users.
>
> If there is a use case which breaks in future due to the right interpretation 
> of (x x+1] I think we should try
> to find the root cause why this (x x+1] interval has to be interpreted 
> wrongly to get the use case to work.

'struct snd_interval' has 'integer' flag. When this flag is off,
'(x, x + 1]' brings no single unique value. The inline function
'snd_interval_single()' should handle this case correctly.


Thanks

Takashi Sakamoto (@airport)