i3status-rust
i3status-rust copied to clipboard
Volume block not working as expected
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
Yes, experiencing this as well, the volume block often gets out of sync
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?
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
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.
Out of curiosity I tried it with Discord killed, only firefox opened really, and the problem persists.
I don't believe I have seen this happen before. I have the driver explicitly set to pulseaudio in my config, how about you?
Same here, driver is explicitely set to pulseaudio
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
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.
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
Does it happen with pipewire-pulse as well?
I haven't seen this problem with pipewire-pulse, no, though I've only been using it since a couple weeks
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!
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.
Can you try with the async branch too? If it happens there then there's a chance it could be specific to pipewire
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
Ah yes, zbus 2.1 is incompatible with zbus 2.0, will update soon.
Updated
By the way, note that notmuch-dev is required at the moment.
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
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-rsdoesn'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.
Any chance 1934195 fixed this? (It merges the thread that subscribes to updates with the thread that queries the info)