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)
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
