I can’t tell you how many times I’ve been annoyed by the volume control on the volumio web app. Sometimes, I’ll use scrolling on a trackpad or a touchscreen or mouse wheel and make a wild adjustment only to have the control snap back to the previous setting with no change.
OR! I’ll carefully tap the plus and minus buttons and try to increase or decrease the volume in increments only to see the numbers stick or not change by the right amount. Some clicks just disappear.
It’s been like this since I started using volumio two or more years ago. I don’t think it’s ever improved.
Is it just me? Maybe my pis are too underpowered to accurately adjust volume. Maybe sending volume adjustments via REST API is too slow and it gets overwhelmed by the requests. Maybe a WebSocket volume control would be more responsive.
What the hell do I know? I just want to fiddle with my volume.
Hi Rob,
what browser are you using?
What DAC do you have?
The minus\plus button thing is something we’ve not been able to solve yet… This is due to the fact that some audio HW has volume in 0-255 steps, and when for example you set 76 as level of volume, it returns 77 or 75 (rounding error by alsa). So this is why it does not move…
Please give me more info and we will try to understand what causes the UI glitch in your case (we already use websocket)
I fell your pain. A while back I couldn’t get it working reliably with a few of my non pi boards, and hence decided to bake in volume control directly into vollibrespot. At least in my network the entire chain (FrontEnd > Backend > exec subshell -> amixer) has a really noticeable lag.
But then again, this was all on non standard Orange|Nano pi boards, and not the usual raspberry pi - so my views might be biased by the fact the Volumio isn’t optimised for these 512MB/1G ram boards.
Oh, and there are also some annoying rounding issues if you select lower step rates because of the parsing
The latency is due to the fact that we preferred to notify that the volume changed only when it actually changes (and not a fire and forget approach).
This adds some latency, but from my point of view that is preferrable rather than see volume move and volume is not actually changed…
If there are ideas on how to improve it please let us know
And here I thought it was a universal issue and nobody else complained about it.
I typically use Firefox around the house, or mobile Safari on iPad and iPhone via the app. I feel the volume “knob” pain on both platforms where I think I set a volume and then the rotary encoder snaps back to the original position or some different value.
I’ve got two Volumios running on RPi3B and a RPi3B+. One’s a Hifiberry AMP2 and the other has a Hifiberry DAC+ Pro (original, not the V2).
When I was poking at another Hifiberry board with amixer, I did indeed see that the volume range was 0-255 so that probably explains the issue with the +/- buttons.
As for fixing it, I think the UI should take priority. If I press a + or - button, I expect a volume change to happen, though maybe not by the exact increment my volume settings have stored.
Do we have a fractional value stored as the “expected volume” setting or do we drop all fractions after every increment or decrement? I suppose I’d have to look at what the code’s doing, but if we’re just dropping that fractional component (2.55 x inc_value), we’re going to be dropping volume levels roughly half the time we hit those buttons.
Anyway. Thank you for letting me express my frustrations. I’ve learned a little bit here today. I wish I had time to contribute code.