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)