i3status-rust icon indicating copy to clipboard operation
i3status-rust copied to clipboard

Volume block not working as expected

Open paulo-caldas opened this issue 4 years ago • 22 comments

I'm using i3, with the following commands mapped for volume:

bindsym Mod4+F7 exec --no-startup-id "pactl set-sink-mute 0 toggle" bindsym Mod4+F8 exec --no-startup-id "pactl set-sink-volume 0 -5%" bindsym Mod4+F9 exec --no-startup-id "pactl set-sink-volume 0 +5%"

I haven't been able to understand under what conditions exactly it happens, but commands seem not to work sometimes, and when I run another command, the one that was run previously is activated.

For example:

1- press mute -> volume gets muted, but status bar show nothing 2 - decrement audio -> system tray only now reports sound as muted

paulo-caldas avatar Apr 18 '21 22:04 paulo-caldas

Yes, experiencing this as well, the volume block often gets out of sync

alarsyo avatar Apr 19 '21 21:04 alarsyo

I use a similar command, but instead of sink 0 i use

pactl set-sink-volume @DEFAULT_SINK@ +5%

which should be better if the audio output device (order) may change.

Also, in my experience it sometimes happens that other applications (discord for example) also mess with pulseaudio which results in the displayed value from i3status-rust to desync. Did you try this with no applications running?

GladOSkar avatar Apr 20 '21 12:04 GladOSkar

For what it's worth scrolling on the block also sometimes causes desynchronization for me. I do have Discord opened quite often though, will check for that

alarsyo avatar Apr 20 '21 14:04 alarsyo

Yeah for me it's when discord is open/on a call then scrolling on the sound block often is 1-2 steps off from the real value from pavucontrol. But not always.

GladOSkar avatar Apr 20 '21 14:04 GladOSkar

Out of curiosity I tried it with Discord killed, only firefox opened really, and the problem persists.

paulo-caldas avatar Apr 20 '21 22:04 paulo-caldas

I don't believe I have seen this happen before. I have the driver explicitly set to pulseaudio in my config, how about you?

ammgws avatar Apr 21 '21 12:04 ammgws

Same here, driver is explicitely set to pulseaudio

alarsyo avatar Apr 21 '21 13:04 alarsyo

Managed to record a short occurrence of the problem:

https://user-images.githubusercontent.com/15170378/115639334-9afedf00-a314-11eb-8522-d4aa898b0163.mp4

The block volume is desynchronized at the beginning at the recording, I'm only scrolling up on the mouse until everything gets synced back up, then scroll up and down a bit to check that everything's back to normal

alarsyo avatar Apr 22 '21 00:04 alarsyo

I am indeed using the pulseaudio driver. Perhaps more confusing in my particular situation, the volume is sometimes set to percentages which are not divisible by 5, despite the fact that my binds only increment and decrement by 5%. Very curious.

paulo-caldas avatar Apr 29 '21 17:04 paulo-caldas

https://user-images.githubusercontent.com/26326040/117447684-b46b7200-af35-11eb-8156-75e9118c8a0e.mp4

Here's my attempt to replicate the issue. I'm using xset r rate 1000 1 so the key gets registered after 1 second and repeated once per second. I have pavucontrol below to show the actual status of the audio output, which differs from the one shown in the status bar.

Here's the keybindings I used:

bindsym Mod4+F7 exec --no-startup-id "amixer -D pulse set Master 1+ toggle"
bindsym Mod4+F8 exec --no-startup-id "amixer -D pulse sset Master 5%-"
bindsym Mod4+F9 exec --no-startup-id "amixer -D pulse sset Master 5%+"

Here's my volume block:

[[block]]
block = "sound"
driver = "pulseaudio"
device_kind = "source"

I found the same issue when muting my microphone with amixer set Capture toggle

paulo-caldas avatar May 07 '21 12:05 paulo-caldas

Does it happen with pipewire-pulse as well?

ammgws avatar Jun 12 '21 14:06 ammgws

I haven't seen this problem with pipewire-pulse, no, though I've only been using it since a couple weeks

alarsyo avatar Jun 15 '21 07:06 alarsyo

I never could reproduce this with native pulseaudio but it would be quite interesting if it doesn't occur with pipewire-pulse. Keep us posted!

ammgws avatar Jun 16 '21 14:06 ammgws

Does it happen with pipewire-pulse as well?

I use pipewire-pulse and recently it's broken for me. Often it's 1-2 inputs behind and i have to reset i3 to get it back. Sometimes it works as expected, i have no idea how it works.

Using the scroll-wheel to change the volume is even worse, the first scroll it changes the volume but doesn't update the block, the second scroll it updates the block only.

Cavernosa avatar Feb 03 '22 00:02 Cavernosa

Can you try with the async branch too? If it happens there then there's a chance it could be specific to pipewire

ammgws avatar Feb 03 '22 03:02 ammgws

I can't build the async branch :( It gives this error, i have the last stable rustc:

error[E0004]: non-exhaustive patterns: `_` not covered
  --> src/util.rs:71:24
   |
71 |     let stream = match zbus::Address::session().unwrap() {
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ pattern `_` not covered
   |
   = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
   = note: the matched value is of type `zbus::Address`, which is marked as non-exhaustive

error[E0004]: non-exhaustive patterns: `_` not covered
  --> src/util.rs:93:24
   |
93 |     let stream = match zbus::Address::system().unwrap() {
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ pattern `_` not covered
   |
   = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
   = note: the matched value is of type `zbus::Address`, which is marked as non-exhaustive

Cavernosa avatar Feb 15 '22 19:02 Cavernosa

Ah yes, zbus 2.1 is incompatible with zbus 2.0, will update soon.

MaxVerevkin avatar Feb 15 '22 19:02 MaxVerevkin

Updated

MaxVerevkin avatar Feb 15 '22 20:02 MaxVerevkin

By the way, note that notmuch-dev is required at the moment.

MaxVerevkin avatar Feb 15 '22 20:02 MaxVerevkin

Thanx MaxVerevkin I tried it and it behaves exactly the same as the master branch, lagging behind 1-2 step. My actual config bugged so I had to create a new simple config to work

https://user-images.githubusercontent.com/42952107/154168598-7403af36-4ec7-4be3-a303-1ded461199af.mp4

Cavernosa avatar Feb 15 '22 23:02 Cavernosa

Using pipewire-pulse with arch and experiencing the same issue.

I've too noticed that it often gets one volume control action out of sync but also that:

  • even pkill -10 -x i3status-rs doesn't force refresh the bar to get the right information.
  • The bar updates to correct and current information when starting or stopping music. Atleast in case when there's only one active program pushing audio.

MrSauna avatar Mar 01 '22 00:03 MrSauna

Any chance 1934195 fixed this? (It merges the thread that subscribes to updates with the thread that queries the info)

MaxVerevkin avatar May 03 '23 14:05 MaxVerevkin