Created attachment 118554 [details] pulseaudio logs (Downstream bugreport at https://bugzilla.redhat.com/show_bug.cgi?id=1265830 ) Description of problem: Days ago I disabled PulseAudio's flat volumes due PulseAudio: - crackling audio trouble (bugreport #92031) - inability to correctly handle application bad behaviour about volume levels https://bugzilla.redhat.com/show_bug.cgi?id=1265267 Disabling PulseAudio's flat volumes solved the mentioned problems, but introduced a new one. I usually increase / decrease volume level by using mouse wheel on KMix icon. Both actions sometimes trigger the master volume to 100% level. While collecting PulseAudio logs, I managed to reproduce (twice) the problem: Note: each mousewheel step increases or decreases volume level by a 5%. ===First occurrence of the problem=== At line number 1359 you can see the volume setted at 70%: A few moments later, I tried to increase it at 75%, but the volume level has been pushed to 100% (line number 1459). ===Second occurrence of the problem=== At line number 18000 you can see the volume setted at 40%: A few moments later, I tried to increase it at 45%, but the volume level has been pushed to 100% (line number 18016). Since on the logs, every volume level change has the form of D: [alsa-sink-Multichannel] alsa-sink.c: Requested volume: front-left: 65536 / 100% / 0,00 dB, front-right: 65536 / 100% / 0,00 dB that "Requested volume" makes me think about PulseAudio being requested to set the volume to 100%. So in the dubt I added in CC some guys of KDE SIG and alsa. I can quite easly reproduce the problem, so feel free to ask me to do any test. Version-Release number of selected component (if applicable): pulseaudio-6.0-8.fc22.x86_64 kmix-15.04.0-1.fc22.x86_64
In the first occurrence you didn't notice that the 70% volume was output volume, while the 100% volume was microphone volume. The second occurrence shows a real jump, however (lines 18014-18015): D: [pulseaudio] protocol-native.c: Client kmix changes volume of sink alsa_output.pci-0000_08_06.0.analog-stereo. D: [pulseaudio] sink.c: The reference volume of sink alsa_output.pci-0000_08_06.0.analog-stereo changed from front-left: 26208 / 40% / -23,88 dB, front-right: 26208 / 40% / -23,88 dB to front-left: 65536 / 100% / 0,00 dB, front-right: 65536 / 100% / 0,00 dB. The log looks like kmix sets the 100%, but of course it may be that PulseAudio is misinterpreting the data that kmix sends. One way to debug this would be to modify pa_context_set_sink_volume_by_index() so that it logs at the client side the parameters that kmix gives.
https://bugs.freedesktop.org/show_bug.cgi?id=84983 pulseaudio drop support of multi channel volume control
(In reply to Raymond from comment #2) > https://bugs.freedesktop.org/show_bug.cgi?id=84983 > > pulseaudio drop support of multi channel volume control I think that they are two different problems
[pulseaudio] alsa-mixer.c: Available mixer paths (after tidying): D: [pulseaudio] alsa-mixer.c: Path Set 0x559ae9bf8c10, direction=1 D: [pulseaudio] alsa-mixer.c: Path analog-output (Uscita analogica), direction=1, priority=99, probed=yes, supported=yes, has_mute=yes, has_volume=yes, has_dB=yes, min_volume=135, max_volume=255, min_dB=-60, max_dB=0 D: [pulseaudio] alsa-mixer.c: Element Master, direction=1, switch=1, volume=1, volume_limit=-1, enumeration=0, required=0, required_any=0, required_absent=0, mask=0x3600000000f66, n_channels=2, override_map=yes min dB -60dB is at 135 and 0 dB is at 255 number of step is 120 how do kmix/pulseudio calulate percentage ? volume step - min step / (max step - min step)
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/oxygen?id=eacbb9dba6b4c982a0217ea2c7d15db88d4fda37
(In reply to Raymond from comment #5) > https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/ > pci/oxygen?id=eacbb9dba6b4c982a0217ea2c7d15db88d4fda37 Mmmh I don't understand how this change in source code may be related to this bugreport... Actually I am using Fedora 24, kmix-16.04.2-1.fc24.x86_64 pulseaudio-8.0-6.fc24.x86_6 and I can say that since F23 I have never experienced this bug again. By the way I am still worried about long term distros, like RHEL/CentOS (etc.), that use more ancient packages.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/514.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.