You are not logged in.
I use following key bindings in ~/.fluxbox/keys to control a volume:
# volume settings, using common keycodes
# if these don't work, use xev to find out your real keycodes
176 :Exec amixer -q sset Master,0 1+; aplay -q ~/.resources/volume.wav
123 :Exec amixer -q sset Master,0 1+; aplay -q ~/.resources/volume.wav
174 :Exec amixer -q sset Master,0 1-; aplay -q ~/.resources/volume.wav
122 :Exec amixer -q sset Master,0 1-; aplay -q ~/.resources/volume.wav
160 :Exec amixer -q sset Master,0 toggle; aplay -q ~/.resources/volume.wav
121 :Exec amixer -q sset Master,0 toggle; aplay -q ~/.resources/volume.wavAs you see it just controls master channel volume and playbacks a short sound sample as a feedback.
This solution worked good for a few years.
A few days ago i found that feedback sound (aplay -q ~/.resources/volume.wav) got play with an odd delay. It can be up to 1-3 seconds. And when i press a bound key several times in a row it can be delayed for a few seconds and then volume changed with a random delay.
What can be a reason for this? I don't observe any high CPU load, memory usage etc.
Last edited by dimich (2018-07-18 22:16:59)
Offline
Well, I checked my keyboard and keys used for volume control. They react immediately with no observable delay. I run `aplay -q ~/.resources/volume.wav' in a shell and it behaves very strange. Sometimes it doesn't sound at all, sometimes it sound with a delay, sometimes it sound twice.
Offline
I found alsamixer displays only one bar for volume control. It looks like pulseaudio injected itself between kernel API and userspace ALSA libraries after some recent update. I don't yet know how to expel it, but now the reason is known. Sorry for flood.
Offline