mirror of
https://github.com/alsa-project/alsa-lib.git
synced 2026-06-02 21:39:27 -04:00
b420056604
Without this change an interval of (x x+1] will be interpreted as an
empty interval but the right value would be x+1.
This leads to a failing snd_pcm_hw_params() call which returns -EINVAL.
An example issue log is given in the following:
snd_pcm_hw_params failed with err -22 (Invalid argument)
ACCESS: MMAP_NONINTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: 16
CHANNELS: 1
RATE: 16000
PERIOD_TIME: (15999 16000]
PERIOD_SIZE: (255 256]
PERIOD_BYTES: (510 512]
PERIODS: [2 3)
BUFFER_TIME: 32000
BUFFER_SIZE: 512
BUFFER_BYTES: 1024
In case of (x x+1) we have to interpret it anyway as a single value of x to
compensate rounding issues.
For example the period size will result in an interval of (352 353) when
the period time is 16ms and the sample rate 22050 Hz
(16ms * 22,05 kHz = 352,8 frames). But 352 has to be chosen to allow a
buffer size of 705 (32ms * 22,05 kHz = 705,6 frames) which has to be >= 2x
period size to avoid Xruns. The buffer size will not end up with an
interval of (705 706) simular to the period size because
snd_pcm_rate_hw_refine_cchange() calls snd_interval_floor() for the buffer
size. Therefore this value will be interpreted as an integer interval
instead of a real interval further on.
This issue seems to exist since the change of
|
||
|---|---|---|
| .. | ||
| alisp | ||
| conf | ||
| control | ||
| hwdep | ||
| mixer | ||
| pcm | ||
| rawmidi | ||
| seq | ||
| timer | ||
| topology | ||
| ucm | ||
| async.c | ||
| conf.c | ||
| confmisc.c | ||
| dlmisc.c | ||
| error.c | ||
| input.c | ||
| Makefile.am | ||
| names.c | ||
| output.c | ||
| shmarea.c | ||
| socket.c | ||
| userfile.c | ||
| Versions.in | ||