On 10/18/18 16:45, Takashi Sakamoto wrote:
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.
Okay. Thanks for the hint. I think than I does not yet got the meaning
of the integer flag correctly. My expectation was that the interval is
interpreted as a real number interval in case integer is not set and
interpreted as a natural number interval. Therefore in case of integer
is not set the interval includes all real numbers which are >x and <=x+1
e.g. the interval (1 2] includes 1.89 and 2.
In case of integer flag is set I would expect the same rule >x and <=x+1
e.g. (1 2] only 2 is included because this is the only natural number
which is >1 and <=2.
Please correct me if I am wrong.
Thanks
Takashi Sakamoto (@airport)
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel