search

marioortizmanero / polybar-pulseaudio-control

A feature-full Polybar module to control PulseAudio
MIT License
478 stars 49 forks source link

No longer updates every time volume changes #70

Closed thennothinghappened closed 2 years ago

thennothinghappened commented 2 years ago

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. image Is this intended behaviour? I really hope not, or I'll have to stick to the outdated version.

marioortizmanero commented 2 years ago

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.

thennothinghappened commented 2 years ago

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 :/

marioortizmanero commented 2 years ago

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.

thennothinghappened commented 2 years ago

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

marioortizmanero commented 2 years ago

Hey @thennothinghappened, this has been fixed in v3.1.0. Let me know if it solves your issue :)

thennothinghappened commented 2 years ago

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.