Without this commit the following intervals [x y), (x y) were be
replaced to (y-1 y) by snd_interval_refine_last(). This was also done if
y-1 is part of the previous interval.
With this changes it will be replaced with [y-1 y) in case of y-1 is
part of the previous interval. A similar behavior will be used for
snd_interval_refine_first().
This solves the issue reported here:
https://bugzilla.opensuse.org/show_bug.cgi?id=1033179
and work arounded with commit
e736715 ("pcm: dmix: Disable var_periodsize as default").
I am able to reproduce the issue with a simplified aplay use case using
the following configuration:
pcm_slave.adr3_tdm_8ch {
pcm {
type hw
card "Loopback"
device 0
}
rate 48000
period_size 128
buffer_size 1024
channels 2
}
pcm.dshare_Playback_3 {
type dmix
ipc_key 600
ipc_perm 0660
ipc_gid audio
var_periodsize true
slave adr3_tdm_8ch
}
pcm.AdevAcousticoutSpeech {
type rate
slave.pcm dshare_Playback_3
slave.rate 48000
}
$ modprobe snd_aloop
$ aplay -v --period-size=352 -c2 -fS16_LE -r22500 -DAdevAcousticoutSpeech /dev/urandom
...
Rule 9 (0xffff91d1f230): PERIODS=(0 2) -> NONE BUFFER_SIZE=480 PERIOD_SIZE=[240 240]
refine_soft 'AdevAcousticoutSpeech' (end--22)
...
aplay: ../../alsa-utils-1.1.5/aplay/aplay.c:1390: set_params: Assertion `err >= 0' failed.
Aborted by signal Aborted...
The following stack trace shows where the -EINVAL will be thrown:
__snd_pcm_hw_params_set_period_size_near()
snd1_pcm_hw_param_set_near()
snd1_pcm_hw_param_set_last()
snd1_pcm_hw_refine_slave()
snd1_pcm_hw_refine_soft()
snd_pcm_hw_rule_div()
snd1_interval_refine()
This issue exists due to PERIODS does not include 2
Rule 9 (0xffff91d1f230): PERIODS=(0 9) -> (0 2) BUFFER_SIZE=[120 480]
PERIOD_SIZE=(240 241)
because of an invalid integer inverval of PERIOD_SIZE of (240 241).
This interval is set by snd_interval_refine_last().
Signed-off-by: Timo Wischer <twischer@de.adit-jv.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use the standard uint{8,16,32,64}_t everywhere instead of the
non-standard u_int{8,16,32,64}_t.
This changes the types in the public headers and removes the u_int*_t
defines. This may break things. However, indentifiers ending with _t are
reserved by POSIX[1]; defining those can lead to undefined behavior.
So if you rely on alsa-lib defining those for you, then you want the
compiler to error so things can be fixed properly.
[1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_02
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
