Strange behaviour with Volume and slider

[Titas-Lenkaitis]

Describe the bug
I made a volume slider, and moving the slider around can cause the slider to start glitching and slides around by itself, seemingly switching between a few values. This bug does affect the actual volume, and not just the slider value. Sometimes it requires deliberate effort to trigger but at other times it happens when just using it normally

2025-08-16_15-50-00.mp4

To Reproduce
Make a slider with the value being binded to the volume of the default speaker and the onValueChanged setting the volume of the default speaker
drag it around

Expected behavior
Should be able to just drag the slider around like any normal slider without getting into some loop like that

Additional context
The chance of this bug occurring seems to have a few factors.
One is the refresh rate of the monitor. At 60Hz, this is much harder to pull off but at higher refresh rates it can happen naturally just trying to slide the slider normally

This also is a lot easier to trigger when using a Bluetooth speaker, making the bug far easier to trigger.

The slider code:

<slider
    roundDigits={2}
    value={volume}
    min={0}
    max={100}
    page={5}
    step={5}
    widthRequest={250}
    onValueChanged={(self) => defaultSpeaker.set_volume(self.value/100)}/>

volume is a binding to the current volume:
const volume = createBinding(defaultSpeaker, "volume").as((self) => Math.round(self*100))

and defaultSpeaker is just the default speaker
const defaultSpeaker = wp.get_default_speaker()

Although I use 0-100 scale for volume, and multiply/divide where I need to, this issue still occurs when using the normal values of 0-1 for volume, like the volume slider in the gtk4 example bar.

I've also tried using onChangeValue and onNotifyValue but they both have over issues
I've used this exact method for my brightness slider with no issue.
This issue occurs on my other device aswell

[kotontrion]

I was not able to reproduce this yet.

When the value is set, it does not set the value of the property directly, but just sends the new value to PipeWire, which then sets the volume and emits a signal. When this signal is received, the volume property is set to the new value, so there is a small delay between you setting the value via the slider and the value actually being set.

So what you run into is a race condition here: you set the volume to value A, which is sent to PipeWire, then to value B, which is also sent to PipeWire, then you receive the signal for volume A, which sets the slider back to A. Because this changes the value of the slider, you again send value A to PipeWire, then you receive the signal for value B, which sets the slider position to that value and sends value B to PipeWire. At this point, you’re stuck in a loop.

I will look into how this can be improved in the AstalWireplumber library, but you should probably use the onChangeValue signal instead, as this will only be emitted when the value is changed as a result of user interaction, while onValueChanged is emitted anytime the value changes.

[Titas-Lenkaitis]

I've tried using onChangeValue, but it has it's own issue where it requires two actions to actually do something.

2025-08-18_13-18-19.mp4

For example, if the volume is at 50%, and i press right once, the slider moves to 55%, and only on the second press does the volume get set, and this happens anytime the slider is moved when using onChangeValue for me

[kotontrion]

I did briefly look into this (still wasn't able to reproduce) and this is not as straight forward to fix, as I initially thought.
My initial attempt was to ignore some volume update signals from wireplumber when I've sent multiple volume updates. But the way the wireplumber api is designed, makes this quite convoluted, so I've opted for another easier solutions. Just don't allow changing the volume from within the notify::volume signal handler, which should break the loop.

Could you test this patch?

diff --git i/lib/wireplumber/src/device.c w/lib/wireplumber/src/device.c
index b20f34f..8b30e51 100644
--- i/lib/wireplumber/src/device.c
+++ w/lib/wireplumber/src/device.c
@@ -290,7 +290,7 @@ GList *astal_wp_device_get_output_routes(AstalWpDevice *self) {
  */
 gchar *astal_wp_device_get_pw_property(AstalWpDevice *self, const gchar *key) {
     AstalWpDevicePrivate *priv = astal_wp_device_get_instance_private(self);
-    if(priv->device == NULL) return NULL;
+    if (priv->device == NULL) return NULL;
     const gchar *value = wp_pipewire_object_get_property(WP_PIPEWIRE_OBJECT(priv->device), key);
     return g_strdup(value);
 }
diff --git i/lib/wireplumber/src/node.c w/lib/wireplumber/src/node.c
index bf9a0e8..1c98892 100644
--- i/lib/wireplumber/src/node.c
+++ w/lib/wireplumber/src/node.c
@@ -27,6 +27,8 @@ typedef struct {
     gdouble volume;
     gboolean mute;
 
+    gboolean updating_volume;
+
     gchar *description;
     gchar *nick;
     gchar *node_name;
@@ -128,7 +130,9 @@ void astal_wp_node_update_volume(AstalWpNode *self) {
 
     g_object_notify(G_OBJECT(self), "volume-icon");
 
+    priv->updating_volume = TRUE;
     g_object_thaw_notify(G_OBJECT(self));
+    priv->updating_volume = FALSE;
 }
 
 static void astal_wp_node_mixer_changed(AstalWpNode *self, guint node_id) {
@@ -201,6 +205,8 @@ void astal_wp_node_set_volume(AstalWpNode *self, gdouble volume) {
     if (volume >= 1.5) volume = 1.5;
     if (volume <= 0) volume = 0;
 
+    if (volume == priv->volume || priv->updating_volume) return;
+
     gboolean mute;
     GVariant *variant = NULL;
     GVariantIter *channels = NULL;
@@ -492,7 +498,7 @@ void astal_wp_node_set_type(AstalWpNode *self, AstalWpMediaClass type) {
  */
 gchar *astal_wp_node_get_pw_property(AstalWpNode *self, const gchar *key) {
     AstalWpNodePrivate *priv = astal_wp_node_get_instance_private(self);
-    if(priv->node == NULL) return NULL;
+    if (priv->node == NULL) return NULL;
     const gchar *value = wp_pipewire_object_get_property(WP_PIPEWIRE_OBJECT(priv->node), key);
     return g_strdup(value);
 }
@@ -703,6 +709,7 @@ static void astal_wp_node_init(AstalWpNode *self) {
     priv->node_name = NULL;
     priv->name = NULL;
     priv->path = NULL;
+    priv->updating_volume = FALSE;
 
     priv->channels = g_hash_table_new_full(g_str_hash, g_str_equal, g_free, g_object_unref);
 }

but it has it's own issue where it requires two actions to actually do something.

That one I could reproduce, and should be fixable by implementing a opportunistic update mechanism, the above patch shouldn't affect this one.