No longer updates every time volume changes
thennothinghappened opened this issue · comments
When changing my volume, a visual update is painfully slow and (as I have a keyboard with a volume wheel, and thus have it set up so that volume goes up by only one each time), it makes it really difficult to set a precise volume now without going really slowly to wait for it to update. Below is running the same command through the terminal, and you can see that it is skipping a bunch, where as pre 3.0.0 updated at every change.
Is this intended behaviour? I really hope not, or I'll have to stick to the outdated version.
That's unfortunate. Are you using v3.0.0 or v3.0.1? We did change how we process the events so that the script consumes less CPU: #65, #67. It buffers the input events for 100ms and prints the output before and after. So that seems like the delay you're experiencing. It was good enough for me, but I imagine others like less latency.
You can try to fix this by changing this line's -t parameter to something like 0.05, which should be 50 ms, or even less. Let me know if you can find a number that fits your needs. We can then add a flag to customize it, or modify the default value.
this did what I was looking for, thanks!
I ended up settling on 0.02, which ends up using a little less CPU than the old one did. while this isn't ideal for CPU use, I don't really care as I prefer the fast updates, and I'm not changing my volume 24/7 anyway.
something else that was mildly annoying was that going between versions I had to change between sink and 'node'. I get why this was done given the changes made but it was annoying that it doesn't just let me use the old way... I ended up modifying the script to change it back for now. next update I'll have to use the new way :/
Shall we add a --listen-timeout-secs flag to configure it, then?
About the breaking changes, I personally think they were necessary for the new feature. Otherwise it would be very confusing, and I don't think they were that bad, especially because we warn about them, rather than silently failing. It should be as easy as a s/sink/node and s/SINK/NODE in your config. Not sure what you had to change in the script.
Making it customisable through a flag would be great!
As for your question, in the script — since I was going back and forth between the old one and new one — I changed it back to sink... instead of node... in any occurrences of it so that I wouldn't have to change my polybar config every time. Once the flag is added in a release I'll change over to the proper one and thus will stop using my mutilated version lol
Hey @thennothinghappened, this has been fixed in v3.1.0. Let me know if it solves your issue :)
Works great now, thanks! I've got the flag set to 0.01, having the customisability without having to manually change it in the script is great.