Rework playing of volume feedback
Needs ReviewPublic

Authored by drosca on Jan 15 2017, 10:48 AM.

Details

Reviewers
None
Group Reviewers
Plasma
Summary

Instead of manually playing feedback immediately on user interaction
(but with wrong, old volume), connect to volume change of all sinks and
play the feedback there.

Also don't cancel already playing feedback sound when playing new one
(in case of quickly changing volume), as cancelling it produces worse
sound (with some noise on my machine) than letting them play on top of
each other.

Test Plan

Feedback is now played with correct volume + quickly changing
volume produces pleasant feedback sound

Diff Detail

Repository
R115 Plasma Audio Volume Applet
Branch
feedback-rework (branched from Plasma/5.8)
Lint
No Linters Available
Unit
No Unit Test Coverage
drosca retitled this revision from to Rework playing of volume feedback.Jan 15 2017, 10:48 AM
drosca updated this object.
drosca edited the test plan for this revision. (Show Details)
drosca added a reviewer: Plasma.
Restricted Application added a project: Plasma. · View Herald TranscriptJan 15 2017, 10:48 AM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript

Aren't there applications like Skype that mess with volume settings, wouldn't that cause annoying sounds everytime?

drosca updated this revision to Diff 10495.Jan 24 2017, 1:24 PM

Make sure not to play feedback for volume changes that comes outside widget

drosca updated this object.Jan 24 2017, 1:25 PM

Ping. The issue pointed by @broulik have now been fixed, it only plays feedback for volume changes made by the applet.

Zren added a subscriber: Zren.Wed, Jan 10, 6:01 PM

Is the onVolumeChange call delayed? I'm not sure if it's fired when we set it, or PulseAudio gets back to us.

Does this fire onVolumeChange immediately?

sinkModel.preferredSink.volume = volume;

If so, you're currently calling

playFeedback(); // feedback.sinkIndex = sinkModel.preferredSink.index;

after you change the volume. Which means feedback.sinkIndex isn't set the first volume change, but it is still set until the next time you change the volume. Since it's not -1 after the first "volume change", it will play feedback, even if it's from something else.

If this is so, then we probably want to move the call before we assign the volume. Maybe even rename the function to playFeedbackNextVolumeChange() as well.

diff --git a/applet/contents/ui/main.qml b/applet/contents/ui/main.qml
index 1c9b759..cf58149 100644
--- a/applet/contents/ui/main.qml
+++ b/applet/contents/ui/main.qml
@@ -78,10 +78,10 @@ Item {
         }
         var volume = boundVolume(sinkModel.preferredSink.volume + volumeStep);
         var percent = volumePercent(volume, maxVolumeValue);
+        playFeedbackNextVolumeChange();
         sinkModel.preferredSink.muted = percent == 0;
         sinkModel.preferredSink.volume = volume;
         osd.show(percent);
-        playFeedback();
     }
 
     function decreaseVolume() {

Also, does sinkModel.preferredSink.volume = sinkModel.preferredSink.volume fire onVolumeChange too?

Eg: increaseVolume() setting it to 100% when it's already at 100%.

In D4140#188956, @Zren wrote:

Is the onVolumeChange call delayed? I'm not sure if it's fired when we set it, or PulseAudio gets back to us.

Does this fire onVolumeChange immediately?

sinkModel.preferredSink.volume = volume;

No. All signals are delayed by design because they are emitted only when changes are signaled from pulseaudio.

Also, does sinkModel.preferredSink.volume = sinkModel.preferredSink.volume fire onVolumeChange too?

Eg: increaseVolume() setting it to 100% when it's already at 100%.

Most likely no, unless it actually did change volume on pulseaudio side.